分布式消息队列：如何保证消息的顺序性

数据的顺序性

（1）rabbitmq保证数据的顺序性

若是存在多个消费者，那么就让每一个消费者对应一个queue，而后把要发送 的数据全都放到一个queue，这样就能保证全部的数据只到达一个消费者从而保证每一个数据到达数据库都是顺序的。
rabbitmq：拆分多个queue，每一个queue一个consumer，就是多一些queue而已，确实是麻烦点；或者就一个queue可是对应一个consumer，而后这个consumer内部用内存队列作排队，而后分发给底层不一样的worker来处理

（2）kafka保证数据的顺序性

kafka 写入partion时指定一个key，列如订单id，那么消费者从partion中取出数据的时候确定是有序的，当开启多个线程的时候可能致使数据不一致，这时候就须要内存队列，将相同的hash过的数据放在一个内存队列里，这样就能保证一条线程对应一个内存队列的数据写入数据库的时候顺序性的，从而能够开启多条线程对应多个内存队列

kafka：一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，而后N个线程分别消费一个内存queue便可

MQ积压几百万条数据怎么办？

这个是咱们真实遇到过的一个场景，确实是线上故障了，这个时候要否则就是修复consumer的问题，让他恢复消费速度，而后傻傻的等待几个小时消费完毕。这个确定不能在面试的时候说吧。

一个消费者一秒是1000条，一秒3个消费者是3000条，一分钟是18万条，1000多万条

因此若是你积压了几百万到上千万的数据，即便消费者恢复了，也须要大概1小时的时间才能恢复过来

通常这个时候，只能操做临时紧急扩容了，具体操做步骤和思路以下：

1. 先修复consumer的问题，确保其恢复消费速度，而后将现有cnosumer都停掉
2. 新建一个topic，partition是原来的10倍，临时创建好原先10倍或者20倍的queue数量
3. 而后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费以后不作耗时的处理，直接均匀轮询写入临时创建好的10倍数量的queue
4. 接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
5. 这种作法至关因而临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据
6. 等快速消费完积压数据以后，得恢复原先部署架构，从新用原先的consumer机器来消费消息

这里咱们假设再来第二个坑

假设你用的是rabbitmq，rabbitmq是能够设置过时时间的，就是TTL，若是消息在queue中积压超过必定的时间就会被rabbitmq给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。

这个状况下，就不是说要增长consumer消费积压的消息，由于实际上没啥积压，而是丢了大量的消息。咱们能够采起一个方案，就是批量重导，这个咱们以前线上也有相似的场景干过。就是大量积压的时候，咱们当时就直接丢弃数据了，而后等过了高峰期之后，好比你们一块儿喝咖啡熬夜到晚上12点之后，用户都睡觉了。

这个时候咱们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，而后从新灌入mq里面去，把白天丢的数据给他补回来。也只能是这样了。

假设1万个订单积压在mq里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那1000个订单给查出来，手动发到mq里去再补一次

而后咱们再来假设第三个坑

若是走的方式是消息积压在mq里，那么若是你很长时间都没处理掉，此时致使mq都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉全部的消息。而后走第二个方案，到了晚上再补数据！

更多系列文章

分布式消息队列：如何保证消息队列的高可用

分布式消息队列：如何保证消息不被重复消费

分布式消息队列：如何保证消息的可靠性传输

分布式消息队列：如何保证消息的顺序性

最后

后续会持续更新分布式知识，你们以为不错能够点个赞在关注下，之后还会分享更多文章！