一 rabbit & kafka选型对比

这里自然而然的分为三类
第一代 rabbitmq 是咱们熟悉的mq，很多企业在使用
第二代 kafka 部分一线互联网公司在使用。
第三代 pulsar 未来将会主流。
rabbit & kafka参数对比
参数列表

参数总结

1. 从参数上看，中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用Kafka是很好的选择
2. 如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

kafka&rabbit高可用对比
rabbit我前面说了属于第一代mq指望高可用别太指望了，但是我还会给出对比。kafka毕竟是第二代，当然很常规的支持 高可用 分布式的。

二 RabbitMq 如何保证高可用

2.1 普通集群

多台机器上启动多个rabbitmq实例，每个机器启动一个。但是创建的queue，只会放在一个rabbtimq实例上，然后每个实例仅仅只同步queue的元数据。假设客户端消费queue，请求的是没有数据记录的实例，那么他会去转发请求有数据的实例。
缺点：

1. 没有数据分片，它是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
2. 如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。
3. 没有什么所谓的高可用性可言，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作

   2.2 镜像集群

   

这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
好处在于，你任何一个机器宕机，别的机器都可以用。坏处在于，1.性能开销大：消息同步所有机器，导致网络带宽压力和消耗很重！1.没有扩展性：假设某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue。

三 kafka高可用

分布式
每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据。
HA**

1. replica副本机制：每个partition的数据都会同步到其他机器上，形成自己的多个replica副本。
2. 读写leader：然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。
   1. 写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
   2. 读leader，只有一个消息已经被所有follower都同步成功返回ack的时候，这个消息才会被消费者读到。
   3. 要是你可以随意读写每个follower，那么就要care数据一致性的问题，系统复杂度太高，很容易出问题。kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才可以提高容错性。
3. 高可用：如果某个broker宕机，那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性了。

高可用总结
rabbitmq是初代传统的mq ，我们不能指望他的高可用性有多好，只能说，不合适高性能大数据的场景。

四 消息幂等性

kafka&rabbit消息幂等对比
消息的幂等其实是在业务上控制的，虽然kafka提供了幂等操作，但是这不是很好的注意（降低了系统吞吐），一般从业务上具体处理，比如插入数据 ，设置唯一约束。等
幂等性总结
这个点其实和mq关系不大。不做过多对比。 我们一般搞个去重表去重。或者在内存或者redis里搞个去重记录。

五 Rabbit消息可靠性

生产者丢数据
生产者将数据发送到rabbitmq的时候，可能数据就在半路给搞丢了，因为网络啥的问题，都有可能。
事务功能：可以选择用rabbitmq提供的事务功能，就是生产者发送数据之前开启rabbitmq事务（channel.txSelect），然后发送消息，如果消息没有成功被rabbitmq接收到，那么生产者会收到异常报错，此时就可以回滚事务（channel.txRollback），然后重试发送消息；如果收到了消息，那么可以提交事务（channel.txCommit）。但是问题是，rabbitmq事务机制一搞，基本上吞吐量会下来，因为太耗性能（了解）。
confirm模式：可以开启confirm模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了。如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。
事务机制和cnofirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，你发送个消息之后就可以发送下一个消息，然后那个消息rabbitmq接收了之后会异步回调你一个接口通知你这个消息接收到了。
所以一般在生产者这块避免数据丢失，都是用confirm机制的。

rabbitmq丢数据
rabbitmq自己弄丢了数据，这个你必须开启rabbitmq的持久化，就是消息写入之后会持久化到磁盘，哪怕是rabbitmq自己挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢。除非极其罕见的是，rabbitmq还没持久化，自己就挂了，可能导致少量数据会丢失的，但是这个概率较小。
设置持久化有两个步骤，第一个是创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据；第二个是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行，rabbitmq哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的数据。
而且持久化可以跟生产者那边的confirm机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者ack了，所以哪怕是在持久化到磁盘之前，rabbitmq挂了，数据丢了，生产者收不到ack，你也是可以自己重发的。

哪怕是你给rabbitmq开启了持久化机制，也有一种可能，就是这个消息写到了rabbitmq中，但是还没来得及持久化到磁盘上，结果不巧，此时rabbitmq挂了，就会导致内存里的一点点数据会丢失。

