Redis列表的使用场景整理

背景

Redis的列表可以实现多种数据结构，如栈、队列、有限集合、消息队列等。在某种条件下Redis的发布订阅模式可以用基于列表的消息队列方案取代。发布-订阅模式的消息通常是一对多，例如基于发布订阅模式的消息的生产者和消费者是都是作为独立节点部署的，那么这种结构表现上也是消息队列。

实际开发过程中必须弄清楚应用场景，正确分析应用属于发布订阅模式还是消息队列模式，这将会对应用的部署方式产生不同的影响。

Redis消息队列模型

Redis的列表可以实现消息队列，其实现过程为：

生产者客户端使用lpush命令从列表左侧插入元素，多个消费者客户端使用brpop命令阻塞式的获取队列右侧尾部元素，多个客户端保证了消费者的负载均衡和高可用性。

列表的其他使用场景

1. 栈，先进后出，命令组合为：lpush+lpop=Stack。
2. 队列，先进先出，使用方式为：lpush+rpop=Queue。
3. 有限集合，控制溢出元素，lpush+ltrim=Limited Collection。

启示录

在单机部署的情况下，发布订阅模式和消息队列在表现上是没有区别的，但是分布式部署场景下情况就不一样了。如果生产者和消费者都使用分布式部署，那么一条消息将被N个订阅者处理：

很不幸的是，如果应用的业务本质对消息的消费是一对一的，即一条消息只能被一个消费者处理，这就导致分布式部署模式下，所有的消息都会被重复处理N次，这是一种错误的消息处理方式。

发布订阅模式和消息队列，从本质来看，多少还是有区别的，发布订阅模式是一种消息N种订阅者同时处理，类似消息广播。而消息队列则是一对一的，只能有一个消费者取到消息并对其进行处理。

项目开发初期在对技术进行选择时，应该多思考项目中的业务场景，合理权衡并谨慎做决定，在满足功能的前提下，还应该考虑应用的扩展性和部署方式。否则，当初偷过的懒，迟早是要还的。

这里简单总结一下，希望对各位同行有所启发：敲下某个API调用的同时，还应该捎带想想这个API的使用场景与其所处位置是否。

我认为程序员并不是搬运工，而应该是沉思者……