4、集群架构设计：主从模式 vs 对等模式、数据一致性、高可用设计思路
好，咱们进入第四章。这一章我打算聊聊集群架构的核心设计思路。
说实话，很多刚接触 ThingsBoard 的朋友，一上来就问我：「到底该用主从还是对等？」
我的回答通常是：别急着选，先搞清楚你的业务场景。你想想看，如果连数据一致性怎么保证、故障转移怎么处理都没想明白，选什么模式都是白搭。
4.1 主从模式：简单可靠，但有单点风险
主从模式，说白了就是「一个老大，一群小弟」。老大负责写数据，小弟们只负责读。
我在项目中遇到过一家做智慧水务的公司，他们刚开始就用的主从。为什么？因为简单。部署起来快，运维也省心。
主从模式的核心特点：
- 一个主节点：处理所有写入请求，比如设备上报数据、规则链执行
- 多个从节点：只处理读取请求，比如仪表盘查询、告警查看
- 数据同步：主节点写入后，异步或同步复制到从节点
嗯，这里要注意。主从模式有个天然缺陷——单点故障。主节点一旦挂了，整个系统就写不了数据了。我曾经帮一家工厂排查过，他们的主节点因为磁盘满了，直接宕机，结果所有设备数据都丢了两个小时。
避坑指南：
我曾经遇到过主从模式下，从节点数据延迟严重的问题。原因是主节点写入压力太大，复制队列积压。解决方案是：给主节点加写缓冲，或者改用半同步复制。
4.2 对等模式：高可用，但复杂度翻倍
对等模式，也叫 P2P 模式。每个节点都是平等的，都能读写。
你想想看，这就像一群合伙人，谁都能拍板。好处是没了单点故障，坏处是——数据一致性怎么保证？
我个人的习惯是，如果业务对数据一致性要求极高，比如金融、医疗场景，我会优先考虑对等模式。但代价是，你得引入分布式协调组件，比如 ZooKeeper 或 Etcd。
对等模式的核心特点：
- 无主节点：所有节点平等，都能读写
- 数据分片：每个节点负责一部分数据，比如按设备 ID 哈希分片
- 一致性协议：常用 Raft 或 Paxos 保证数据一致性
我记得有一次，一个做车联网的客户，他们用了对等模式。结果因为网络分区，两个节点各自为政，数据冲突得一塌糊涂。后来我帮他们引入了 Raft 协议，才解决了这个问题。
我的建议：
如果你团队有分布式系统经验，对等模式是更好的选择。否则，先从主从模式起步，等业务规模大了再迁移。
4.3 数据一致性：CAP 理论的取舍
聊到数据一致性，就绕不开 CAP 理论。说白了就是：一致性、可用性、分区容忍性，三者只能选两个。
在 ThingsBoard 集群里，我一般这样取舍：
| 场景 | 选择 | 原因 |
|---|---|---|
| 设备数据上报 | AP（可用性 + 分区容忍性） | 设备数据可以容忍短暂不一致，但不能丢 |
| 告警规则配置 | CP（一致性 + 分区容忍性） | 配置错了，整个系统可能误报 |
| 仪表盘查询 | AP | 用户看到旧数据几秒钟，问题不大 |
嗯，这里有个坑。很多人以为用了对等模式，数据就自动一致了。其实不是。你想想看，如果没有分布式锁或事务机制，两个节点同时修改同一条数据，结果会怎样？
我曾经在项目中踩过这个坑。两个规则链同时更新设备属性，结果一个覆盖了另一个。后来我引入了 乐观锁，用版本号来控制并发写入。
避坑指南：
我曾经遇到过数据同步延迟导致告警误报的问题。比如设备离线了，但主节点还没同步到从节点，从节点以为设备在线。解决方案是：告警查询走主节点，或者加一个「数据新鲜度」校验。
4.4 高可用设计思路：从单点到集群
高可用，说白了就是「别让一个点坏了，拖垮整个系统」。
我个人的习惯是，从三个层面来设计高可用：
- 计算层高可用：ThingsBoard 服务本身做多实例部署，用负载均衡器分发请求
- 数据层高可用：数据库、消息队列、缓存都做主从或集群
- 网络层高可用：多网卡、多线路、DNS 故障转移
你想想看，如果只做了计算层高可用，数据库挂了，照样白搭。反过来，数据库做了主从，但 ThingsBoard 服务只有一个实例，那也扛不住流量。
一个典型的高可用架构：
客户端
↓
负载均衡器（Nginx/HAProxy，主备）
↓
ThingsBoard 实例（3个节点，对等模式）
↓
PostgreSQL（主从复制）
↓
Redis（哨兵模式）
↓
Kafka（集群模式，3个broker）我记得有一次，一个客户的生产环境，负载均衡器挂了。因为他们只部署了一个 Nginx 实例。后来我帮他们加了一个备用 Nginx，用 Keepalived 做 VIP 漂移，才解决了这个问题。
我的建议：
高可用不是一蹴而就的。先保证核心链路的高可用，比如设备数据上报和告警。其他非核心功能，比如历史数据查询，可以容忍短暂不可用。
4.5 总结：选型建议
好了，说了这么多，我最后给个总结性的建议：
- 小规模（< 1000 设备）：单机就够了，别折腾集群
- 中等规模（1000 - 10000 设备）：主从模式，简单可靠
- 大规模（> 10000 设备）：对等模式，但要做好数据一致性设计
- 高可用要求极高：不管规模大小，都上对等模式 + 多副本
嗯，最后提醒一句：架构设计没有银弹。你想想看，再好的架构，如果运维跟不上，也是白搭。所以，选一个你团队能驾驭的模式，比选一个「理论上最好」的模式更重要。
下一章，我会带你手把手搭建一个 ThingsBoard 对等模式集群。到时候咱们再细聊具体的配置和踩坑经验。