红色主题下用Redis搞消息队列，感觉挺实用但细节还得琢磨琢磨

（来源：日常技术讨论）这事儿其实是从我们项目组接了个新需求开始的，领导说要做一个活动推送功能，大概就是用户完成某些任务后，系统得立刻给他发个红色主题的激励消息，恭喜你，学习时长突破100小时！”或者“新一期党史知识竞赛开始了，快来参与！”。

要求就是快，不能延迟，而且量可能会突然变大，我们之前用的那种打日志，或者直接往数据库里插记录再轮询的老办法，感觉有点扛不住，团队里有个同事就提了一嘴：“要不，用Redis试试？它搞消息队列不是挺快的嘛。”

（来源：团队内部技术调研）说干就干，我们一开始觉得这事儿应该不复杂，Redis不是有List这个数据类型嘛，想法特简单：让不同的服务，一个当生产者（就是发消息的），一个当消费者（就是收消息的），生产者用LPUSH命令把消息内容，比如一个JSON字符串{“user_id”: 123, “message”: “恭喜你获得学习标兵称号！”}，从左边塞进一个叫red_theme_message_queue的列表里，消费者那边呢，就死循环地用BRPOP命令从列表右边把消息弹出来处理。BRPOP最好的地方是它是阻塞的，列表里没消息它就等着，有消息才返回,不会白占CPU。

（来源：初步实践遇到的坑）刚开始跑demo，感觉真不错，速度嗖嗖的，我们都觉得这方案稳了，但真把代码放到测试环境一跑，问题就一个个冒出来了，头一个大问题就是“消息丢失”，消费者用BRPOP拿到了消息，正准备调接口给用户发推送呢，结果它自己“砰”的一下崩溃了，或者网络突然抖动了，这下好了，消息已经从Redis里弹出来了，没处理成功，又没地儿找去，这条激励消息就彻底没了，这放在我们这种红色主题的正能量推送里，可是个大事故，用户明明完成了任务却没收到认可,体验很不好。

（来源：解决方案的寻找过程）我们琢磨着，这不行啊，得保证消息至少被处理一次，然后就查资料，发现Redis从5.0开始推出了Stream这种更专业的数据结构，就是冲着消息队列来的，它有个“消费者组”的概念，而且消息可以被“待处理”，就是说消费者拿了消息后，必须显式地告诉Redis“这条我处理完了”，系统才会把消息标记为已确认，如果消费者半路挂了，过一段时间这条消息会被重新分配给组里其他消费者去处理,这就解决了我们担心的丢失问题。

（来源：深入细节的纠结）但用Stream吧，感觉一下子复杂了好多，光是理解XADD, XREADGROUP, XACK这些命令就花了点时间，而且又带来新问题：要是某个消费者就是死活处理不成功一条消息，那这条消息就会没完没了地重试，成了“死信”，我们还得想办法处理这些死信，得有个机制把它挪到另一个死信队列里，再报警让人工介入看看是啥问题,这又增加了不少工作量。

（来源：关于可靠性的进一步讨论）另外还有一个细节让我们纠结了好久，就是Redis本身的持久化问题，我们知道Redis为了快，数据默认是在内存里的，虽然可以配置AOF（追加日志）或者RDB（快照）来把数据存到硬盘上，防止Redis服务器重启后数据全丢，但这又涉及到性能权衡：AOF配置成每条命令都刷盘，最安全，但会慢一些；配置成每秒刷盘，可能会丢一秒的数据，我们就在争论，对于这种激励消息，丢个几条能不能接受？是不是需要最严格的持久化配置？这又得根据业务重要性来拍板。

（来源：扩展性的考量）还有容量问题，Redis是内存数据库，所有消息都堆在内存里，如果搞个大型活动，消息量暴增，会不会把Redis内存撑爆？我们得提前估算好队列的最大长度，或者设计一个消息过期时间，让处理完的旧消息自动删除,这也得考虑进去。

所以你看，用Redis搞消息队列，入门感觉挺轻巧，几个命令的事，但真想在生产环境用踏实了，尤其是我们这种要求一定可靠性的红色主题应用，里面要琢磨的细节可真不少，从最简单的List到更可靠的Stream，从消息丢失到重复消费，从持久化策略到内存管控，每一步都得想清楚，做权衡，感觉这玩意儿就像搭积木，给了你很好用的基础材料，但房子最终稳不稳，还得看你怎么设计、怎么把各个细节连接处理好，我们现在也还在摸索和测试阶段,希望能找到一个既保证速度又足够稳妥的方案吧。