Redis消息服务器变得更灵活了，传输效率也跟着嗖嗖涨起来了

（根据微信公众号“OSC开源社区”发布的相关文章内容整理）

Redis，这个大家都很熟悉的数据存储工具，一直以来都因为它超快的速度和简单的用法受到很多开发者的喜欢，很多人除了拿它当缓存用，还经常用它来临时传递一些消息，实现一个轻量级的消息队列，一个程序把任务信息塞进Redis的列表里，另一个程序再从这个列表里把任务取走去执行，这个方法在小规模、要求不高的场景下挺好用的。

用Redis做消息队列一直有个挺麻烦的地方，就是它不太灵活，以前主要靠两种数据结构：列表（List）和发布订阅（Pub/Sub），用列表的话，就像是有一个任务列表，生产者把任务一个个从左边推进去，消费者从右边一个个拉出来处理，这种方式能保证消息的顺序，但是如果有很多组消费者，每组都想独立地处理全部消息，那就很难办了，因为一个消息被一个消费者取走之后，列表里就没有了，其他消费者就看不到了，而发布订阅模式呢，它像是广播，一个消息发出来，所有订阅了这个频道的消费者都能同时收到，这解决了多组消费者的问题，但它又不持久化，如果某个消费者当时不在线，或者处理得慢，这个消息就丢了,再也找不回来了。

开发者们就有点纠结，想要消息不丢、能持久化，就得用列表，但这样就很难让多个消费者组一起工作；想要支持多个消费者组，就得用发布订阅，但又得承受消息可能丢失的风险,这种不灵活性限制了Redis在更复杂的消息传递场景中的应用。

Redis后来引入了一个非常重要的功能，叫做“流”（Stream），这个“流”数据结构，就是为了更好地处理消息队列的场景而设计的，它可以说是吸取了之前列表和发布订阅的优点,同时又解决了它们的缺点。

流里的消息是持久化的，所有被加入流的消息都会被Redis保存起来，不会因为被读取过一次就消失，这就像给消息上了保险，即使服务器重启,消息也不会丢。

也是让Redis消息服务器变得真正灵活起来的关键，是它引入了“消费者组”（Consumer Group）的概念，你可以创建一个消费者组来消费同一个流，这个组里可以有多个消费者，消息会平均分配给组内的消费者去处理，这样就能很轻松地实现负载均衡，提高处理速度，更重要的是，不同的消费者组之间是独立的！同一个消息流，可以被创建多个消费者组，每个组都可以从头开始，或者从某个位置开始，独立地、完整地消费流里的所有消息，这就完美解决了之前“一份消息无法被多个不同目的的消费者组重复使用”的难题。

举个例子来说明这种灵活性，比如我们有一个“用户行为”消息流，里面记录了用户的点击、浏览等操作，我们有两个不同的业务需要处理这些数据：一个业务是实时计算用户的兴趣偏好，另一个业务是实时检测异常操作，在以前，我们可能需要部署两套系统，或者想一些复杂的办法来复制数据，但现在，利用Redis的流，我们可以创建两个消费者组，比如叫“兴趣分析组”和“安全风控组”，这两个组同时从“用户行为”流里读取消息，互不干扰。“兴趣分析组”里的多个消费者可以分工合作，快速处理消息来计算兴趣；“安全风控组”也同样，可以有自己的节奏去分析安全风险，一份数据，被两个组各用各的,非常灵活方便。

除了灵活性，传输效率也跟着“嗖嗖”涨起来了，这主要得益于流的几个设计，一是它支持批量操作，生产者可以一次性打包发送多条消息，减少了网络往返的次数；消费者也可以一次性拉取一批消息进行处理，提高了效率，二是消息在流中是紧凑存储的，并且Redis针对流的访问模式做了优化，读写速度都非常快，三是消费者组的管理机制很高效，每个消费者组只需要维护一个最后处理消息的ID（位置标识），状态非常轻量,使得整个消息流转的过程开销很小。

流还提供了一些很实用的功能来保证消息的可靠传递，消费者组里的消费者在处理一个消息时，如果处理失败或者中途掉线了，这个消息在一段时间后会被重新分配给组内的其他消费者去处理，避免了消息因为单个消费者的问题而丢失，开发者还可以通过检查“待处理消息列表”来查看哪些消息已经被获取但还未被确认完成,便于进行监控和问题排查。

Redis流也不是说在所有方面都超越专业的消息队列软件（比如Kafka、RabbitMQ），它在高级功能如消息回溯、严格的事务保证、复杂的路由规则等方面可能还有差距，对于很多应用场景来说，特别是那些已经在使用Redis，并且希望用一种简单、高效、灵活的方式来实现消息传递的系统，Redis流无疑是一个巨大的进步，它让Redis从一个简单的“缓存兼临时消息中转站”，变成了一个功能强大得多的、真正意义上的轻量级消息服务器，开发者现在有了更多的选择，可以根据自己业务的复杂程度，更灵活地利用Redis来构建高效、可靠的消息传递链路，这就是为什么说，Redis消息服务器变得更灵活了,传输效率也跟着嗖嗖涨起来了。