详解KAFKA是如何做到1秒发布百万级条消息的
KAFKA是分布式发布-订阅音讯体系，是一个分布式的，可划分的，冗余备份的持久性的日志服务。它首要用于处理活跃的流式数据。
如今被广泛地应用于构建实时数据管道和流应用的场景中，具有横向拓展，容错，快等优点，并现已运行在许多大中型公司的出产环境中，成功应用于大数据领域，这篇文章共享一下我所了解的KAFKA。
【KAFKA高吞吐率功用揭秘】
KAFKA的第一个突出特定即是“快”，而且是那种变态的“快”，在普通便宜的虚拟机器上，比如一般SAS盘做的虚拟机上，据LINDEDIN统计，最新的数据是每天运用KAFKA处理的音讯超越1万亿条，在峰值时每秒钟会发布超越百万条音讯，就算是在内存和CPU都不高的情况下，Kafka的速度最高可以到达每秒十万条数据，而且还能持久化存储。
首先，可以运用KAFKA供给的出产端API发布音讯到1个或多个Topic（主题）的一个（确保数据的次序）或者多个分区（并行处理，但不必定确保数据次序）。Topic可以简单了解成一个数据种类，是用来区别不同数据的。
KAFKA保护一个Topic中的分区log，以次序追加的办法向各个分区中写入音讯，每个分区都是不可变的音讯队列。分区中的音讯都是以k-v办法存在。
? k表明offset，称之为偏移量，一个64位整型的仅有标识，offset代表了Topic分区中一切音讯流中该音讯的开始字节位置。
? v即是实践的音讯内容，每个分区中的每个offset都是仅有存在的，一切分区的音讯都是一次写入，在音讯未过期之前都可以调整offset来完结屡次读取。
以上说到KAFKA“快”的第一个因素：音讯次序写入磁盘。
我们知道如今的磁盘大多数都还是机械构造（SSD不在讨论的范围内），假如将音讯以随机写的办法存入磁盘，就会按柱面、磁头、扇区的办法进行（寻址进程），缓慢的机械运动（相对内存）会耗费许多时间，致使磁盘的写入速度只能到达内存写入速度的几百万分之一，为了规避随机写带来的时间耗费，KAFKA采纳次序写的办法存储数据，如下图所示：
新来的音讯只能追加到已有音讯的末尾，而且现已出产的音讯不支撑随机删去以及随机访问，可是花费者可以经过重置offset的办法来访问现已花费过的数据。
即使次序读写，过于频频的许多小I/O操作一样会形成磁盘的瓶颈，所以KAFKA在此处的处理是把这些音讯调集在一同批量发送，这样削减对磁盘IO的过度读写，而不是一次发送单个音讯。
另一个是无效率的字节仿制，特别是在负载比较高的情况下影响是显着的。为了避免这种情况，KAFKA采用由Producer，broker和consumer共享的标准化二进制音讯格局，这样数据块就可以在它们之间自由传输，无需转换，降低了字节仿制的本钱开支。
一同，KAFKA采用了MMAP(Memory Mapped Files，内存映射文件)技能。许多现代操作体系都许多运用主存做磁盘缓存，一个现代操作体系可以将内存中的一切剩下空间用作磁盘缓存，而当内存收回的时分几乎没有功用丢掉。
由于KAFKA是基于JVM的，而且任何与Java内存运用打过交道的人都知道两件事：
? 对象的内存开支非常高，通常是实践要存储数据大小的两倍；
? 跟着数据的增加，java的垃圾收集也会越来越频频而且缓慢。
基于此，运用文件体系，一同依赖页面缓存就比运用其他数据构造和保护内存缓存更有吸引力：
? 不运用进程内缓存，就腾出了内存空间，可以用来存放页面缓存的空间几乎可以翻倍。
? 假如KAFKA重启，进行内缓存就会丢掉，可是运用操作体系的页面缓存仍然可以继续运用。
也许有人会问KAFKA如此频频运用页面缓存，假如内存大小不够了怎么办？
KAFKA会将数据写入到持久化日志中而不是刷新到磁盘。实践上它只是转移到了内核的页面缓存。
运用文件体系而且依托页缓存比保护一个内存缓存或者其他构造要好，它可以直接运用操作体系的页缓存来完结文件到物理内存的直接映射。完结映射之后对物理内存的操作在适当时分会被同步到硬盘上。
KAFKA除了接纳数据时写得快，别的一个特点即是推送数据时发得快。
KAFKA这种音讯队列在出产端和花费端分别采纳的push和pull的办法，也即是你出产端可以以为KAFKA是个无底洞，有多少数据可以使劲往里面推送，花费端则是依据自个的花费才能，需要多少数据，你自个过来KAFKA这里拉取，KAFKA能确保只要这里有数据，花费端需要多少，都尽可以自个过来拿。
▲零拷贝
详细到音讯的落地保留，broker保护的音讯日志自身即是文件的目录，每个文件都是二进制保留，出产者和花费者运用一样的格局来处理。保护这个公共的格局并答应优化最主要的操作：网络传输持久性日志块。 现代的unix操作体系供给一个优化的代码途径，用于将数据从页缓存传输到socket；在Linux中，是经过sendfile体系调用来完结的。Java供给了访问这个体系调用的办法：FileChannel.transferTo API。
要了解senfile的影响，主要的是要了解将数据从文件传输到socket的公共数据途径，如下图所示，数据从磁盘传输到socket要经过以下几个步骤：
? 操作体系将数据从磁盘读入到内核空间的页缓存
? 应用程序将数据从内核空间读入到用户空间缓存中
? 应用程序将数据写回到内核空间到socket缓存中
? 操作体系将数据从socket缓冲区仿制到网卡缓冲区，以便将数据经网络发出
这里有四次拷贝，两次体系调用，这是非常低效的做法。假如运用sendfile，只需要一次拷贝就行：答应操作体系将数据直接从页缓存发送到网络上。所以在这个优化的途径中，只要最终一步将数据拷贝到网卡缓存中是需要的。
常规文件传输和zeroCopy办法的功用对比：
假定一个Topic有多个花费者的情况， 并运用上面的零拷贝优化，数据被仿制到页缓存中一次，并在每个花费上重复运用，而不是存储在存储器中，也不在每次读取时仿制到用户空间。 这使得以接近网络连接限制的速度花费音讯。
这种页缓存和sendfile组合，意味着KAFKA集群的花费者大多数都彻底从缓存花费音讯，而磁盘没有任何读取活动。
▲批量紧缩
在许多情况下，体系的瓶颈不是CPU或磁盘，而是网络带宽，对于需要在广域网上的数据中心之间发送音讯的数据流水线特别如此。所以数据紧缩就很主要。可以每个音讯都紧缩，可是紧缩率相对很低。所以KAFKA运用了批量紧缩，即将多个音讯一同紧缩而不是单个音讯紧缩。
KAFKA答应运用递归的音讯调集，批量的音讯可以经过紧缩的办法传输而且在日志中也可以保持紧缩格局，直到被花费者解紧缩。
KAFKA支撑Gzip和Snappy紧缩协议。
【KAFKA数据可靠性深度解读】
KAFKA的音讯保留在Topic中，Topic可分为多个分区，为确保数据的安全性，每个分区又有多个Replia。
? 多分区的设计的特点：
1.为了并发读写，加快读写速度；通过这种优化，可以极大的提高短网址的高并发问题
2.是运用多分区的存储，利于数据的均衡；
3.是为了加快数据的康复速率，一但某台机器挂了，全部集群只需要康复一部分数据，可加快故障康复的时间。
每个Partition分为多个Segment，每个Segment有.log和.index 两个文件，每个log文件承载详细的数据，每条音讯都有一个递增的offset，Index文件是对log文件的索引，Consumer查找offset时运用的是二分法依据文件名去定位到哪个Segment，然后解析msg，匹配到对应的offset的msg。
每个Partition会在磁盘记载一个RecoveryPoint,，记载现已flush到磁盘的最大offset。当broker 失败重启时，会进行loadLogs。首先会读取该Partition的RecoveryPoint，找到包括RecoveryPoint的segment及今后的segment， 这些segment即是也许没有彻底flush到磁盘segments。然后调用segment的recover，从头读取各个segment的msg，并重建索引。每次重启KAFKA的broker时，都可以在输出的日志看到重建各个索引的进程。
< 数据同步>
Producer和Consumer都只与Leader交互，每个Follower从Leader拉取数据进行同步。
如上图所示，ISR是一切不落后的replica调集，不落后有两层意义：间隔上次FetchRequest的时间不大于某一个值或落后的音讯数不大于某一个值，Leader失败后会从ISR中随机选取一个Follower做Leader，该进程对用户是通明的。
当Producer向Broker发送数据时,可以经过request.required.acks参数设置数据可靠性的级别。
此装备是表明当一次Producer请求被以为完结时的承认值。特别是，多少个其他brokers必须现已提交了数据到它们的log而且向它们的Leader承认了这些信息。
?典型的值：
0： 表明Producer从来不等候来自broker的承认信息。这个选择供给了最小的时延但一同危险最大（因为当server宕机时，数据将会丢掉）。
1：表明取得Leader replica现已接纳了数据的承认信息。这个选择时延较小一同确保了server承认接纳成功。
-1：Producer会取得一切同步replicas都收到数据的承认。一同时延最大，然而，这种办法并没有彻底消除丢掉音讯的危险，因为同步replicas的数量也许是1。假如你想确保某些replicas接纳到数据，那么你应该在Topic-level设置中选项min.insync.replicas设置一下。
仅设置 acks= -1 也不能确保数据不丢掉,当ISR列表中只要Leader时,相同有也许形成数据丢掉。要确保数据不丢除了设置acks=-1，还要确保ISR的大小大于等于2。
?详细参数设置：
request.required.acks:设置为-1 等候一切ISR列表中的Replica接纳到音讯后采算写成功。
min.insync.replicas: 设置为>=2,确保ISR中至少两个Replica。
Producer：要在吞吐率和数据可靠性之间做一个权衡。
KAFKA作为现代音讯中间件中的佼佼者，以其速度和高可靠性赢得了广大商场和用户喜爱，其间的许多设计理念都是非常值得我们学习的，这篇文章所介绍的也只是冰山一角，希望可以对我们了解KAFKA有必定的作用。
