消息在开发过程中多次用到，在分布式系统中也是高频使用的一项技术，特写该片文章以作总结。
一、消息使用场景
1.1 常见的使用场景
系统解耦
在单机系统中解耦可能无关痛痒，但是在分布式环境下，系统间的相互依赖，最终会会导致整个依赖关系混乱，对后期的拆分和优化都带来负担。
异步处理
在逻辑请求链路里，为了提高接口RT，都会对逻辑进行优化，对于非主链路上的分支逻辑，都会选择异步处理。其中比较经典的当属日志的记录，一般会选择发送消息日志，然后由日志系统异步消费并进行存储等后续处理。
数据最终一致性，通过消息来实现最终的数据同步。
异步处理也可以引来 并行处理 的使用姿势。在工作中，我们基于消息开发了一个简单的分布式任务处理组件。该组件简单分为三块分别是 切分、加载、执行三个阶段
每个阶段都是以作为消费者，然后处理完毕后再作为生产者发送消息。消息消费无状态，可以按需无限拓容。
流量削峰
由于使用消息，我们的链路变成了生产者发送消息，消息中间件存储消息，最后消费者从消息中间件拉取消息的一个过程。而消息中间件的存储能力能够有效的帮助消费者进行缓冲。试想下，正常流量下消费者能够愉快的进行消费，瞬时高峰流量来的时候，消费者消费能力跟不上，刚好阻塞在消息中间件，等峰值过后，消费者又能很快的将阻塞的消息进行消费。
1.2 消息使用的先决条件
根据上面的三个常见场景，我们可以发现，消息的介入，一般都是在非核心链路较多或者核心链路但是能容忍延迟的情况下（比如数据的最终一致性）较为合适。
二、消息相关的概念
在JMS标准中，有两种消息模型P2P（Point toPoint）和Publish/Sub(Pub/Sub)。
P2P
特点：
- 一个消息只能被一个消费者消费，消费后会从队列里移除
- 发布者和消费者无关系，发布者发送消息的行为不会随消费者而改变
- 消费者消费完成消息，需要向队列Ack，消息队列发现消息消费成功即做消息移除
Pub/Sub
发布订阅模式，一个发布，多方订阅。涉及到的角色有 发布者（Publisher）、主题（Topic）、订阅者（Subscriber）。
特点
- 每个消息可以有多个消费者
- 针对某个主题（Topic）的订阅者，必须创建一个订阅者之后，才能消费发布者的消息
- 为了消费消息，订阅者必须保持运行的状态
Kafka 就是该模式的典型代表。
三、常规消息问题及解决方案
2.1 消息延迟
一般要么是大流量进入，要么是消费者延迟，基本思路就是排除业务逻辑，然后考虑是否可拓容。
案例
工作中有这样一个场景 商品根据商品变更消息来进行ES数据的新增或修改，另外一个商品分组的消息对ES的数据进行修改，由于业务上先有商品后有分组，所以分组消息的消费者只做ES更新。
不巧的时当时一个哥们在刷全网商品数据，也没做限速导致有大量的商品变更消息产生，商品消息阻塞导致ES对应的商品文档没有创建，然后分组消息消费者更新失败。当时用的还是顺序消息，所以拓容无望。
2.2 消息阻塞
消息阻塞一般就是突然消息增多，超过了消费者消费的能力。或者消费者出现逻辑问题，导致不断的重试或长时间等待。
该类问题一般首先要看下业务日志，缺消费是否正常。如果是消息峰值，可考虑是否拓容。当然消费逻辑问题，只能紧急修补并发布了，在修补后为了快速消费阻塞的消息队列，可考虑临时对消费者进行拓容。
2.3 重复消费
重复消费一般发生下消费端，比如消费者处理完毕，在准备进行ack的时候出现了问题，应用重启后，消息中间件以为该消息还未处理又推给了消费者，或者消费者拉取的时候重复。
一般的做法就是消费端做幂等，业务上设置一个幂等表或者用redis等用来存储消费记录，每次消费消息都先去幂等存储进行验证，如果没有消费则存入幂等记录，幂等一般会根据一个业务唯一键进行确认。
2.4 消息丢失
消息丢失一般分为生产者发送失败、消息中间件丢失、消费丢失。
生产者丢失
生产者发送消息，可能以为网络问题或者消息中间处理失败导致，消息遗漏。针对生产者如果发送是同步的自然可以进行异常捕捉并重试。如果是异步请求，一般通过发送消息的异步回调方法来实现。kafka里这两种case都能满足。
消息中间的丢失
消息中间对我们来说一般都是相对可信的，但是有时候消息中间可能为了吞吐量啥的不能保证某些特性，所以这只能根据中间的文档进行相应的配置。
案例
kafka某个broker宕机，然后重新选举partiton的leader时，要是此时其他的follower刚好还有些数据没有同步，结果此时leader挂了，然后选举某个follower成leader之后，待同步的数据就彻底丢了。
给这个topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本
在producer端设置acks=all：这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了
消费丢失
有的消息中间件支持自动ack，当消费者消费到消息，消息中间件也不管是否消费成功自动ack。这时候一般选择消费者主动ack比较合适。
2.5 消息顺序性
消息顺序性保证，一般来通过消息中间实现。消息中间件的顺序消息其实根本上就是局部有序，一般会对消息的主体，比如用户id、商品id这些进行分区，每个partition保证自己的队列有序，两个Partition之间无顺序限制。
然后在消费的过程中，一个Partition同一时刻只能被一个消费者消费变相的同步。所以可以看出需要注意的是，为了保证业务响应需要提取估好Partition的数量，保证系统最够的并发数量。
顺序消息的消费特性，导致一旦某个消息消费阻塞或者异常会导致它所在的Partition的阻塞。
三、常见消息中间对比
Kafka、RabbitMQ、RocketMQ消息中间件的对比 —— 消息发送性能
推荐文章
从1-7，都建议看下
https://www.cnblogs.com/daiwei1981/p/9394587.html
