Redis功能拓展-消息队列

1.什么是消息队列，消息队列解决什么问题？
　　从宏观上看，消息队列就是围绕队列这个数据结构而拓展开的一段特殊程序，将这类程序单独部署就可以称之为消息中间件（也称：消息队列）。在分布式系统中消息队列最常用与解决的问题是：解耦以及流量的削峰填谷。

2.Redis中基于List结构实现消息队列的方式

　　常见的消息中间件专业户有Kafk，RabbitMQ，ActiveMQ，RocketMQ等等，但实际上除了这些专业户外Redis适不适合作为消息中间件呢？对于消息队列来说最基本的需求是：1.必须满足队列的数据结构以及相关操作；2.必须要保证消息的快速读写；3.对于业务侧的其他需求。对于第1点Redis的list数据结构恰好可以满足，而第2点由于Redis的高性能自然也可以满足，那么Redis是不适用于消息队列就必须得看业务侧的一些其他常见需求。比如说：1.消息的可靠性保证；2.消息的消费确认；3.消息的重复消费；4.消息的保序；5.消息的堆积能力；

2.1消息的可靠性保证

　　Redis自身提供的AOF的方式来保证数据的可靠性，换句话只要生产者向Redis发送了一条消息，这条消息被成功执行，该数据就完成了持久化。在这之后的任何一个时间点Redis宕机，这条消息都可以被恢复，当然前提是该消息没有被消费。

2.2消息的消息确认机制

　　消费者从消息队列消费消息时，可能会因为网络问题而导致该次消息丢失，此时消费者再次从消息队列中获取数据的时候，消费者获取的就是一条新的消息。换句话说，有消息逃逸了。如果需要保证消息的确认机制，只用单个List是无法完成的，需要有3个的List结构去共同维护。如：一个正常的list结构List-A、一个正在消费中的list结构ListB、一个消费失败的list结构ListC。生产者向ListA生产消息，消费者首先向ListA获取消息时，把获取到的数据先发送到ListB，这一步必须保证原子操作；如果消息消费成功则从ListB中删除，消费失败则将其放入到ListC中。其实Redis中新的特性Streams就是使用内部队列留存消费组里每个消费组的消息，直到消费者使用XACK命令通知Streams“消息已经处理完成”。

2.3消息的重复消费

　　List的数据在被取出之后，该数据就不存在了，所以不存在重复消费的问题。

2.4消息的保序

　　多个生产者向队列生产消息的时候，由于是通过网络进行发送的所以谁先进入到队列是无法保证的。而消息的顺序通常来说是指消息在被消息队列接受后的顺序与消费的先后顺序是否一致。List结构自然也是满足的。如果需要对消息做严格的保序，即消息的顺序是按照生产者生产消息的先后，那么就需要在消息体重添加序号ID来去确保顺序，消费者在消费过程中自然也是需要使用该序号ID来进行排序再消费。

2.5消息的堆积能力

　　对于消息队列来说，削峰填谷是一个非常典型的应用场景。这也意味着在流量高峰期，生产者的速度会远远大于消费者的速度，那么久就会有大量的消息堆积在队列中。而Redis是基于内存的，消息的堆积能力完全受限于实例所分配的内存。所以说基于Redis的消息队列在消息的堆积能力是较差的。

　　因此基于Redis的消息队列一般只适用于并发量小，消息体积小的场景。