- 日志与消费队列
- 消息队列的应用价值
- 数据集成于系统解耦
- 异步处理与事件驱动
- 流量削峰
- 事务消息与分布式事务的最终一致
- 从历史看消息队列的价值演化
思考手上的工作，找到他的价值和定位，将价值最大化
1. 日志和消息队列
日志的应用目标：它记录了什么时间发生了什么事情。
由于日志【按时间天生有序】的特性，解决了分布式系统中的两个重要问题：修改操作的顺序和数据分发，这为并发更新的一致性和副本复制提供了基础。将协商出一致的修改操作顺序写入日志，，利用日志做修改操作的“数据分发”，使得各副本能够在本地应用完全相同的操作顺序，无需考虑网络延迟等其他因素对操作顺序的影响，从而保证各副本数据的一致。
本质上是把多台机器一起执行同一件事情的问题简化为实现分布式一致性日志，通过日志的 Pub/Sub 保证多题啊机器对数据处理的最终一致。
Primary 将各种操作通过日志序列化，各 Replica 从日志中读取并应用到本地状态，这种解决问题的模式也叫 Pub/Sub，即抽象成通用的数据订阅机制，而将这种抽象产品化，这就是 消息队列。
2. 消息队列的应用价值
消息队列作为大型分布式系统的关键组件，在实时数据或流式数据架构中扮演这重要的角色。它通常被应用再系统解耦、异步处理、流量削峰，分布式事务/金融电商等场景中。
1. 数据集成&系统解耦
数据集成：将一个组织所拥有的数据，使其在所有的服务和系统中都可用。
数据集成的难点在于需要面对：
- 越来越多的数据
- 越来越多的数据系统
引入消息队列做数据分发。
好处：
- 这样架构只需要关心如何将数据导入消息队列即可
- 由于消息队列的解耦，架构复杂度大大降低，各系统间的数据同步不会互相影响
- 由于消息队列的持久化，不易丢失数据，也可以在必要时进行数据重放
- 由于所有数据都汇聚到消息队列中，数据集成很高效，可以快速介入新的系统而不影响存量架构
解耦是消息队列解决的最本质的问题，价值所在。
2. 异步处理&事件驱动
异步处理：本质上是解耦系统间的 RPC 调用，将那些依赖其他系统，同时对时效性要求不高的逻辑剥离出来，提高系统吞吐量和响应时间，降低系统耦合的复杂度。异步处理注重的是“通知”，事件驱动。
好处：
- 简化业务逻辑，更快的返回结果，提升响应效率和系统吞吐，改善用户体验
- 及时异步逻辑出现异常，也不会影响主流程，降低系统耦合度
异步处理更多的是事件驱动，引入消息队列做事件的转述与投递，从架构上也会达到解耦的功效。事件驱动的核心就是一套稳定、靠谱的 Event-Streaming 系统：消息队列。
大型分布式架构的数据总线、微服务中隔离直连的异步调用，事件驱动，处处都有消息中间件的身影。
3. 流量削峰
为什么要削峰：
- 后端服务的处理能力往往是有限的，无法和前端对等，同样的机器能够支撑的并发量无法跟前端处在同一个数量级。
- 后端服务对到达自身的流量是不可控的，只要上游调用不限流，后端就随时暴露在流量洪峰的压力下。
消息队列的作用：
- 高吞吐的特点可以在不高的成本下承接住巨大的流量，起到蓄水池的作用
- 后端采用拉取的消费模式，可以按照自身的处理能力进行流控，平稳的消费队列
4. 事务消息于分布式事务的最终一致
消息队列中的事务：指“业务执行本地事务”与“消息发送到消息队列“的原子性。
事务消息和普通消息的区别是，在事务提交前，这个消息对消费者来说是不可见的，基于事务消息，消息队列最终解决的是生产者与消费者在分布式事务场景中的一致性问题。
消费端对数据的处理逻辑一般是幂等的。
对于以上场景，引入消费队列做异步处理，使用非事务消息可能会出现如下情况：
- 创建订单成功，写入消息失败导致使用的优惠券没有被删掉
- 订单因支付失败没有创建成功，优惠券却被删除了
事务消息要解决的就是上述问题，保证“业务执行本地事务”（创建订单）和“发送消息”这两件事情是原子性的，然后依赖消息队列的可靠投递，实现不同系统对数据处理的最终一致性。
服务端为了实现事务机制（保障下游系统能消费到客户端认为已经提交的事务信息），需要做以下事情：
- 引入事务状态来“记录”客户端事务是否提交
- 由于网络原因或订单系统重启，导致有些客户端已提交或撤回的消息在服务端的状态是未知的。需要辅助“补偿"机制（对不确定状态的消息进行回查或客户端询问）来解决
通过两阶段提交语义（事务消息），事务状态反查的机制补偿，消息队列的可靠投递，以及业务消费逻辑的幂等，实现分布式事务最终一致。
3. 从历史看消息队列的价值演化
- 最早的消息队列开源产品 ActiveMQ，可以追溯到2003年，这一阶段主要是用来减轻经典 RPC 调用的紧耦合，剥离异步处理逻辑，解耦系统复杂度。（调用松耦合，异步处理）
- 第二阶段便是以kafka为经典代表的实时数据管道时代，这一阶段的产品在吞吐和数据量上都有质的提升，主要是为了解决数据集成的痛点，提高数据在不同系统之间的流转效率。（数据管道，数据集成，实时计算）
- 消息系统的第三个阶段，流数据平台，不仅仅是一个数据管道，更多的是强调平台化。平台化使得消息系统必须配备完善的多租户管理，I/O阻隔，流控与配额管理等。随着容器化发展，消息队列需要一个灵活的架构来适应这种变革，未来存储计算分离很可能是中间件产品的架构发展方向。（平台化，容器化，存储计算分离架构）