高并发之消息队列
简单模型
比如一个接口处理短信发送，如果没处理完就可以放入消息队列；然后等待接口处理，如果接口处理短信发送失败则可以再次放入消息队列，减少尝试的次数和占用的线程，再次进行处理。
消息队列的特性
- 业务无关：只做消息分发
- FIFO：先投递先到达
- 容灾：节点的动态增删和消息的持久化
- 性能：吞吐量提升，系统内部通信效率提高
为什么需要消息队列
- 【生产】和【消费】的速度或稳定性等因素不一致
举几个例子
- 业务系统触发短信发送申请，但短信发送模块速度跟不上，需要将来不及处理的消息暂存一下，缓冲压力。就可以把短信发送申请丢到消息队列，直接返回用户成功，短信发送模块再可以慢慢去消息队列中取消息进行处理。
- 调远程系统下订单成本较高，且因为网络等因素，不稳定，攒一批一起发送。调远程系统下订单成本较高，且因为网络等因素，不稳定，攒一批一起发送。
- 任务处理类的系统，先把用户发起的任务请求接收过来存到消息队列中，然后后端开启多个应用程序从队列中取任务进行处理。任务处理类的系统，先把用户发起的任务请求接收过来存到消息队列中，然后后端开启多个应用程序从队列中取任务进行处理。
消息队列的好处
- 业务解耦
简单讲就是一个事务只关心核心的流程，而需要其它系统但不是那么重要的事情有通知即可，无需等待结果。基于消息模型，关心的是通知，而不是处理。 - 最终一致性
要么都成功，要么都失败。比如银行转账，A扣钱，B加钱，如果A成功B失败，A失败B成功，则都会全部回滚。 - 广播
如果没有消息队列；每次接入，我们都要联调一次新接口；有了消息队列，我们只需要关系消息是否送达消息队列，新接入的接口订阅相关的消息，自己做处理就可以了。 - 错峰与流控
上下游对于事物的处理能力是不同的。前端和后端数据库，数据库的性能肯定不能追上前端，前端上千万并发量，数据库是承受不住的。利用中间系统转储中间内容，在下游又能力处理的时候进行处理是一套比较通用的方式。
Kafka和RabbitMQ
Kafka
kafka讲解详细见本人博客的分类kafka笔记
RabbitMQ
-
RabbitMQ讲解详细见本人博客的分类RabbitMQ笔记（待整理）