分布式系统以及安全问题详解

发表于 分类于 阅读次数： 本文字数： 2.6k 阅读时长 ≈ 2 分钟

你的理解抓住了分布式系统的核心场景之一，但还可以更全面；而分布式系统间的数据传递安全性，需要通过 “传输加密、身份验证、权限控制” 等多维度机制共同保障。下面我会分别拆解这两个问题，结合实际场景让逻辑更清晰。

一、先明确：你对分布式系统的理解 “对了一半，但不够完整”

你的核心认知 ——“将单服务器无法运行的大型项目拆分重组，多服务器合作服务”—— 是分布式系统的重要应用场景（解决 “性能 / 容量瓶颈”），但分布式系统的设计目标远不止于此。更全面的定义是：
“通过网络连接多个独立节点，协同完成一个或多个任务，最终对外呈现为‘一个整体服务’的系统”，其核心价值包含 3 个维度，你的理解只是其中之一：

核心价值 你的理解是否覆盖 补充说明（结合你的设备数据场景）
1. 突破单机瓶颈 ✅ 部分覆盖 比如你 100 个设备每日 10 亿条数据，单服务器存储 / 计算会撑爆，拆分到多节点后可分摊压力（这是你理解的场景）。
2. 保障高可用 ❌ 未覆盖 若单服务器宕机，整个服务中断；分布式系统中，一个节点故障，其他节点可 “接管任务”（比如 TDengine 的副本机制），避免设备数据无法查询。
3. 弹性扩展 ❌ 未覆盖 若后续设备从 100 个增加到 1000 个，无需重构系统，只需新增服务器节点加入集群，即可动态提升存储 / 计算能力（无需停机扩容）。
4. 降低延迟（可选） ❌ 未覆盖 若设备分布在不同地区，可将数据节点部署在靠近设备的区域（如边缘节点），用户查询时无需跨地域拉取数据，图表加载更快。

简单说：“拆分大项目” 是分布式的 “手段之一”，但不是全部目标—— 即使是 “单服务器能跑的小项目”，为了避免宕机（高可用）或方便后续扩容（弹性扩展），也可能设计成分布式（比如小型电商的后端服务，拆分成用户、订单、支付节点，分别部署在不同服务器）。

二、分布式系统间数据传递的安全性：需从 “5 个关键环节” 保障

分布式系统的节点通过网络传递数据（比如 TDengine 的 MNode 与 DNode 通信、设备数据上传到边缘节点、查询请求从客户端到数据节点），网络传输的 “明文、伪造、篡改” 是核心风险，需针对性防护：

1. 传输层加密：防止 “数据被窃听”

这是最基础的安全措施，通过加密算法将传输的明文数据变成密文，即使被黑客截获，也无法解析内容。

  • 常用方案：TLS/SSL 协议（如 HTTPS 就是 HTTP+TLS），覆盖 TCP 连接的加密（从应用层到传输层的端到端加密）。
  • 实际场景：
    • 你的设备向分布式数据节点上传数据时，用 “MQTTs”（MQTT+TLS）或 “HTTPS” 协议，避免设备的原始数据在公网被窃听；
    • TDengine 集群中，MNode 与 DNode 之间的元数据同步、DNode 间的副本数据同步，可配置 TLS 加密（在taos.cfg中开启enableTls参数），防止集群内部数据被窃取。

2. 身份认证：防止 “假节点混入通信”

确保数据传递的 “双方都是合法节点”，避免黑客伪装成 “假数据节点” 骗取数据，或伪装成 “客户端” 发起非法查询。

  • 常用方案：
    • 双向 TLS 认证（mTLS）：客户端和服务端都需要出示 “数字证书”（由可信机构签发），双方互相验证证书合法性（比 “单向 TLS” 更安全，单向只有服务端验证客户端，双向是双向验证）；
    • 令牌认证（如 JWT、OAuth2）：节点通信时携带 “临时有效令牌”，接收方验证令牌的签名和有效期（适合 API 调用场景，比如你的前端查询 TDengine 数据时，后端先签发 JWT 令牌，前端带着令牌请求数据节点）。
  • 实际场景：TDengine 分布式集群中，新 DNode 加入集群时，需要向 MNode 提交 “集群证书”，MNode 验证通过后才允许其加入，避免恶意节点混入。

3. 数据完整性校验：防止 “数据被篡改”

即使数据加密了，黑客也可能篡改密文（比如把 “设备温度 25℃” 的密文改成乱码），导致接收方解析错误。需通过 “哈希校验” 确保数据未被篡改。

  • 常用方案：
    • 传输数据时，附带该数据的 “哈希值”（如 SHA-256），接收方接收后重新计算哈希值，若与附带值一致，则数据未被篡改；
    • 更安全的方案是 HMAC（带密钥的哈希）：发送方和接收方共享一个密钥，哈希计算时加入密钥，即使黑客篡改数据，也无法生成正确的 HMAC 值。
  • 实际场景：你的设备向数据节点传输 10 万条 / 天的时序数据时，可按 “每 100 条数据” 计算一个 HMAC 值，数据节点接收后验证 HMAC，确保数据在传输中没被篡改。

4. 访问控制与权限管理：防止 “合法节点越权操作”

即使节点身份合法，也需限制其 “能传递 / 访问哪些数据”，避免合法节点（如某个边缘数据节点）获取不属于它的设备数据。

  • 常用方案：基于角色的权限控制（RBAC），给每个节点 / 用户分配 “角色”，角色绑定 “数据访问权限”。
  • 实际场景：在你的分布式系统中，可配置 “设备 A 的数据只能由 DNode1 处理，设备 B 的数据只能由 DNode2 处理”，即使 DNode2 身份合法，也无法请求 DNode1 的设备 A 数据（TDengine 的 “分片 + 权限” 机制就是这么实现的，每个 DNode 只管理自己分片内的数据）。

5. 抗重放攻击：防止 “旧数据被重复利用”

黑客可能截获之前的合法数据（如 “设备启动指令”），然后重复发送给目标节点，导致设备重复执行指令（比如重复上传同一批数据，导致图表数据重复）。

  • 常用方案：
    • 数据中加入 “时间戳 + 随机数”：接收方只处理 “时间戳在有效期内” 且 “随机数未见过” 的数据；
    • 序号机制：每次通信给数据分配一个递增的序号，接收方只处理 “序号比上一次大” 的数据。
  • 实际场景：你的设备上传数据时，每条数据携带 “设备 ID + 时间戳 + 随机数”，数据节点记录已处理过的 “设备 ID + 随机数”，若收到重复的组合，则直接丢弃，避免重放攻击。

三、总结

  1. 关于分布式系统的理解：
    你的 “拆分大项目到多服务器合作” 是正确的，但需补充 —— 分布式的核心是 “多节点协同”，目标包括突破单机瓶颈、高可用、弹性扩展，即使小项目也可能为了高可用设计成分布式。
  2. 关于数据传递安全性：
    核心是 “防窃听、防伪造、防篡改、防越权、防重放”，需结合TLS 加密（传输层）、双向认证（身份）、HMAC 校验（完整性）、RBAC 权限（访问控制）、时间戳 / 随机数（抗重放） 等手段，根据你的设备数据场景（如时序数据、跨节点同步）选择合适的组合方案（比如 TDengine 可直接配置 TLS + 证书认证，无需额外开发）。