用redis stream作队列的一些心得

最近做了些基于redis stream做消息队列的工作，有人会问，为什么要用redis，而不是专用消息队列中间件来做呢？

好吧，一个是资源不足问题，另一个也是不想增加依赖项，最终导致了不用ons、rocketmq、rabbitmq来做。

曾经的概念里，用redis做消息队列都是不正统的，很脆弱的选择，一般是看不上的，直到最近的redis5 stream特性出来后，就另眼相看了。

stream特性是模仿kafka设计的，有消费组、有ACK机制、能查看已下发但未收到ACK消息列表，确实强大了一个档次。

这个消费组，需要说下，有了消费组，就代表可以做1对N的事件处理、也可以做1对1的消息处理

消费组中还有consumer，如果某个消费组消息处理不过来，就可以通过增加多个consumer来加快消费速率

发消息、很容易，没啥说的

由于是框架层面的中间件产，因此consumer收到消息还需要自动触发业务开发人员编写的业务处理消息方法，也是个灵活的地方，但是属于spring bean invoke方面的了，这里略过，总体来说也没多少技术含量

另外比较重要的地方是监控以及消息转移部分，比如上线后过段时间后consumer的变动、或者进程、或者docker宕机导致出现了未ack的消息，此时怎样处理？怎样监控有这样的消息存在了？

假设内存不多时，消息队列消息太多导致占用内存过大，想释放一部分内存又需要怎样操作？

这些问题直接用x系列命令操作的话还挺麻烦，最好是写个程序定时监控上报，然后通过webapi方式来转移消息等就会好很多。

还好，上面说的这些基础层面的api redission都提供了，只是要成为半成品的框架，考虑易用性，则还需要自己开发。