分布式系统基础：CAP理论、分布式通信模式、时钟同步
好，咱们进入正题。
做飞控系统，尤其是分布式飞控，你绕不开这三个东西：CAP理论、通信模式、时钟同步。
我当年第一次把飞控拆成多个节点时，就踩了CAP的坑。当时想当然地以为所有数据都得强一致，结果系统一丢包就卡死。后来才明白——分布式系统里，没有银弹。
1. CAP理论：你只能选两个
CAP理论是分布式系统的“不可能三角”。它说：
- C（一致性）：所有节点看到的数据是一样的。
- A（可用性）：每个请求都能得到响应，不保证数据最新。
- P（分区容错性）：网络断了，系统还能继续干活。
你最多只能同时满足两个。网络分区是必然的，所以P必须选。剩下的，你只能在C和A之间二选一。
飞控场景下的选择
我建议：控制指令走CP（一致性+分区容错），传感器数据走AP（可用性+分区容错）。
为什么？控制指令错了会炸机，必须一致。传感器丢一帧没关系，系统还能用旧数据撑着。
举个例子。我做过一个四旋翼，两个飞控板通过以太网互联。有一次网线松了，一个板子收不到另一个的IMU数据。如果当时我选了CP模式，系统会直接停摆。但我用了AP模式，每个板子用自己的IMU数据继续飞，虽然精度下降，但至少没炸。
注意：别在飞控里搞“最终一致性”。最终一致性意味着“最终会一致”，但飞控需要的是“现在就得一致”。
2. 分布式通信模式
通信模式决定了节点之间怎么说话。主要有两种：点对点和发布/订阅。
2.1 点对点（Point-to-Point）
说白了就是“私聊”。一个节点直接给另一个节点发消息。
- 优点：延迟低，实现简单。
- 缺点：耦合紧，改一个节点得改一堆。
我在早期项目里用过UDP点对点。两个飞控板之间传心跳，简单粗暴。但后来加了第三个节点，代码就乱成一锅粥了。
2.2 发布/订阅（Pub/Sub）
这是“广播”。一个节点发消息，所有感兴趣的节点都能收到。
- 优点：解耦，扩展性好。
- 缺点：需要中间件，延迟略高。
DDS用的就是发布/订阅模式。你想想看，一个IMU节点发布姿态数据，飞控、导航、记录仪各取所需，多清爽。
我的经验：在飞控里，控制指令用点对点，传感器数据用发布/订阅。这样既保证了指令的实时性，又让数据分发灵活。
3. 时钟同步
分布式系统里，每个节点都有自己的时钟。时间不同步，数据就乱套了。
比如，两个IMU节点同时采集数据，但时间戳差了10毫秒。融合出来的姿态，误差能让你怀疑人生。
3.1 为什么需要时钟同步？
- 数据融合：多个传感器的数据必须对齐时间。
- 事件排序：知道哪个指令先到，哪个后到。
- 故障诊断：定位问题发生的时间点。
3.2 常用方法
| 方法 | 精度 | 适用场景 |
|---|---|---|
| NTP | 毫秒级 | 地面站、日志记录 |
| PTP（IEEE 1588） | 微秒级 | 飞控内部节点 |
| GPS PPS | 纳秒级 | 多无人机协同 |
我个人习惯用PTP。精度够，实现也不复杂。GPS PPS虽然准，但依赖卫星信号，室内就废了。
避坑指南：我曾经在PTP配置里忘了设置主时钟优先级，结果两个节点互相抢着当主时钟，时间越同步越乱。后来加了优先级配置，才稳定下来。
4. 知识体系总览
下面这张图，把本章的核心逻辑串起来了。你看一眼，心里就有数了。
嗯，这张图把CAP、通信模式、时钟同步串起来了。你记住：CAP是指导思想，通信模式是骨架，时钟同步是血液。三者缺一不可。
小技巧：在实际项目中，先用CAP理论定基调，再选通信模式，最后配时钟同步。顺序别搞反了。
好了，这一章就到这儿。分布式系统的基础打牢了，后面讲DDS集成时，你才能理解为什么DDS能解决这些问题。