消息中间件相关(三)

如何保证消息的顺序性呢?

顺序错乱的场景：

1.rabbitMQ：一个queue，多个consumer

2.kafka：一个topic，一个partition，一个consumer，内不是多线程

如何保证顺序性消费？

1.rabbitMQ：拆分多个queue，每个queue一个consumer，就是多一些queue，这个比较麻烦；或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列排队，然后分发到底层不同的worker来处理

2.kafka：一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存的queue

如何解决消息队列的延时以及失效问题?消息队列满了怎么处理？有几百万消息持续积压几小时怎么解决？下面我们结合场景说说。

1.大量消息在mq里积压了几个小时还没解决。 假如积压了几百上千万条数据，一个消费者一秒1000条，一秒三个就是3000条，一分钟就是18W，1000+W条；所以即使你消费者恢复了，也需要大概一个小时的时间才能恢复。 遇到这种情况我们只能紧急扩容了：

1>先修复consumer问题，确保其消费数据速度恢复，然后全部停掉；

2>新建一个topic，partition是原来的十倍，临时建立好原先十倍或者二十倍的数量；

3>然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压数据，消费之后不做耗时的处理，然后直接均匀轮询的写入临时建立好的10倍数量的queue

4>接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时的queue的数据

5>这种做饭相当于临时将queue资源和consumer资源扩大到10倍，以正常的10倍速度来消费数据 6>等快消费完积压数据之后，恢复原先的架构部署

再如： 如果是使用的rabbitMQ，可以设置过期时间，如果消息在queue中积压超过一定的时间就会被清理掉。这样是直接把数据搞丢。遇到这种情况只能在用户都休息了，写程序一点一点的吧数据找回来再写入mq中

让你设计一个中间件，你会如何去设计呢？

1>消息队列的高可用： 参照kafka的设计理念多个broker，一个broker是一个节点，每个broker对应一个partition，一个topic HA机制，多个副本，自动选举leader

2>消息不被重复消费： 比如生成全局唯一ID

3>如何保证消息不丢： 当然是在网络正常的情况下，可以参考rabbitMQ的confirm和事务机制，还有kafka的参数设置来保证消息不丢失

4>消息的顺序性： 参照kafka一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可 或者参照rabbitMQ拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实是麻烦点；或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理

转载于:https://my.oschina.net/Pirvate/blog/3021352