分布式系统CAP原则在项目中的实战

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。由于业务背景不要求数据强一致性，因此我们选择AP，牺牲强一致性，选择最终一致性。

可用性（Availability）

分布式系统对比LAMP架构的优点之一是支持处理能力无限扩展。

架构实现：mqtt-gateway是整个分布式系统的流量入口，gateway层根据一致性hash策略，把流量转发到每个group。group是对gateway可见的最小处理单元，group内部根据某个业务key的hash策略把流量分配到每个node节点，实现流量的二次分治。对于每个group的node之间数据同步问题，我们将在下面的一致性设计章节介绍。

技术实现：我们使用zk管理的group、node的树形关系，支持自定义虚拟分组数，保证hash环尽可能平衡。group内部的流量分治我们使用的RocketMQ的RocketMQSelector机制，根据某个业务key算出hash，由RocketMQ负责转发到指定的Topic、Broker、Queue，RocketMQ的Consumer根据Topic、Broker、Queue可以确定消息的消费范围，实现根据hash分发的效果。

风险点：
1.zk组件在失效转移时会有重新选主过程，选主时不能对外提供服务，这会降低服务的可用性；
2.根据RocketMQSelector机制进行hash分发，如果某个Consumer出现消费比较慢的场景，则它负责的车辆数据都不是最新的（优点：这种设计可以减少查询的跳转次数，后续一致性设计时会提及）

敲黑板：group的新增保证了系统的横向扩展能力，node之间的数据同步保证系统的可用性（每个group的node节点拥有整个group的全部知识）。

一致性（Consistency）

最终一致性针对的是group内部之间的数据同步，我们需要保证的是group下的任一node在一定时间内会拥有整个group的全部知识（每个node都可以独当一面）。

group管理node节点时，第一个注册到group的node节点被称为primary，其他节点被称为second。如果primary出现失效，group踢出失效primary，下一个最新注册到group的node节点被选为primary。

node之间数据同步有两种场景：
1.group根据某个业务key的hash计算出流量转发到second节点，second节点收到后使用scuttlebutt组件（gossip协议的一种实现）同步到primary节点，primary再使用scuttlebutt同步到其他的second节点（为了提高scuttlebutt的同步效率，每个group下的node节点不建议超过3个）；

2.group根据某个业务key的hash计算出流量转发到primary节点，primary节点收到负责向所有second节点同步数据。