卡夫卡很棒。它适合所有年龄段的人。它拥有无限的风景。从业务服务到大数据，无所不能。不过，即便如此牛逼，在很多项目中，还是可以看到很多替代品，比如RabbitMQ、RocketMQ、Pulsar等等，等等，先不说这些同质化的竞争者。在我看到的很多项目中，经常会有一个杂乱无章的消息队列，那就是Redis。更不用说，它被广泛使用。他们傻吗？还是水平根本不够？Redis很强大，因为Kafka的对手是Redis！Redis非常强壮，肌肉发达，几乎无所不能。如果你的内存足够大，你甚至可以把所有的数据都装进内存。除了常见的五种数据结构，Redis还支持很多扩展的数据结构，包括Kafka实现的Stream类型。Stream是Kafka的低配置版本。如果你有使用Kafka的经验，玩玩它是没有问题的。与旧的LPUSH/BRPOP和PUB/SUB模式相比，Stream在这种情况下获胜。可以看到，Streamn的生产和消费模式和Kafka几乎是一样的，甚至还有消费组的概念。但是Stream没有Partition的概念，所以是低配版的Kafka。我们来看看官网上的描述。消费者组最初是由流行的消息系统Kafka(TM)引入的。Redis以完全不同的方式重新实现了类似的想法，但目标是相同的：让一组客户端协作消费同一消息流的不同部分。Redis可以在许多软件开发中，尤其是将软件部署到PartyA的机器，引入一个新部件的成本是巨大的。对此，很多外包商和OD应该更清楚它的残酷性。对于这类系统，即使是发展势头不错的中小企业，对于消息的需求也不是那么苛刻。与其引入新的Kafka组件，不如利用项目中已有的Redis组件来完成工作。让我们回顾一下消息队列的作用。调峰用于接受超过业务系统处理能力的请求，使业务平稳运行。这样可以节省很多成本。例如，某些限时抢购活动并非针对高峰容量而设计。Buffer作为缓冲层存在于服务层和慢速登陆层，其作用类似于调峰，但主要用于服务内部的数据流转。比如群发短信。解耦项目银石未确定具体要求。消息队列可以作为接口层来解耦重要的业务流程。您只需要遵守数据的协议和程序，就可以获得可扩展性。冗余的消息数据可以被多个不相关的业务以一对多的方式使用。健壮性消息队列可以积累请求，所以即使消费者业务短时间挂掉，也不会影响主业务的正常进行。不好意思，Redis的Stream除了内存容量较小之外，上面提到的所有需求都可以做到，包括持久化，这对于缓存系统来说是比较少见的，也是支持的。你为什么不犹豫！多么容易，怎么玩！还有一个好处是Kafka为了提高吞吐量费尽心机。比如使用FilesystemCachePageCache缓存，减少与磁盘的交互；使用顺序写入来增加写入吞吐量；使用零拷贝和MMAP来减少内存交换；使用batch流式交互，达到网卡上限；使用pull方式获取和消费消息，符合consumer的处理能力。经过这样的优化，虽然功能很强大，但同时代码和软件的体积也会膨胀。对于Redis来说，domain是在内存里玩的，不用那么费劲就可以达到比Kafka更高的速度。甚至partition的特性也可以通过使用不同的key划分来实现，性能自然比kafka要高。另一个很容易使用。比如XADD指令、XLEN、XRANGE、XREAD等，指令比Kafka更少，更容易理解。这些优点一旦凑到一起，就抵挡不住它成为MQ中的香包子了。简单易用易维护，优点这么多，为什么不选择Redis呢？给客户一个笨重笨重的Kafka、Pulsar，给自己添麻烦，何必呢？当然，以上评价是针对外包和项目公司的。如果你公司的产品不断迭代，不断优化，体量大，一次性选择成熟的消息队列是正确的选择。因此，在正确的项目和正确的地方使用RedisStream的人一点都不傻。
