kafka
一、kafka的基础架构
1）Producer ：消息生产者，就是向kafka broker发消息的客户端； 2）Consumer ：消息消费者，向kafka broker取消息的客户端； 3）Consumer Group （CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。 4）Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。 5）Topic ：可以理解为一个队列，生产者和消费者面向的都是一个topic； 6）Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列； 7）Replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。 8）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。 9）follower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower会成为新的leader。
二、kafka的文件存储机制
由于生产者生产的消息会不断追加到log文件末尾，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment。每个segment对应两个文件——“.index”文件和“.log”(默认最大为1g可配)文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号。例如，first这个topic有三个分区，则其对应的文件夹为first-0,first-1,first-2。
index和log文件以当前segment的第一条消息的offset命名。下图为index文件和log文件的结构示意图。
“.index”文件存储大量的索引信息，“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中message的物理偏移地址。
三、kafka生产者
1，kafka集群分区的原因:
（1）方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；
（2）可以提高并发，因为可以以Partition为单位读写了。
2，生产者分区的原则:
（1）指明 partition 的情况下，直接将指明的值直接作为 partiton 值；
（2）没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值；
（3）既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition 值，也就是常说的 round-robin 算法。
3，ISR:
Leader维护了一个动态的in-sync replica set (ISR)，意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后，就会从ISR中选举新的leader。
4，Kafka的消息可靠性保障ack:
0：producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据；
1：producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；
-1（all）：producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。无法保证幂等性,故而用Exactly Once：idempotent + at least once = exactly once
5，Kafka的在0.11.0版本之后是如何解决消息的幂等性(Exactly Once):
为了实现Producer的幂等语义，Kafka引入了Producer ID（即PID）和Sequence Number。每个新的Producer在初始化的时候会被分配一个唯一的PID，该PID对用户完全透明而不会暴露给用户。
对于每个PID，该Producer发送数据的每个<Topic, Partition>都对应一个从0开始单调递增的Sequence Number。
类似地，Broker端也会为每个<PID, Topic, Partition>维护一个序号，并且每次Commit一条消息时将其对应序号递增。对于接收的每条消息，如果其序号比Broker维护的序号（即最后一次Commit的消息的序号）大一，则Broker会接受它，否则将其丢弃：
如果消息序号比Broker维护的序号大一以上，说明中间有数据尚未写入，也即乱序，此时Broker拒绝该消息，
Producer抛出InvalidSequenceNumber
如果消息序号小于等于Broker维护的序号，说明该消息已被保存，即为重复消息，Broker直接丢弃该消息，
Producer抛出DuplicateSequenceNumber
上述设计解决了0.11.0.0之前版本中的两个问题：
Broker保存消息后，发送ACK前宕机，Producer认为消息未发送成功并重试，造成数据重复 前一条消息发送失败，后一条消息发送成功，前一条消息重试后成功，造成数据乱序
使用时，只需将enable.idempotence属性设置为true，kafka自动将acks属性设为-1。
6，故障处理细节
（1）follower故障
follower发生故障后会被临时踢出ISR()，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。
（2）leader故障
leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据。
注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。
四、Kafka消费者
1，消费方式:
consumer采用pull(拉)模式从broker中读取数据
push(推)模式很难适应消费速率不同的消费者,因为消息发送速率是由broker决定的。它的目的是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。
pull则可以根据consumer的消费能力以适当的速率消费消息。不足：如果kafka没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka的消费者在消费数据时会传入一个时长参数timeout，如果当前没有数据可供消费，consumer会等待一段时间之后再返回，这段时长即为timeout。
2，分区分配策略:
一个消费者组中有多个消费者，一个topic有多个partition分区，而每个分区最多只能被一个消费者组中的一个消费者消费，故而这里就涉及到partition分区分配策略的问题，即确定哪个partition由哪个consumer来消费。
kafka的分配策略：roundrobin和range（默认）
range：按照每个topic的分区进行range分配，假设n=分区数/消费者数量，m=分区数%消费者数量，那么前m个消费者每个分配n+1个分区，后面的（消费者数量-m）个消费者每个分配n个分区。这样当同一个组同时消费多个topic时，靠前的消费者需要消费的分区偏多
T1和T2表示两个主题；C1和C2表示同一个消费者组的两个消费者 C1：T1（0，1，2，3） T2（0，1，2，3） C2：T1（4，5，6） T2（4，5，6）
这样C1就比C2多两个分区消费
roundrobin：把所有的partition和consumer列出来，然后轮询consumer和partition，尽可能的让把partition均匀的分配给consumer
具体分配策略参考：https://blog.csdn.net/qq_39907763/article/details/82697211
3，offset的维护
由于consumer在消费过程中可能会出现断电宕机等故障，consumer恢复后，需要从故障前的位置的继续消费，所以consumer需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费。
Kafka0.9版本之前，consumer默认将offset保存在Zookeeper中，从0.9版本开始，consumer默认将offset保存在Kafka一个内置的topic中，该topic为__consumer_offsets。
五、Kafka的高效读写：
1）顺序写磁盘：
kafka的producer生产数据，要写入到log中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能达到600M/s，而随机写只有100k/s。这与磁盘的机械结构有关系，顺序写之所以快，是因为其省去了大量磁头寻址的时间
2）零拷贝复制：
详情参考：零拷贝详解
- DMA（Direct Memory Access）：直接存储器访问，是所有现代电脑的重要特色，它允许不同速度的硬件装置来沟通，而不需要依赖于CPU的大量中断负载。
- 零拷贝主要的任务就是避免CPU将数据从一块存储拷贝到另外一块存储，主要就是利用各种零拷贝技术，避免让CPU做大量的数据拷贝任务，减少不必要的拷贝，或者让别的组件来做这一类简单的数据传输任务，让CPU解脱出来专注于别的任务。
- 零拷贝有两种：mmap和sendFile
- 传统IO拷贝需要4次拷贝和4次上下文切换
- mmap通过内存映射，将文件映射到内核缓冲区，同时，用户空间可以共享内核空间的数据。这样，在进行网络传输时，就可以减少内核空间到用户空间的拷贝次数。需要3次拷贝（①DMA将磁盘文件拷贝到kernel内核页缓存，用户空间通过mmap映射操作数据；②从kernel内核的页缓存通过CPU拷贝到socket缓冲区；③DMA从socket拷贝到网卡）和4次上下文切换
-
sendFile（linux2.1）：数据根本不经过用户态，直接从内核缓冲区进入到SocketBuffer，同时，由于和用户态完全无关，就减少了一次上下文切换。需要3次上下文切换，3次数据拷贝。- sendFile（linux2.4）：避免了从内核缓冲区拷贝到
Socketbuffer的操作，直接拷贝到网路协议栈，从而再一次减少了数据拷贝。需要3次上下文切换，2次数据拷贝。
代码实现：
//SocketServer接收数据 public class MySocketServer { public static void main(String[] args) throws IOException { ServerSocket serverSocket = new ServerSocket(8888); while (true) { Socket socket = serverSocket.accept(); DataInputStream inputStream = new DataInputStream(socket.getInputStream()); try { byte[] bytes = new byte[1024]; while (true) { int count = inputStream.read(bytes, 0, bytes.length); if (count == -1) { break; } } } catch (Exception e) { e.printStackTrace(); } } } }
/** * 传统的拷贝 */ public class MyOldClient { public static void main(String[] args) throws IOException { //创建socket连接 Socket socket = new Socket("localhost", 8888); //定义文件路径 String fileName = "E:\\学习\\springcloud.zip"; FileInputStream inputStream = new FileInputStream(fileName); //创建输出流 DataOutputStream outputStream = new DataOutputStream(socket.getOutputStream()); //定义缓冲区 byte[] bytes = new byte[1024]; long readCount = 0; long total = 0; long startTime = System.currentTimeMillis(); //TODO 这里要发生2次copy和2次上下文切换 //copy:1.将磁盘文件通过DMA拷贝到内核 2.将内核文件拷贝到用户(CPU拷贝) //上下文切换：1.用户态 -> 内核态 2.内核态->用户态 while ((readCount = inputStream.read(bytes))>=0) { total += readCount; //TODO 网络发送：这里发生2此copy 2次上下文切换 //copy：1.从用户拷贝到socket内核 2.从socket内核通过DMA拷贝到网卡 //上下文切换：1.用户态->内核态 2.内核态->用户态 outputStream.write(bytes); } long endTime = System.currentTimeMillis(); System.out.println("发送总字节数： "+total+" , 耗时： "+(endTime-startTime)+"ms"); outputStream.close(); inputStream.close(); socket.close(); } }
/** * 采用sendFile零拷贝 */ public class MyNewClient { public static void main(String[] args) throws IOException { SocketChannel socketChannel = SocketChannel.open(); socketChannel.connect(new InetSocketAddress("localhost", 8888)); socketChannel.configureBlocking(true); //定义文件路径 String fileName = "E:\\学习\\springcloud.zip"; FileChannel fileChannel = new FileInputStream(fileName).getChannel(); long m8 = 8 * 1024 * 1024; long count = (long)Math.ceil(fileChannel.size() * 1.0 / m8 ); long startTime = System.currentTimeMillis(); long total = 0l; long startPosition = 0; long endPosition = 0; int size = 0; while (size < count) { size++; endPosition = Math.min(size * m8, fileChannel.size()); //TODO 底层使用的就是sendFile，这里只发生了2次拷贝，2次上下文切换 //拷贝：通过DMA将磁盘文件拷贝到内核中，然后就是从(socket)内核拷贝到网卡。不需要经过用户 total += fileChannel.transferTo(startPosition,endPosition, socketChannel); startPosition = endPosition; } long endTime = System.currentTimeMillis(); System.out.println("发送总字节数： "+total+" , 耗时： "+(endTime-startTime)+"ms"); fileChannel.close(); socketChannel.close(); } }
六、Zookeeper在kafka中的作用
Kafka集群中有一个broker会被选举为Controller（先抢占的broker就为leader），负责管理集群broker的上下线，所有topic的分区副本分配和leader选举等工作。
Controller的管理工作都是依赖于Zookeeper的。
