大数据那些事(28):卡夫卡们的故事

2020-05-27 00:00:00 的人 消息 开源 系统 卡夫卡

人生亦有涯,而知也无涯。把庄子的话改吧改吧放上来作为开头,就是想和大家说,现在的这个大数据的世界里,数据太大,而我自己懂的东西很有限。除了analytics以外的其他领域就是典型的半瓶醋了。连八卦都不说。


然而作为一个系列,连Kafka都不提一下,显然是说不过去。所以我也就硬着头皮的来提一下卡夫卡以及其他的消息队列们。当然严格的讲,卡夫卡不算是一个严谨的消息队列。它并不提供一入一出这样严谨的语义。所以严格一点讲卡夫卡算是一个基于pub/sub(中文叫发布/订阅??)的消息系统。


消息系统的作用在现代网站和电商里面很重要了。我记得自己在Bing的时候,老一代的爬虫系统和索引建立的系统都是手写的,一切东西搞在一起,所以做到incremental build特别难。而Google发布咖啡因的新一代系统以后,就使得Bing的整个业务体系架构显得很落伍。一条新闻CNN出来,近而被用户能在搜索引擎搜到,可能Google只需要秒级别的延迟,到了Bing可能是分钟级别的。这当然就显得非常的不好。于是,当时Bing就不得不新修一套了。然后新修这套的时候,为了整个业务体系能够适应多变的环境和业务规模,就准备搞一套消息系统,基于pub/sub的。


那个时候我记得内部曾经有过各种演讲,资料。大致上来说,使用了消息系统有那么几个好处,一是对业务逻辑的耦合程度就要求没那么高了,不管是消息发布方还是消息的订阅方的逻辑都可以进行更改。二是这样一来对于用多少资源去处理消息就会很灵活,峰值或者有需要特殊的时候比如感恩节,就可以多加机器,平时就可以少加。


这个项目持续了很多年,后的结果好像是黄了。应该是2016年的时候给撤销了。但是不管怎么说,理论上讲,消息系统是很有意义的,无论隔离业务逻辑,存储消息,提供冗余,以及因对业务规模的增加和减少的时候的资源使用率,都是很好的。这我想是初LinkedIn决定做卡夫卡的原因吧。


有关技术构架我就不讲了,虽然说论文也读过,我只能说自己理解不够深刻,讲出来误人子弟的可能性比较高。但是一个八卦是卡夫卡的开发者,其中那个中国人,我正好有过几周之缘。在IBM实习的时候对方是同样一个研究小组里面早开始做Hadoop的几个人之一。只是这个小组的人后来各奔东西,都成了挺牛的人,但是牛的显然还是这位了。今时不同往日的感觉。只是可惜了IBM。


卡夫卡之前之后其实消息队列不少,RabbitMQ是有名的一个吧。我是个C++写得比较脑残的人,所以不管是Erlang还是Scala在我眼睛里看起来都比较奇怪,但是这些消息队列好像都是用这些奇奇怪怪的语言写出来的。传说里面大家会觉得卡夫卡不够scalable不够稳定等等之类的抱怨。当然,应该比起RabbitMQ是要更好一些了。关于卡夫卡的故事之一是我前段时间和AWS里面做Kinesis的人聊天。对方信心满满的觉得自己的产品肯定比卡夫卡好用,无论是scabaility还是稳定性上。的例子是它们抢下了美国某在线视频直播厂商的业务,鉴于保密需要就不点名了,大家自己脑补很容易知道我说谁的。卡夫卡的另外一个八卦是MapR觉得卡夫卡性能不够好的原因之一是它们没有文件系统层面的支持。所以MapR决定又一次的开干,在它们的新版本里面集成和卡夫卡接口兼容的自己的实现。虽然说MapR成于文件系统,但是是不是任何东西后都成了文件系统,这就见仁见智了。在CTO跳槽去Uber,几个主创人员另外组局开公司去推广Drill的今天,我想MapR可能也是快要挂了。


后来MQ产品就很多了,近这个领域大的新闻是阿里巴巴开源了自己的消息队列RocketMQ。听名字就很霸气了。当然现在还在孵化中,不知道将来会怎么样。从我能看到的资料来看,RocketMQ是Java开发的,对用户比较友好,对于峰值的支持经过天猫这么多次双11的洗礼可谓很牛逼。网上有好事的人做了一些比较,总之的出来的结论就是大天朝的阿里巴巴出品威武,卡夫卡在很多方面都缺了功能或者性能。现在阻碍RocketMQ飞越的主要还是文档和社区了。当然我们必须说RocketMQ的主要目的是基于电商的业务,而卡夫卡的服务范围更多是系统日志。文档缺好像是中国人开源项目的通病了。而不维护更是阿里的现象,因为阿里特定级别需要升上去就有若干贡献指标,其中开源了多少东西很重要。所以阿里就很重视开源但是不重视开源以后的维护。我不知道RocketMQ会不会和阿里的其他开源项目一样。要是能和JStorm那样的努力就真的给中国人长脸了。

相关文章