消息初识

发送消息

1. 正常流程

step1. 业务执行

step2. 发送消息

优点：

实现简单

缺点：

业务执行成功与否与发送消息成功与否会出现不一致

举例：业务执行成功，消息发送/入库失败。目前项目中使用的就是这种方式，会采用兜底的方式来做最终一致。

 

2. 轻量保证一致 方法一

step1：发送消息

step2：存储消息

step3：返回消息入库结果

step4：业务操作

step5：发送业务处理结果

step6：更新消息状态

优点：

一定程度上保证了业务执行与消息发送的一致性

缺点：

仍然会出现，业务操作成功，消息处于待处理状态，本质上来说并没有解决消息发送失败的情况

 

3. 真正保证一致 方法二

step1：发送消息

step2：存储消息

step3：返回消息入库结果

step4：业务操作

step5：发送业务处理结果

step6：更新消息状态

stepa：查询待处理消息对应的业务操作结果

stepb：发送业务处理结果

stepc：更新消息状态，如果失败不断重试stepa、stepb

 

4. 真正保证一致 方法三

把消息存储至数据库/本地磁盘，定时任务来拉数据进行消息发送

优点：

解耦了消息中间件与业务应用，保证可用性优先

缺点：

每次新增业务就需要一个新字段存储消息

消息存入数据库：数据库业务操作需要支持事务

消息存入本地磁盘：有宕机丢失消息风险

 

消费消息

消费端保证幂等、不能catch异常

局部消息有序：部分消息按照属性聚合

消费者处理失败：是否阻塞整个流程呢？还是会因为采用了多线程发送消息，所以并不会阻塞住整个消息的消费？

全局消息有序：单机多队列，消息的消费是严格按照顺序来的，因此会出现失败阻塞住所有的case。一般这种场景采用pull。

我们的项目上采用的rabbitmq是严格有序消费还是乱序呢？或者说rabbitmq的具体状态是什么样呢？是否支持局部有序？

消息中间件如何支持高吞吐量的？分布式消息中间件是会做并行处理？每个中间件都只负责投递自己接收的消息么？

每个消息中间件都做了三件事：接收消息，存储消息，投递消息。

是不是正常的消息发送都是乱序投递的？rabbitmq会支持顺序消息么？