redis队列先进先出需要注意什么_「每日一问」用代码分析，Redis为什么可以做消息队列...

MQ

现在的应用基本上都是采用分布式 系统架构进行设计，而很多分布式系统必备的一个基础组件就是消息队列。

如果大家不想再引入一个其他的消息组件例如：kafka、RabbitMQ、RocketMQ。恰好你的项目中使用了Redis，可以尝试利用Redis编写一个轻量级的消息组件。

为什么Redis可以作为消息队列

在回答这个问题前，首先我们考虑下，作为一个消息队列，应该有哪些特征？我个人认为应该满足以下三点要求：

消息的有序性

问题描述：虽然消费者是异步处理消息，但是大部分的情况下消费者仍然需要按照生产者发送消息的顺序来处理消息，避免后发送的消息被先处理了。对于要求消息保序的场景来说，一旦出现这种消息被乱序处理的情况，就可能会导致业务逻辑被错误执行，从而给业务方造成损失。

解决方案：redis提供的数据结构list和sorted set都是有序存储的结构，都可以保证存入数据的有序性。但是个人更倾向于使用list，一是因为list的有序性不需要人为的干预，sorted set需要设置score来维护顺序；二是因为list支持阻塞是获取brpop，避免了轮询队列造成的CPU消耗。

重复消费的处理

问题描述：消费者从消息队列读取消息时，有时会因为网络堵塞而出现消息重传的情况。此时，消费者可能会收到多条重复的消息。对于重复的消息，消费者如果多次处理的话，就可能造成一个业务逻辑被多次执行，如果业务逻辑正好是要修改数据，那就会出现数据被多次修改的问题了。

解决方案：针对这一问题，生产者在生产消息时，生成一个全局唯一的消息id，消费者在消费时，手动记录已经消费的消息id。避免消息的重复消费。

消息的可靠性

问题描述：消费者在处理消息的时候，还可能出现因为故障或宕机导致消息没有处理完成的情况。此时，消息队列需要能提供消息可靠性的保证，也就是说，当消费者重启后，可以重新读取消息再次进行处理，否则，就会出现消息漏处理的问题了。

解决方案：redis支持数据的持久化，因此可以保证数据的可靠性，具体可以参考我之前写的文章「每日一问」Redis宕机后，如何恢复数据？

简易代码实现

1.创建三个注解分别表示消息监听者、消息消费者、消息处理者，具体代码如下：

消息消费者容器

/*** 消息消费者容器，被该注解标注的类表示其内部的被@see  MessageListener    标注的public方法* 为一个消息监听器*/@Target({ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Documented&#