Kafka RabbitMQ 选择（二）
RabbitMQ可靠性
我们通过前文知道，RabbitMQ的队列分为master queue和mirror queue，mirror queue 在master queue宕机之后，会被提升为master queue，如下图所示。
队列A的consumer在消费的时候，机器宕机，此时客户端和服务端分别做如下动作：
- 服务端：把mirror queue提升为master queue
- 客户端：连接到新的master queue 所在的节点进行消费或者生产
当master queue 所在节点宕机后，其正在被消费的消息的相关信息全部丢失，即服务端不知道消费者对那一瞬间消费的消息是否进行了ACK，所以在mirror queue被提升为master queue时，会把宕机前正在进行消费的的消息全部重新发送一遍，即客户端重连后，消息可能被重复消费，这个时候就必须依靠应用层逻辑来判断来避免重复消费。
在持久化方面，RabbitMQ的master queue每次收到新消息后，都会立刻写入磁盘，并把消息同步给mirror queue。假设在master queue 收到消息后，消息未同步到mirror queue 之前master queue 宕机，则此时mirror queue中就没有刚刚master queue收到的那条消息，当这个mirror queue被提升为master queue时，消费者连接到新的master queue上进行消费时就丢了一条消息。所以，RabbitMQ也会丢消息，只不过这个丢消息的概率非常低。
Kafka可靠性
我们知道Kafka中的每个队列叫做Topic，一个Topic有多个主分片和副分片，当主分片所在机器宕机后，服务端会把一个副分片提升为主分片，如下图所示。
服务端和客户端会有如下动作：
- 服务端：把副分片提升为主分片
- 客户端：连接到新的主分片
Kafka同样有主从同步，所以也必定存在与RabbitMQ同样丢消息的问题。但是Kafka的每个客户端保存了读取消息的偏移信息，故当一个主分片宕机后，Kafka客户端可以从副分片相应位移后继续消费，不会有重复消费的情况。
持久化方面，Kafka默认把消息直接写文件，但是由于操作系统的cache原因，消息可能不会立马写到磁盘上，这个时候就需要刷新文件到磁盘。由于刷新文件到磁盘是一个比较耗时的操作，故Kafka提供了两种不同的刷新配置：
#每接收多少条消息刷一下磁盘
log.flush.interval.messages=10000
#每隔多少ms刷一下磁盘
log.flush.interval.ms=1000
我们完全可以把log.flush.interval.messages设置为1，这样Kafka就能在持久化方面达到和RabbitMQ同样的安全级别。
但是Kafka集群依赖ZK，如上图所示，所以对于Kafka稳定性的评估必须考虑ZK集群的稳定性，而一般我们认为任何分布式集群的稳定性都小于1，故两个集群的串联稳定性会下降一些，维护更复杂一些，这点没有RabbitMQ有优势。
总结
其实好多开源组件随着时间推移，往往都进行了各种改进。就比如Kafka虽然是为了日志而生，给人第一印象是容易丢消息，但是经过这么多年的改进，其可靠性可能并不逊色RabbitMQ了，只需要你根据不同的业务场景配置不同的配置参数，即可达到适合自己的安全级别。
- 从吞吐量上看，在不要求消息顺序情况下，Kafka完胜；在要求消息先后顺序的场景，性能应该稍逊RabbitMQ（此时Kafka的分片数只能为1）。
- 从稳定性来看，RabbitMQ胜出，但是Kafka也并不逊色多少。
