Kafka 和 RocketMQ 如何进行消息复制

如何保证消息不丢？

客户端配合请求确认机制，来保证服务端确实收到了消息；服务端通过集群中多节点的消息复制和持久化来保证消息不丢失。

消息复制面临什么问题？

CAP 定理：一致性、可用性、分区容错性，三者不可兼得。

消息队列中的数据一致性，包括了两方面，一是消息在各个节点都存在，不会丢消息，二是消息在各个节点的顺序都一致。如果要保证这样的一致性，必须要采用主-从复制的方式。

RocketMQ 如何做？

老的方案：主从复制，主当掉之后就无法生产消息了，但是可以到从节点上继续消费消息

新的方案：引入 Deldger 完成消息复制工作。Deldger 要求消息写入半数以上节点时才能返回给客户端成功的响应。因此，使用了 Deldger 之后，集群至少是 3 节点的，并且只能保证一个节点宕机时，服务继续可用。如果两个节点宕机，即使还剩一个节点，服务也无法正常使用，资源利用率较低。而且由于需要等消息复制到半数节点，性能上也会有所降低。

Kafka 如何做？

Kafka 的 Broker 不分主从，Broker 只是分区副本的容器，复制的基本单位是分区。分区的多个副本之间是一主多从的关系。kafka 相对而言更为灵活，提供了相关的配置项来让用户自己配置一份消息要复制几份就算写入成功。保持数据同步的副本 —— ISR(In Sync Replicas)。

kafka 依赖 zookeeper 来监控每个分区的多个节点，发现某个分区的主节点宕机就会重新选举出新的主节点，主节点只会从 ISR 节点中选举。

痕迹
没有过去，就没法认定现在的自己