Kafka Over View

Posted 2021-05-02 完齿猪

    Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统(也可以当做MQ系统)，常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

    (注:Message Queue即消息系统，本来Linkedin只想把Kafka做成日志系统，谁知道Kafka越来越强大，变成消息系统，后来还发展出stream process。)

    与其他Message Queue(消息系统)对比

    其他消息系统还包括RabbitMQ，Redis，ZeroMQ，ActiveMQ，尚未有了解。但网上说，Kafka比其他消息中间件强大，而且是快得变态：

    (1)以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能

    (2)高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输

    (3)支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输

    (4)同时支持离线数据处理和实时数据处理

    何谓消息系统？

    传统的关系数据库(Oracle, mysql)保存数据，就像记账本一样，白纸黑字，写错了擦掉(rollback)，还要审核确认(commit)，非常严谨。

    而消息系统，顾名思义就是向目标用户发布公开的消息、公告、通知、提示等。可以点对点，也可以点对面(TOPIC)。如果是点对面，就要考虑方法：是挨家挨户通知？还是开广播通知？还是贴公告栏？

   挨家挨户通知可以知道谁收到，谁没有收到，但很累，如果那家人不在要不要等？

   开广播通知很省事，但消息播完就消失了，不知道哪些人收到。

    Kafka就是用贴公告栏的方法：

    发布者(producer)不定时将公告(message)贴到公告栏(broker)预先定好的栏目(partition)上；

    如果订阅者(consumer)订阅了某主题(TOPIC)的公告，自己按时去读取便是；

    如果订阅者今天没空，公告会一直留着，超过设定时间，就会撕掉。(这就是优于其他消息系统之处，其他消息系统消息过了就没了。)

    如果订阅者明天有空，还可以去读取公告(事实上，只要公告在，订阅者怎么读取都可以：从头读取、读未读的、读最新的...)

    何谓高吞吐？

    打个低俗的比方：

    你挖鼻孔，1次/秒很爽；

    如果10次/秒你能受得了吗?

    而Kafka居然可以做到100000次/秒！ 还可以很多人一起来进进出出(进=写数据，出=读数据)！而且，还是在非常廉价的商用机器上，这就是厉害之处。(我觉得比喻换成ooxx更贴切，吞吐嘛，但是我怕被封号)

    发展由来

    原来，对于Linkin这样的互联网企业来说，用户和网站上产生的数据有三种：

    (a)需要实时响应的交易数据，用户提交一个表单，输入一段内容，这种数据最后是存放在关系数据库(Oracle, MySQL)中的，有些需要事务支持。

    (b)活动流数据，准实时的，例如页面访问量、用户行为、搜索情况，这些数据可以产生：广播、排序、个性化推荐、运营监控等。这种数据一般是前端服务器先写文件，然后通过批量的方式把文件导入Hadoop这种大数据分析器里面慢慢整。

    (c)各个层面程序产生的日志，例如httpd的日志、tomcat的日志、其他各种程序产生的日志。码农专用，这种数据一个是用来监控报警，还有就是用来做分析。

    Linkin的厉害之处在于，他们发现了原先(b)，(c)的数据处理方式有问题.

    对于(b)而言，原来动辄一两个小时批处理一次的方式已经不行了，用户在一次购买完之后，最好马上就能看到相关的推荐；

    对于(c)而言，传统的syslog模式等也不好用，而且很多情况下(b)和(c)用的是同一批数据，只是数据消费者不一样，如下图。

    这2种数据的特点是：

    (1)准实时，不需要秒级响应，分钟级别即可。

    (2)数据量巨大，是交易数据的10倍以上。

    (3)数据消费者众多，例如评级、投票、排序、个性化推荐、安全、运营监控、程序监控、后期报表等。

    于是，Linkin就自己开发了一套系统，专门用来处理这种性质的数据，这就是Kafka，如下图：

    根据官网的介绍，ApacheKafka®是一个分布式流媒体平台，它主要有3种功能：

    (1)It lets you publish and subscribe to streams of records.

      发布和订阅消息流，这个功能类似于消息队列，这也是kafka归类为消息队列框架的原因

    (2)It lets you store streams of records in a fault-tolerant way.

      以容错的方式记录消息流，kafka以文件的方式来存储消息流

    (3)It lets you process streams of records as they occur.

      可以在消息发布的时候进行处理

    使用场景

    (1)Building real-time streaming data pipelines that reliably get data between systems or applications.

      在系统或应用程序之间构建可靠的用于传输实时数据的管道，消息队列功能

    (2)Building real-time streaming applications that transform or react to the streams of data。

      构建实时的流数据处理程序来变换或处理数据流，数据处理功能

    Push vs. Pull

    作为一个消息系统，Kafka遵循了传统的方式，选择由Producer向broker push消息并由Consumer从broker pull消息。一些logging-centric system，比如Facebook的Scribe和Cloudera的Flume，采用push模式。事实上，push模式和pull模式各有优劣。

    push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成Consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据Consumer的消费能力以适当的速率消费消息。

    对于Kafka而言，pull模式更合适。pull模式可简化broker的设计，Consumer可自主控制消费消息的速率，同时Consumer可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。

    版本更新  

    我开始学习的版本是0.9.0.1，目前最新版本是1.0.0(2017.11月发布)，据说1.0.0有很多重要特性，我会尽努力在分享中讲到版本间的差异。

    [后记]：为什么这个系统名称叫Kafka?

    个人觉得是写Kafka的工程师也喜欢文学，而且是个卡夫卡迷或但丁迷，因为代码中充斥着“炼狱”等词语。

    Franz Kafka(弗兰兹·卡夫卡)，生活于奥匈帝国统治下的捷克德语小说家，本职为保险业职员,主要作品有小说《审判》、《城堡》、《变形记》等。“卡夫卡”在捷克语中是“寒鸦”的意思，在希伯来语中是“穴鸟”的意思。

    卡夫卡被认为是现代派文学的鼻祖，是表现主义文学的先驱，其作品主题曲折晦涩，情节支离破碎，思路不连贯，跳跃性很大，语言的象征意义很强，这给阅读和理解他的作品带来了一定的困难。

    这是因为，他生活和创作的主要时期是在一战前后，当时，经济萧条，社会腐败，人民穷困，这使得卡夫卡终生生活在痛苦与孤独之中。卡夫卡一生都在苦苦地探求人生的价值与意义，但至死都无法对他的思考和探索给出令他自己满意的答案和结论，所以没有结尾。

主要参考文章

[1]日志：每个软件工程师都应该知道的有关实时数据的统一概念

[2]Building LinkedIn’s Real-time Activity Data Pipeline

[3]分布式发布订阅消息系统 Kafka 架构设计

[4]Kafka文件存储机制那些事

[5]Kafka是个奇葩！

[6]百度