kafka概要设计

Posted 2021-01-21 csuliujia

Kafka核心功能

即：高性能的消息发送与高性能的消息消费

 

下载安装包后即可启动Kafka服务器，但是此前需要首先启动Zookeeper服务器，Zookeeper是为Kafka提供协调服务的工具，Kafka内置提供了一个Zookeeper服务器以及一组相关的管理脚本，直接使用该内置Zookeeper即可。

 

Kafka吞吐量/延时分析

吞吐量：某种处理能力的最大值，对于Kafka而言，吞吐量指的是每秒能够处理的消息数或者每秒能够处理的字节数。（高吞吐）

延时：衡量发出某个操作与接收到操作响应之间的时间间隔，对于Kafka而言，延时表示客户端发起请求与服务器处理请求并发送响应给客户端之间的时间间隔。（低延时）

 

Kafka生产端如何做到高吞吐低延时：Kafka写入操作快，得益于它对磁盘的使用方法不同，虽然Kafka会持久化所有数据到磁盘，但本质上每次写入操作其实都是把数据写入到操作系统的页缓存(page cache)中，然后由操作系统自行决定什么时候把页缓存中的数据写回磁盘上。这样设计具有3个优势:

1.操作系统页缓存是在内存中分配的，所以消息写入的速度非常快

2.Kafka不必直接与底层的文件系统打交道。所有繁琐的I/O操作都交由操作系统来处理

3.Kafka写入操作采用追加写入(append)的方式，避免了磁盘随机写操作，注意磁盘随机读写的吞吐量的确很慢，但是磁盘顺序读写的吞吐量很快，甚至接近内存的随机I/O

 

Kafka消费端如何做到高吞吐低延时：Kafka读取消息时首先会从操作系统的页缓存中读取，如果命中便把消息经页缓存直接发送到网络的Socket上。该过程利用Linux平台的sendfile系统调用做到，即所谓的零拷贝(Zero Copy)技术。（附：传统的Linux操作系统中的I/O接口会将同一份数据进行多次拷贝，数据传输过程中还涉及内核态与用户态的上下文切换，CPU开销巨大，限制了操作系统高效数据传输的能力）Kafka的消息消费机制使用的就是sendfile——严格来说是通过Java的FileChannel.transferTo方法实现。

 

Kafka高吞吐低延时总结：

1. 大量使用操作系统页缓存，内存操作速度快且命中率高
2. Kafka不直接参与物理I/O操作，而是交由最擅长此事的操作系统来完成
3. 采用追加写入方式，摒弃了缓慢的磁盘随机读/写操作
4. 使用以sendfile为代表的零拷贝技术加强网络间的数据传输速率

Kafka消息持久化

Kafka由操作系统自行决定什么时候把页缓存中的数据写回磁盘上。Kafka依赖操作系统的flush“刷盘”功能实现消息真正写入物理磁盘，而默认的刷盘间隔是5s，通常情况下，该间隔太短，适当增加例如2min可以大程度上提升操作系统物理写入操作的性能。此外持久化到磁盘上的好处如下：

1. 解耦消息发送与消息消费
2. 实现灵活的消息处理：如重置消费位点等

此外，传统持久化方式是优先使用内存，内存不足后再一次性写入磁盘，Kafka相反，当操作系统决定将页缓存中的数据写入到磁盘上时，会优先写入到磁盘（文件系统的持久化日志），减少了Kafka程序对内存的消耗，将内存主要供于页缓存使用

 

Kafka负载均衡和故障转移

Kafka实现负载均衡(load balancing)实际上是通过智能化的分区领导者选举(partition leader election)来实现，可以在集群的所有机器上以均等的机会分散各个partition的leader，从而实现整体上的负载均衡，默认情况下Kafka的每台服务器都有均等的机会为Kafka的客户提供服务，可以把负载分散到所有集群中的机器上。

 

Kafka实现故障转移(fail-over)主要是利用会话机制来实现

所谓故障转移是指当服务器意外终止时，整个集群可以快速地检测到该失效(failure)，并立即将该服务器上的应用或服务自动转移到其他服务器上。故障转移通常以“心跳”、“会话”的机制来实现，即只要主服务器与备份服务器之间的心跳无法维持或主服务器注册到服务中心的会话超时过期了，那么就认为主服务器已无法正常运行，集群会自动启动某个备份服务器来替代主服务器的工作。

每台Kafka服务器启动后会以会话的形式把自己注册到Zookeeper服务器上，一旦该服务器出现问题，与Zookeeper的会话便不能维持从而超时失效，此时Kafka集群会选举出另一台服务器来完全代替这台服务器继续提供服务。

Kafka伸缩性

伸缩性表示向分布式系统中增加额外的计算资源(cpu、内存、存储或带宽)时吞吐量提升的能力。

阻碍线性扩容的一个关键因素就是状态的保存。不管哪类分布式系统，集群中的每台服务器一定会维护许多内部状态。如果由服务器自己来保存这些状态信息，则必须要处理一致性问题。相反如果服务器是无状态的，状态的保存和管理交给专门的协调服务来做(如Zookeeper),那么整个集群的服务器之间就无需繁重的状态共享，这极大的降低了复杂度。如果需要扩容集群节点，只需要简单地启动新的节点机器进行自动负载均衡就可以。

Kafka采用了上述思想，每台Kafka服务器上的状态统一交给Zookeeper保管，扩展Kafka服务器也只需要一步：启动新的Kafka服务器。Ps:在Kafka服务器上并不是所有状态都不保存，它只保存了很轻量级的内部状态，因此在整个集群建维护状态一致性的代价很低。

 

注意：在Kafka演进过程中，经由Kafka下游数据处理平台做的事情Kafka自己也可以做，即Kafka Streams，流式处理组件。