目录
这篇文章讲了消息队列作用
1 消息系统角色
消息队列系统主要有三个角色组成：生产者、消息队列、消费者。
- 生产者：生产消息给消息队列。
- 消息队列：存储生产者生产的消息，将消息提供给消费者消费。
- 消费者：消费消息队列存储的消息。
2 消息不丢失
为了保证消息不丢失，我们可以先考虑什么情况下消息会丢失。
2.1 生产者角度
1 生产者发送消息了，之后就不管了，至于消息队列有没有写入消息与自己没有关系，假设消息队列没有写入消息。此时会出现消息丢失的情况。
2 假设在极端情况下，生产者的网络出现故障，导致消息丢失。
如果业务要求消息一定不能丢，如何保证呢？
发送消息的方式有同步和异步。
同步：生产者将消息发送给消息队列，等到消息队列的写入确认之后，消息才算写入成功，性能相对较低。
异步：生产者将消息发送给消息队列，此时直接返回，消息队列写入成功或者失败都会回调生产者，性能相对较高。
生产者以同步的方式发送消息，等待消息队列的响应，如果消息队列响应失败，进行重试。
生产者发送消息失败重试阈值多少次合适？
这个可以通过自己的业务来定，没有固定的次数。可以封装在生产者客户端中。
生产者如果重试次数达到阈值还是失败呢？
如果重试次数达到阈值还是失败，可以写入 DB，事后以定时任务的形式进行重新发送。当然执行的过程中需要考虑消息的幂等性。
2.2 消息队列角度
消息队列在收到消息还没有持久化的时候，进程挂了，此时生产者是异步发送消息。消息丢失。
为了保证消息不丢，配合生产者使用同步发送消息机制。保证生产者的消息一旦发送成功，消息肯定不丢。
2.3 消费者角度
那些业务场景会丢消息呢？
1 消费者消费到消息，提交了offset，消费者进程突然被杀掉，消费者处理消息失败，消息丢失。
2 消息在消息队列是有有效期的，由于消费者消费消息过于缓慢，导致过期的消息会被统一清理，消息丢失。
3 消息消费失败，进入重试消息队列；重试多次都是消费失败，进入死信消息队列，如果没有人工介入，消息丢失。
如何避免上述丢消息的情况呢？
1 必须等消费者成功处理消息，才能提交 offset 位点。
2 加速消费者的消费速度，尽量在消息过期之前将消息消费掉。
3 针对这种重试消息队列、死信消息队列，我们进行人工介入。
3 消息不重复
3.1 生产者角度
由于一些异常情况、业务进行重试、代码bug等等，都能导致发送重复消息的情况。所以生产者不保证消息的不重复。
3.2 消息队列角度
消息队列只是一个消息传输的通道，是一个消息的载体，消息重复是业务层面的问题。所以消息队列不保证消息的不重复。
3.3 消费者角度
消费者消费消息列队的消息，由于生产者和消息队列都不能保证消息不重复，需要保证在消息重复消费的时候做好幂等性。
消费者是如何消费消息队列的消息的呢?
生产者生产消息，每一个消息写入消息队列，都是有 offset ，这个 offset 代表消息的序号。
消费者来消费消息也是按照 offset 顺序来执行的，消费了消息之后都会提交 offset。
消费者在消息重复消费的情况下如何保证幂等性？
1 如果说数据在数据库只能存在一份，可以先读，如果数据存在，可以更新；如果数据不存在，直接写入。
2 在数据库添加唯一约束条件，来保证数据不能多次写入。来避免脏数据的产生。
3 如果是需要写入 Redis，那没问题了，反正每次都是 set，天然幂等性。
4 消息顺序性
如何理解消息的顺序性？
从生产者角度来看，生产的消息是有顺序的 A->B->C。
从消息队列的角度来看，存储的消息是有顺序的 A->B->C。
从消费者的角度来看，消费的消息是有顺序的 A->B-C。
如何保证消息顺序性呢？
生产者：在同一个线程中采用同步的方式发送。
消息队列：确保要排序的消息路由到同一个队列中。
消费者：不对收到的消息的顺序进行调整，一个分区的消息只由一个线程处理即可。
255
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
