kafka 基础知识

kafka 的消息通过主题(类似文件夹)进行分类，消息以追加的方式写入分区（类似文件）

分区消息：由于一个主题一般包含几个分区，因为无法在主题范围保证消息的顺序，但可以保证消息在单个分区内的顺序

生产者：默认情况下生产者发送的消息会被均衡分布到所有分区，不过特殊情况下也会把消息写到特定分区

消费者：消费者通过检查消息的偏移量来区分已经读取过的消息，并将最后读取的偏移量保存在zk 或者kafka 上、每个分区只能被一个消费者使用，支持多个消费者互不影响的从一个单独的消息流上读取消息

broker ：接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存，并为消费者提供服务。返回已经提交到磁盘上的消息。一个分区从属于一个broker,一个分区可以分配给多个broker ，这个时候会发生分区复制，提供消息冗余

保留消息：要么超过一定时间，要么到达一定大小

多集群：MirrorMaker做类似消费生产者将消息从一个kafka集群生产到另一个集群

优势：多个生产、消费者，基于磁盘的数据存储（每个主题设置单独的保留规则，消息中断后可以继续消费）、伸缩性（可以扩展到上百broker）、高性能(特定服务器配置下，每秒百万级的性能)

如何选定分区数量： 
1.估算每天大概多少数据；
2.再计算每秒大概是多少数据；（单个主题）
3.再计算单台机子的每秒写入速度  可以使用fio做随机读写测试
4.根据此公式计算出Kafka机器数量（经验公式）=2*（峰值生产速度*副本数/100）+1
5.再根据主题每秒的吞吐量与消费者的吞吐量相除计算出分区数量（一分区对应一消费者）
6根据预估的kafka机器数与分区数定总机器数（一般一机一分区）
分区与topic类似高速车道和高速公路的关系，且分区下的消息不允许中途变道，正常情况下分区越多速度越快，不过也要考虑消费者的消费速率，以及集群的资源是否足够支撑partion的最大传输：
    假设我现在一个partition的最大传输速度为p，目前kafka集群共有三个broker，每个broker的资源足够支撑三个partition最大速度传输，那我的集群最大传输速度为3*3p=9p
     在不增加资源的情况下将partition增加到18个，每个partition只能以p/2的速度传输数据，因此传输速度上限还是9p，并不能再提升，因此吞吐量的设计需要考虑broker的资源上限。
同样多的partion代表了
更高的文件句柄：每个消息会使用一个索引文件一个消息文件
更高的内存：为了支持批量提交与消费，每个producer和consumer 都会占用10m 内存
更高的延迟：从producer 端到consumer端的延迟，即leader 分区只开启一个rsync线程同步数据给别的分区，分区越多，同步耗时越久，而kafka 只会在同步完之后才将消息提供给消费者
更长的恢复期: 

log.retention.ms 主题的消息保存时间
log.retention.bytes 主题单个分区消息保存大小。
message.max.bytes  单个消息的大小，默认1m, 生产者与客户端，以及其他的broker ，也要遵循这个参数的原则

资源的选择：
1、磁盘吞吐量， 生产者会等待服务确认这条消息已经成功提交后再发送下一条，也就是说，磁盘写入速度越快，生成消息的延迟就越低
2、磁盘容量， 包括测算每天接收的消息，每个topic、partition 保存的消息大小
3、内存则是影响客户端性能的主要因素。消费者从分区尾部，紧跟着生产者读取直接存放在系统的页面缓存的消息，这比从磁盘重新读取要快得多
以及网络和cpu

*** 作系统的调优：
对于大多数依赖吞吐量的应用来说，都要尽量避免内存交换，但不建议关闭vm.swappiness
xfs 的分配延迟算法比ext4 更安全
设置socket 与socket 的读写缓冲区、启用tcp的时间窗扩展等

生产者： 可以做错误逻辑的处理，可以使用同步或者异步两种发送方式， 控制消息格式的序列化器Avro ，以及自定义分区

消费者：消费者从属消费组，群组中的消费者均衡接受主题的一部分分区的消息，消费者会往_consumer_offset 的特殊主题发送包含对每个分区的偏移量的消息，每次消费者的变更都会触发 ”再均衡“， 也有不加入消费者群组的独立消费者

集群成员关系：kafka使用zookeeper 维护成员信息，每个broker 启动时会将自己的id 注册zk 的/brokers/ids 路径，当brokers从zk 上断开连接，这些临时节点就会自动从zk 上移除。在完全关闭一个broker 之后，如果使用相同id 的broker 加入集群，它会继承旧broker 相同的主题和分区

控制器：集群中第一个启动的broker 通过在zk 创见一个临时节点 /controller 让自己成为控制器，其他broker 也会监控这个临时节点随时准备成为控制器，控制器负责在节点加入或者离开时进行分区首领选举

复制：每个分区都有一个首领副本和多个跟随着副本，跟随者副本获取消息的请求和消费者是一样的，跟随者必须是足够同步才会在首领失效后成为首领