深入浅出 Kafka 设计

这篇文章是俺家老板写的，希望可以做后端的小伙伴一起沟通学习！

kafka由来：

Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等，用scala语言（一种JVM语言）编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

Kafka的特性:

高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行消费操作。

可扩展性：kafka集群支持热扩展

持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失

容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）

高并发：支持数千个客户端同时读写

kafka 使用场景：

日志收集：可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。

消息系统：解耦和生产者和消费者、缓存消息等。

用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。

运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

流式处理：比如spark streaming和storm

等等

kafka设计思想：

先上一张集群结构图：

ZK是kafka集群的管理者，Broker是集群的一个实例，集群中有一个Broker是leader节点，其他事follower节点。leader节点通过ZK选举产生，leader节点做了很多管理工作。Producer与Consumer都通过ZK来获取集群信息。Producer与Consumer是通过Topic关联在一起。每个topic根据业务需求自定义切割多少partition。这样当业务流量变大就可以增加topic的partition来保证横向扩展能力。下图举例展示了topic分割成三个partition,为了保证数据可靠性，partition需要根据业务需求配置N个副本用来相互备份，每个子partition内部有一个是leader,读写都是在leader上进行。副本仅仅是冷备份。

下图展示消费者如何进行消费。topic 作为生产者与消费者的纽带。生产者在启动之时通过ZK获取某个Topic下所有的partion leader ，并建立socket连接。一个消费群体订阅了一个topic,那么这个群体一定会消费掉所有信息。kafka的设计是让每个partition只被这个消费群体里面一个消费者消费。反过来消费者可以消费多个partition ，这样保证了业务是顺序被消费的。

假设kafka集群有三个Broker,一个topic, topic分区是三个，每个分区有两个副本。下图展示消息具体存储。关于replica有以下几点：

1 Replica均匀分配在Broker上，同一个partition的replica不会在同一个borker上

2 同一个partition的Replica数量不能多于broker数量。多个replica为了数据安全，一台server存多个replica没有意义。server挂掉，上面的副本都要挂掉。

3 分区的leader replica通过算法均衡分布在broker上。此时集群的负载是均衡的。这就叫做分区平衡

溜完以上图片 Broker leader 做了什么工作呢？

简单的说kafka在设计上为了减轻ZK的工作量，把相应工作放给了Broker leader，leader通过监听ZK上的相应节点来做管理工作，例如管理partition 选举leader，partition再平衡。

那么partition 什么样的内部结构造就kafka的高性能？接着看最后一张图

下图是具体展示每个partition内部存储。每个partion(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。

每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。这样做的好处就是能快速删除无用文件，有效提高磁盘利用率。

partition内部会再分成N个Segment,这是消息具体存储的位置。根据kafka定位就是处理消息流，那么在设计的时候，写的时候顺序的追加，读的时候也是顺序读取，并采用消息直接从page cache转入socket发送出去。

Broker 被设计成无状态的，所有消费者在消费时需要自行传入要读取消息的offset， 这个值可以存储在消费者内存自行控制，也可以定期的上报给ZK，这样当消费者宕机重启可以接着消费，否则从头来过。

segment 内部会再分出两个文件***.index，与****.log，index 文件采用稀疏索引方式存储。 log 则是具体日志存储。

可靠性与高性能是相悖的，kafka在可靠性上有很多参数可以启用，可靠性包括三个方面，一是生产者把消息可靠的发给kafka集群，二是kafka集群本身把消息可靠的存储，三是消费者把消息可靠的从kafka集群中消费掉。根据业务需求自行寻求二者间的平衡。

编程*职场*思维

把时间交给阅读