前言大数据技术相辅相成。任何技术都没有缺点，都是孤立发展的。今天我们就来分析一下Kafka和Redis的对比，看看分布式发布订阅有什么优缺点。什么是Redis？Redis是开源免费的，并且遵守BSD协议。它是一个高性能的键值非关系数据库。可能有朋友会问，Redis作为存储数据库，和Kafka这种分布式发布订阅消息系统相比如何？两者不是一个级别的。但是Redis中有一个队列数据类型，作为发布/订阅系统，可以和Kafka类比。什么是卡夫卡？Kafka是一个高吞吐量、分布式、基于发布-订阅的消息系统。使用Kafka技术，可以在廉价的PCServer上搭建一个大规模的消息系统。Kafka具有消息持久化、高吞吐量、分布式、多客户端支持、实时性等特点。现在干货来了。Kafka和Redis的区别与存储介质不同有关。Redis队列的数据是存储在内存中的，虽然有AOF和RDB的持久化方式，但仍然是基于内存的。Kafka是存储在硬盘上的，由于存储介质不同，性能也不同。理论上redis队列的性能要优于kafka，但是在实际使用中，这种体验并不是很明显。通常只有一些高并发的场景需要用到redis队列。比如发红包，可以提前拆解红包，然后推送到redis队列，在抢到的瞬间可以很好的支持并发。这里的成本是不同的，重点，重点，重点。Kafka存储在硬盘上，成本会比内存低很多。具体相差1或2个数量级。在数据量非常大的情况下，使用Kafka可以节省大量的服务器成本。最常见的是应用程序生成的日志。这些日志的量级一般都很大。如果需要处理它们，可以使用kafka队列。这只是对原著差距的简单介绍，我们来看核心对比——优缺点对比Redis作为消息队列Redis的发布（pub）、订阅（sub）模式Redis的发布和订阅由以下部分组成三个部分。Publisher（生产者），channel（类似于topic），subscriber（消费者）。做访问，你生产的所有消息都会一次性被消费者处理，不会留下任何痕迹，而且因为内存永远是宝贵的，所以内存会有限制，当生产者和消费者上来的时候，有时候也会影响redis的效率，而Redis在处理、发布和消费大数据（10K+文件）时，会出现无法忍受的慢慢现象 如果你有以下场景，可以考虑使用Redis做消息队列 如果你的需求是即时消费快生产快消费的场景，生产出来的消息是立即被消费者消费的 如果速度对你很重要，比如慢一秒几千万 如果消息丢失的场景是allowed 如果不需要系统保存你发过的消息，就可以无影无踪 如果处理的数据量不是那么大，就用KafKa做消息队列 KafKa设计精美，支持分布式ted和高可用部署，将一个大队列分成多个Partition（分区）来提高消息进入队列的吞吐量，分而治之的思想。并且消费时支持组的概念。可以支持多个客户端消费同一个队列，可以在一组中增加消费者的数量，扩大消费的处理能力。 KafKa不受生产者数量的影响，因为吞吐量足够，即使在便宜的单机服务器上也可以有每秒10万条的消息传输量，消费者可以随时消费。消息就在那里，非常灵活，再也不用担心来无影去无踪的恐慌。消息可以持久化，并采用一定的策略（比如在一定时间内删除，或者容量满了就清空） 遇到这种场景，可以考虑使用KafKa作为消息队列 如果你想要一个稳定的消息队列 如果你想让你发送的消息保留一定的时间，那不是无迹可寻的时候。在处理海量数据时，Redis采用keyhash的方式将数据分散存储在列中，当Redis作为集群使用时，对应的应用对应一个Redis，一定程度上会造成数据偏斜，从而导致数据丢失。从之前Kafka集群的部署来看，Kafka的一个主题（topic）可以有多个分区（replicas），它们均匀分布在Kafka集群上，这样就不会像redis那样出现数据倾斜。Kafka也有Redis的冗余机制。比如Redis集群中的一台机器宕机，很可能会造成数据丢失。因为Kafka是均匀分布在集群主机上的，即使一台机器宕机，也不会影响数据。使用。同时，Kafka作为一个订阅消息系统，还具有每秒百万级别的高吞吐量、持久化、分布式的特点。