消费端丢数据
rabbitmq如果丢失了数据，主要是因为你消费的时候，刚消费到，还没处理，结果进程挂了，比如重启了，那么就尴尬了，rabbitmq认为你都消费了，这数据就丢了。
这个时候得用rabbitmq提供的ack机制，简单来说，就是你关闭rabbitmq自动ack，可以通过一个api来调用就行，然后每次你自己代码里确保处理完的时候，再程序里ack一把。这样的话，如果你还没处理完，不就没有ack？那rabbitmq就认为你还没处理完，这个时候rabbitmq会把这个消费分配给别的consumer去处理，消息是不会丢的。

六 Kafka 消息可靠性

生产者会不会丢数据
如果按照上述的思路设置了ack=all，一定不会丢，要求是，你的leader接收到消息，所有的follower都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。
kafka丢数据
这块比较常见的一个场景，就是kafka某个broker宕机，然后重新选举partiton的leader时。大家想想，要是此时其他的follower刚好还有些数据没有同步，结果此时leader挂了，然后选举某个follower成leader之后，这就丢了一些数据啊。
一般是要求起码设置如下4个参数：

1. 给这个topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本
2. 在kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才能确保leader挂了还有一个follower吧
3. 在producer端设置acks=all：这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了
4. 在producer端设置retries=MAX（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了

消费端丢数据
唯一可能导致消费者弄丢数据的情况，就是说，你那个消费到了这个消息，然后消费者那边自动提交了offset，让kafka以为你已经消费好了这个消息，其实你刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。
这不是一样么，大家都知道kafka会自动提交offset，那么只要关闭自动提交offset，在处理完之后自己手动提交offset，就可以保证数据不会丢。但是此时确实还是会重复消费，比如你刚处理完，还没提交offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。

可靠性总结：
消息消费不丢失，这块我们一般不仅仅单独的考虑中间件解决，很多时候我们会结合数据库，消息落库，等一整套方案解决。所以通过对比，kafka和rabbitmq都能保证数据不丢失，不分伯仲。

七 消息防丢失解决方案

7.1 消息落库对消息状态进行打标

1. 生产者将业务数据和消息入库，并设置信息状态为0，即初始待投递
2. 生产者将消息发送至broker
3. broker向生产者发送确认
4. 生产者收到broker确认后修改消息状态为1，即消息投递成功
5. 系统定时任务扫描未投递成功的消息
6. 生产者将为成功投递的消息重发给broker，并记录重发次数
7. 当重发次数大于3时，此时修改消息状态为2，即投递失败。对于投递失败的消息启用补偿机制或人工去处理失败消息

存在问题

在高并发场景下，每次要对业务数据和消息数据入库，数据库会遇到瓶颈。故采用下面的消息的延迟投递，做二次检查，回调确认的方案。

7.2 消息的延迟投递，做二次检查，回调确认

1. 先将业务数据入库
2. 生产者第一次向broker发送消息
3. 生产者第二次向broker发送check延迟消息，一般按自己业务设为2min-5min.
4. Consumer从messageQueue获取消息
5. Consumer成功消费消息后，向broker发送确认消息(设其队列名为ConsumerQueueConfirm)
6. CallbackService监听ConsumerQueueConfirm，并将成功消费的消息入库MSG DB
7. 同时CallbackService监听checkdetailQueue,并去MSG DB查询该消息是否被成功消费
8. 若查询不到check message，则CallbackService向ProducerService发送RPC请求，让其重发消息，设置重发次数，达到重发次数后，设置其为消费失败
9. 人工处理因网络闪断或者业务问题产生的未成功消费消息，系统消息投递几乎达到100%

注意

1. 互联网大厂一般不会考虑分布式事务，都用补偿机制。
2. 在高并发下，少做一次数据库持久操作，提高系统处理能力，故将业务和消息的持久化拆开。

八 Rabbit消息顺序性

无序的

有序的
在一个队列里面，rabbitmq的消息是严格顺序的，按照先进先出

拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实是麻烦点；或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理

九 kafka 消息顺序性

无序的

有序的
在同一个partition中消息是有序的，但是生产者put到Kafka中数据会分布在不同的partition中，所有总体是无序的。

一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可

顺序性消费总结
其实这个不比较也是知道的，消息队列不能保证顺序，还谈什么消息队列。所以这个比较没有太多出入。

十消息堆积

kafka&rabbit消息堆积对比
rabbit消息堆积
他是基于内存的,有限持久，当发生消息堆积（内存快要满的时候），就会触发限流自我保护机制，阻塞生生产者，导致mq不可用
kafka消息堆积
他是基于磁盘的，并且天然可以回溯到任意的offset，所以支持无限堆积（磁盘容量很大的），一般不会导致mq不可用。
消息堆积总结
这块没办法，传统的rabbitmq是不占优势的。