mq消息队列的应用与思考点

rabbitMq:
1.如何保证顺序接收的消息
采用单机一个一个消费
多机场景，需要状态验证，验证失败返回mq接收失败，让其后续重发。
2.如何保证消费者挂掉重启后，不去再重复做消费的业务处理，比如重复下单
1.业务处理记录mq传来的唯一标识id，每次先校验此id是否处理成功
2.业务处理可以是redis.set，set处理只会覆盖key
3.采用第三方中介件，比如redis每次保存记录消息中标识id，进入时校验id

2.2 分布式系统中的事务问题，如果A调用B，如何保证B不被重复消费，因为B可能超时，A会不断重试，
扣库存扣一个库存，客户端可能多次重试。扣库存B超时了，A重试一次，实际下游B已经扣减成功，我们采用上游防止A重试。
A生成订单号，利用DB唯一索引，做抢占锁用，抢占到了去调用B扣减库存。

3.如何保证消费的可靠性传输
以下三个不丢数据场景解析
3.1 生产者丢数据
从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm（事务确定）模式来确保生产者不丢消息。
3.2 消息队列丢数据
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。万一在持久化时丢了，事务返回ack失败，让生产者重新发送。
3.3 消费者丢数据
采用手动确认消息设置，即消费者处理成功后返回给mq确定删除。

4.为什么引入消息队列后，系统的可用性下降。
系统可用性降低:万一mq挂了；
系统复杂性增加:要花时间考虑事务一致性问题、如何保证消息不被重复消费（传唯一标识），如何保证保证消息可靠传输（三个场景不丢数据）

5.引入消息队列后优点。
5.1 解耦
房屋下架业务，房屋签约自动下架，房源管理手动下架，还有超时定时下架，系统间耦合性太强。
采用生产者消费者业务解耦，比如房屋签约业务，需要自动把房源下架，可以吧下架业务独立A，这样签约业务可以使用A,手动，定时下架或其他业务也可以使用A。
A成为独立服务，自己维护自己代码。
5.2 异步
主业务只做自己的事情，非必要的业务逻辑以异步的方式运行，加快响应速度。
5.3 削峰限流
系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。
5.4 分流
消息队列可以被多台服务分流消费处理。

你是否：
- 发送RabbitMQ消息时经常生产速率下降导致服务响应时间变慢？
- 经常发现消息积压使得性能变慢却又感觉无法快速恢复？
- 压测过程中老感觉性能瓶颈在MQ?

为你带来新鲜出炉的：
- RabbitMQ 流控规则分析 - http://confluence.corp.imdada.cn/pages/viewpage.action?pageId=12535835
- RabbitMQ 流控性能分析 & 最佳实践 - http://confluence.corp.imdada.cn/pages/viewpage.action?pageId=12540536

kafka
参考：
https://www.cnblogs.com/williamjie/p/9481780.html