为啥非要用Kafka?其他MQ不行么?by彭文华招财风水布局

这是彭文华的第179篇原创大家好,我是彭文华。最近写技术文章比较少了,再不写,都得被各位大数据架构师朋友骂了。我有次跟朋友聊怎么建大数据体系,从数据采集开始,一般用 Flume 监控和收集,然后用 K

这是彭文华的第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生成算法-雪花算法


我需要你的转发,小小的满足一下我的虚荣心
原文链接:http://www.wanshiruyi.cc/news/19966.html,转载和复制请保留此链接。
以上就是关于为啥非要用Kafka?其他MQ不行么?by彭文华招财风水布局全部的内容,关注我们,带您了解更多相关内容。

特别提示:本信息由相关用户自行提供,真实性未证实,仅供参考。请谨慎采用,风险自负。



上一篇:让用户惊喜不断,饿了么x汉堡王为什么总能造出爆款?绿的近义词

下一篇:大量收购ACF 专业求购ACF AC835

相关推荐