为啥非要用Kafka？其他MQ不行么？ by 彭文华

这是彭文华的第179篇原创

大家好，我是彭文华。最近写技术文章比较少了，再不写，都得被各位大数据架构师朋友骂了。

我有次跟朋友聊怎么建大数据体系，从数据采集开始，一般用 Flume 监控和收集，然后用 Kafka 传输和分发，一边到实时，一边到离线巴拉巴拉。

朋友以前是搞 Java 的，他就问：“我不太会用 Kafka ，换成别的行么？”我楞了一下，我听说过几个 MQ 的名字，但是研究不深啊，只知道 Kafka 因为吞吐量巨高，所以用在大数据环境。

但是其他 MQ 行不行，我没太深究，反正都是 MQ ，应该也行吧。当时我就“嗯”了一下，说“应该也行”。

回来我就仔细研究了一下，这就把研究成果给各位唠一唠。文末有最强kafka资料包，可直接下载。

MQ是啥？

MQ，Message Queue，消息队列。啥意思呢，就是存储各种消息信息的一个队列。再通俗一些，就是一个专门把消息信息排好队，放在那里等着别人来读取的场景设计的工具。就像~~这个：

左边一个个的黑点点，就是一条条的消息，在那里排好队。这就是消息队列了。消息队列中的消息最终的宿命就是被前面的应用（大嘴）消费掉（吃掉）。

之所以要有消息队列，是因为前面生产信息的速度不一样，有快有慢。

好比小时候，妈在那边剥瓜子仁儿，我们坐在这边吃。咱妈就是一个生产产品的角色，我们就是消费产品的角色。

妈妈剥瓜子有些时候快，有些时候慢。我们也有些时候在那里干等着，也有些时候要出去玩。前后两个角色之间是脱节的。如果想要这边的瓜子刚剥出来就马上被吃掉，那就得两个角色钉在这边，这多费劲啊！

妈妈多聪明啊，她可以趁我们不在，多剥一些瓜子，把仁儿放在碗里。我们玩累了回到家，就能一个一个吃了。

但是这样有个弊端，就是早些时候剥的，就可能坏掉，或者味道就不够嘎嘣脆了。那咋办？那最好按顺序吃呗，先把最早剥好的吃掉，这样不就能最大程度防止各种问题么？

咱把整个场景挪到信息系统里，这就是一个消息队列了。前面生产信息的角色，就是生产者，后面使用信息的就是消费者。中间按顺序排列着的，就是一条条信息。这上面所有的角色，就组成了消息队列的三要素：生产者、消费者和消息（服务）。

消息队列能干啥？

其实消息队列的作用在上面已经说清楚了。其实就是对生产者和消费者进行解耦。

没有 MQ 的时候，生产者和消费者必须一对一，或者定期轮询。这样要么浪费资源，要么时效性不高。

而有了 MQ 机制之后，有生产任务了，生产者再过来干活也不迟。消费者也不用老等着，或者过一会来看一次，而是在队列那头等着触发就行。来一个信息，就消费一个。

这样同时满足了资源最小化和效率最大化。你看这些大牛的脑子就是灵光，聪明的不要不要的。用 MQ 这个机制，能把资源和效率这两个天生矛盾的事情同时满足。

而且，MQ 还有一个作用：它不怕任务积压。妈妈剥了一堆瓜子，孩子吃的慢，那没关系，妈妈不用等孩子吃完再剥，可以先放到干净的桌子上摆好就是了。你感觉好像是很简单，理所应当的。但是没有 MQ 的时候就像是手递手搬东西，下家手上的东西没放下，你上家的东西就没法递出去。

所以 MQ 还有一个能力，就是超高的信息传输能力，术语叫吞吐量。

为啥是Kafka？

其实 MQ 有很多。Apache 的 Active MQ ，Rabbit的 Rabbit MQ 、阿里开源的 Rocket MQ 、大数据霸主 Kafka ，其他的还有 NSQ、 Zero MQ 、 Beanstalkd 等等。

