kafka-5 kafka的高吞吐量和高可用性

6.1 高吞吐量

kafka的高吞吐量主要是由4方面保证的：

（1）顺序读写磁盘

Kafka是将消息持久化到本地磁盘中的，一般人会认为磁盘读写性能差，可能会对Kafka性能提出质疑。实际上不管是内存还是磁盘，快或慢的关键在于寻址方式，磁盘分为顺序读写与随机读写，内存一样也分为顺序读写与随机读写。基于磁盘的随机读写确实很慢，但基于磁盘的顺序读写性能却很高，一般而言要高出磁盘的随机读写三个数量级，一些情况下磁盘顺序读写性能甚至要高于内存随机读写。

（2）零拷贝

零拷贝是指Kafka利用 linux 操作系统的 “zero-copy” 机制在消费端做的优化。首先来看一下消费端在消费数据时，数据从broker磁盘通过网络传输到消费端的整个过程：
1）操作系统从磁盘读取数据到内核空间（kernel space）的page cache；
2）应用程序读取page cache的数据到用户空间（user space）的缓冲区；
3）应用程序将用户空间缓冲区的数据写回内核空间的socket缓冲区（socket buffer）；
4）操作系统将数据从socket缓冲区复制到硬件（如网卡）缓冲区；

图6.1 数据从broker磁盘通过网络传输到消费端的整个过程

整个过程如图3.1所示，这个过程包含4次copy操作和2次系统上下文切换，而上下文切换是CPU密集型的工作，数据拷贝是I/O密集型的工作，性能其实非常低效。

零拷贝就是使用了一个名为sendfile()的系统调用方法，将数据从page cache直接发送到Socket缓冲区，避免了系统上下文的切换，消除了从内核空间到用户空间的来回复制。从上图可以看出，"零拷贝"并不是说整个过程完全不发生拷贝，而是站在内核的角度来说的，避免了内核空间到用户空间的来回拷贝。

（3）page cache

为了优化读写性能，Kafka利用了操作系统本身的Page Cache，就是利用操作系统自身的内存而不是JVM空间内存。这样做是因为， JVM中一切皆对象，对象的存储会带来额外的内存消耗； 使用JVM会受到GC的影响，随着数据的增多，垃圾回收也会变得复杂与缓慢，降低吞吐量；另外操作系统本身对page cache做了大量优化，通过操作系统的Page Cache，Kafka的读写操作基本上是基于系统内存的，读写性能也得到了极大的提升。

（4）分区分段

Kafka的message是按topic分类存储的，topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹，partition实际上又是按照segment分段存储的。这也非常符合分布式系统分区分桶的设计思想。

通过这种分区分段的设计，Kafka的message消息实际上是分布式存储在一个一个小的segment中的，每次文件操作也是直接操作的segment。为了进一步的查询优化，Kafka又默认为分段后的数据文件建立了索引文件，就是文件系统上的.index文件。这种分区分段+索引的设计，不仅提升了数据读取的效率，同时也提高了数据操作的并行度。

6.2 高可用（HA）

kafka的高可用主要是由3方面保证的：

（1）partition副本的分区分配策略

• 生产者的分区分配策略
• 消费者的分区分配策略

（2）kafka的消息传递备份策略

producer将消息发送给分区的leader，leader会将该消息写入其本地log，然后每个follower都会从leader pull数据，follower pull到该消息并将其写入log后，会向leader发送ack，当leader收到了ISR集合中所有follower的ack后，就认为这条消息已经commit了，leader将增加HW并且向producer返回ack。在整个流程中，follower也可以批量的从leader复制数据，以提升复制性能。

producer在发送消息的时候，可指定参数acks，表示"在生产者认为发送请求完成之前，有多少分区副本必须接收到数据"，有三个可选值，0、1、all(或-1)，默认为1。

• acks=0，表示producer只管发，只要发出去就认为发送请求完成了，不管leader有没有收到，更不管follower有没有备份完成。（At Most Once）
• acks=1，表示只要leader收到消息，并将其写入自己log后，就会返回给producer ack，不考虑follower有没有备份完成。
• acks=all(或-1)，表示不仅要leader收到消息写入本地log，还要等所有ISR集合中的follower都备份完成后，producer才认为发送成功。（At Least Once）
• 幂等性，在Producer中设置enable.idempotence=true，在初始化的时候会被分配一个PID，发往同一个Partition的消息会附带Sequence Number，而Broker端会对<PID,Partition, SeqNumber>做缓存，对具有相同主键的消息，Broker只会持久化一条。（Exactly Once）

实际上，为了提高性能，follower在将消息保存到内存中而尚未写入磁盘时，就会向leader发送ack，所以也就不能完全保证异常发生后该条消息一定能被Consumer消费。

（3）kafka中的Leader选举

kafka中涉及到选举的地方有多处，最常提及的也有：cotroller选举 、分区leader选举、consumer group leader的选举。

• controller的选举【broker的leader】

controller的选举是通过broker在zookeeper的"/controller"节点下创建临时节点来实现的，并在该节点中写入当前broker的信息 {“version”:1,”brokerid”:1,”timestamp”:”1512018424988”} ，利用zookeeper的强一致性特性，一个节点只能被一个客户端创建成功，创建成功的broker即为controller，即"先到先得"。
当controller宕机或者和zookeeper失去连接时，zookeeper检测不到心跳，zookeeper上的临时节点会被删除，而其它broker会监听临时节点的变化，当节点被删除时，其它broker会收到通知，重新发起controller选举。

• leader的选举【分区副本的leader】

分区leader的选举由 controller 负责管理和实施，当leader发生故障时，controller会将leader的改变直接通过RPC的方式通知需要为此作出响应的broker，需要为此作出响应的broker即该分区的ISR集合中follower所在的broker，kafka在zookeeper中动态维护了一个ISR，只有ISR里的follower才有被选为Leader的可能。
具体过程是这样的：按照AR集合中副本的顺序查找到第一个存活的、并且属于ISR集合的副本作为新的leader。一个分区的AR集合在创建分区副本的时候就被指定，只要不发生重分配的情况，AR集合内部副本的顺序是保持不变的，而分区的ISR集合上面说过因为同步滞后等原因可能会改变，所以注意这里是根据AR的顺序而不是ISR的顺序找。

• 消费组leader的选举

组协调器会为消费组（consumer group）内的所有消费者选举出一个leader，这个选举的算法也很简单，第一个加入consumer group的consumer即为leader，如果某一时刻leader消费者退出了消费组，那么会重新随机选举一个新的leader。