kafka学习(二)

内部工作原理 && 可靠数据传递

内部工作原理

控制器：一个集群中只能有一个，负责分区leader的选举

每一个分区有一个首选首领

broker在其所监听的端口上运行Acceptor线程，这个线程会创建一个连接，并将它交给Processor线程处理，Processor线程负责从client获取请求消息并放进请求队列交由IO线程处理，然后从响应队列中获取响应消息。

都需要发送给分区的首领副本，因为首领副本拥有这个分区完整且最新的信息，如果发到一个不包含改首领副本的broker上，会报错

一般客户端只能读取被写入到所有同步副本的消息，防止首领崩溃后，这些消息消失。

对broker的分区分配，一个原则是每个分区的副本分配在不同的broker上，或者指定机架信息，则副本应该处于不同的机架的broker上
kafka将分区分成了若干个片段，并且为了帮助broker快速定位偏移量，为分区维护了一个索引，索引将偏移量映射到片段文件和偏移量在文件里的位置。
清理：
日志片段分为：
- 干净部分（旧的数据）
- 污浊部分，清理线程读取该部分，并创建map(可以节省空间的来清理)
从最旧的消息与map进行比对，如果旧消息的键map中没有，说明它就是最新的，就把其复制到替换片段，如果有，则说明会被后面的包含了，略过。之后将整个替换片段替代原始片段就完成了清理工作。

滞后的同步副本会导致生产者和消费者变慢，因为前面提到过消息被认为已提交的前提是被所有同步副本接收。非同步副本对这个性能不会产生影响，但如果非同步副本的数量越多，意味着复制系数越小，宕机的风险越大。

主题的复制系数：即每个分区总共会被n个不同的broker复制n次（每个broker复制一次）

不完全首领选举：

unclean.leader.election ：true 意味着允许不同步的副本成为leader，否则就需要等旧首领重新上线

min.insync.replicas 设置最少同步副本

对于生产者要处理的错误分为可自动处理和开发者手动处理。前者根据broker返回的错误信息判断是否可通过重试解决，带来的问题是消息重复，解决方法是消息里加上唯一ID或者消息是幂等的。