国内大厂除了阿里，也有大神自研过 MQ ，也都还不错。美团基于 RabbitMQ ，弄了一个 MOS ，云消息队列，顿时就高大上了有没有？滴滴也基于 Rocket 弄了一个 DDMQ ，用的也挺好的。

但是，不管别人怎么弄怎么搞，就是无法撼动 Kafka 在大数据领域的无敌姿态。啥地方都用它，接数据用，分发数据用，最后实时数仓还用 kafka 当“存储”。

我估计 kafka 自己都有点蒙，我本来就是个 MQ ，最后咋还变成数据库了呢？

这就得说到 Kafka 的核心特性了， Kafka 的绝招之一：数据传输速度超级快。前面说过，有一个指标来评判消息队列的效率，就是吞吐量 TPS Transaction per Second，每秒钟传输的事务数据量。

Kafka 的 TPS 能到多少呢？1秒钟，百万级！不过这个没有对比就显示不出有多厉害。

阿里的 Rocket MQ 的 TPS 多少呢？十万级。Apache 的 Acitive MQ 呢？万级。

这是啥概念？碾压啊，有没有？量级的碾压！！！！无敌之姿！

不过，这还不算完。Kafka 通过各种巧妙的设计，最大可能的提升他的可靠性，对大数据场景非常友善。比如：

它有副本概念，可以开启多个副本，保证数据安全；

用跳表思想，设计 Log 和 Index 文件，保证超高效率；

用稀松索引，提升消费者端读取 Offset 时访问物理存储的超高效率；

用零拷贝技术，减少数据在不同环节的数据来回复制，从而提升写入和读取的超快速度。

总之一句话：kafka 就是为了性能而生的。就这个特性，牛不牛？

不过，讲真， Kafka 也有一个不太友好的地方，就是它为了达到性能，需要付出丧失小部分高可靠的特性。

如果选择高并发、高性能、高吞吐，那么 kafka 可能会有数据丢失、重复消费等风险。这种情况在 OLAP 分析场景无所谓了，反正根据大数原则，少几条数据根本不影响计算结果，尤其是百分比那种。

但是，对于跟金额相关的任何场景，高可靠才是第一优先保证的。你不能说在某宝上下个订单，一亿单都成功了，只有1单莫名其妙丢失了，这是不能容忍的。唉，成也萧何，败也萧何！

总结

MQ：Message Queue，消息队列。一种解耦工具，用在数据/信息生产和消费上下游之间的解耦工具。

市面上有很多 MQ ， Rocket MQ 、 Acitve MQ 、Rabbit MQ 、 Kafka 等等。

Kafka 由于其超越所有 MQ 的超高性能，占据大数据生态圈绝对霸主地位，无人可以撼动。其显著特征就是快！

其核心设计思想有：顺序读写、跳表、稀松索引、零拷贝。

Kafka 为了实现超高性能，必须要牺牲部分可靠性。因此只适合在可容忍（极小概率数据重复、丢失等）的场景。

而交易等对可靠性非常高的场景，只能选择 Rocket MQ 等工具。

扩展阅读：《史上最强Kafka资料包书+视频+面试题》下载方式：关注本公众号“大数据架构师”，后台回复“kafka”即可下载。也可以加我微信：shirenpengwh，咱私聊。

本资源从网上下载，只限于研究使用，勿用于商业。如有不妥，请联系本号删除。

配合以下文章享受更佳

海量数据超快查询的秘密-跳表思想

SparkStreaming实时任务处理的三种语义

10亿用户量，连续7天登录的用户标签该怎么打？

One ID中的核心技术ID-Mapping究竟是怎么实现的？

架构师带你细细的捋一遍MapReduce全流程

设计思想赏析-分布式id生成算法-雪花算法

我需要你的转发，小小的满足一下我的虚荣心