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

人生亦有涯，而知也无涯。把庄子的话改吧改吧放上来作为开头，就是想和大家说，现在的这个大数据的世界里，数据太大，而我自己懂的东西很有限。除了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那样的努力就真的给中国人长脸了。