消息队列和分布式消息队列

分析系统现状不足

现状：目前的异步是通过本地的线程池实现的
1） 无法集中限制（分布式），只能单机限制
解决方案：在一个集中的地方去管理下发任务
2） 任务由于是放在内存中执行的，可能会丢失
解决方案：把任务放在一个可以持久化存储的硬盘
3）优化：如果你的系统功能越来越多，长耗时任务越来越多，系统会越来越复杂
服务拆分（应用解耦）：可以把长耗时，消耗很多的任务把它单独抽成一个程序，不要影响主业务
解决方案：可以有一个中间人，让中间人帮我们去连接两个系统（比如核心系统和智能生成业务）

中间件

连接多个系统，帮助多个系统紧密协作的技术（或者组件）
比如：Redis,消息队列，分布式存储Etcd

消息队列

什么是消息队列？

存储消息的队列。
存储：存数据
消息：某种数据结构。比如字符串，对象，二进制数据，JSON等等
队列：先进先出的数据结构

应用场景

在多个不同的系统，应用之间实现消息的传输（也可以存储），不需要考虑传输应用的编程语言，系统，框架等等

消息队列的模型

生产者，消费者，消息，消息队列

为什么不直接传输，而要用消息队列？

生产者不用关心你的消费者要不要消费，什么时候才消费，我只需要把东西给消费队列，我的工作就算完成了，生产者和消费者实现了解耦，互不影响

为什么要用消息队列？

1）异步处理
生产者发送完消息之后，可以继续去忙别的，消费者想什么时候消费都可以，不会产生阻塞
2）削峰填谷
先把用户的请求放到消息队列中，消费者可以按照自己的需求，慢慢去取
原本：12 点时来了 10 万个请求，原本情况下，10万个请求都在系统内部立刻处理，很快系统压力过大就宕机了。
现在：把这 10万个请求放到消息队列中，处理系统以自己的恒定速率（比如每秒 1 个）慢慢执行，从而保护系统、稳定处理

消息队列的缺点？

增加成本（开发，维护，部署），消息丢失，顺序性，重复消费，数据一致性（分布式系统需要考虑）

分布式消息队列

分布式消息队列的优势？

1）数据持久化：可以把消息集中存储到硬盘里，服务器重启就不会丢失
2）可扩展性：可以根据需求，随时增加（或减少）节点，继续保持稳定的服务
3）应用解耦：可以连接各个不同的语言，框架开发的系统，让这些系统能够灵活传输读取数据
应用解耦的优点：
以前，把所有功能放到同一个项目中，调用多个子功能时，一个环节出错，系统就整体出错

使用消息队列进行解耦：

1. 一个系统挂了，不影响另一个系统
2. 系统挂了并恢复后，仍然可以取出消息，继续执行业务
3. 只要发送消息到队列，就可以立即返回，不用同步调用所有系统，性能更高

4）发布订阅：
如果一个非常大的系统要给其他子系统发送通知，最简单直接的方式是大系统直接依次调用子系统
问题：

1. 每次发通知都要调用很多系统，很麻烦，有可能失败
2. 新出现的项目无法得到通知

解决方案：大的核心系统始终往一个地方（消息队列）去发消息，其他的系统都去订阅这个消息队列（读取消息队列中的消息）
打个比喻，老板（发布者）要通知一件事情给员工（消费者），方式1 ：给员工依次发通知；方式2 ：建个群（消息队列）发通知。方式一不仅非常麻烦耗时，有时候网不好（服务器压力大时）还发不出去。方式2呢就是老板只需要把消息发送到群里（消息队列），员工打开查看即可。

消息队列应用场景

1. 耗时的场景（异步）
2. 高并发场景（异步，削峰填谷）
3. 分布式系统协作（跨团队，跨业务协作，应用解耦）
4. 强稳定性的业务（比如金融业务，持久化，可靠性，削峰填谷）

主流分布式消息队列选型

主流技术

1. activemq
2. rabbitmq
3. kafka
4. rocketmq
5. zeromq
6. pulsar(云原生)
7. Apache InLong(Tube)

技术对比
技术选型指标：

• 吞吐量：IO，高并发
• 时效性：类似延迟，消息的发送，到达时间
• 可用性：系统可用的比率
• 可靠性：消息不丢失，功能正常完成

由此看来RabbitMQ不仅应用广泛，而且易于学习，下期分享RabbitMQ入门实战