服务端处理架构
资料来源于网络
网络线程池：
接受请求，num.network.threads，默认为 3，专门处理客户的发送的请求。
IO 线程池：
num.io.threads，默认为 8，专门处理业务请求。也就是它不负责发送响应，发送响应还是由网络线程池处理。
当遇到性能瓶颈的时候可以适当的调整这两个参数
服务端消息存储文件布局
1 Topic 文件结构
Segment 文件结构
命名规则：一个 segment 的名称其实是当前 segment 第一条消息的偏移量,也就是说一个segement如果写不下了就会生成新的segment。
查找机制
- 将所有的 segment 文件名进行生序排列然后找到偏移量最后落在哪个 segment 对象上（采用二分，因为文件名是有序的）。
- 继续从这个 segment 里面的 .index 文件找到消息的物理偏移量，也就是对应图中的.index偏移量，最后拿着物理偏移量去 .log 文件找到最终的实体消息，非常的迅速。
删除机制
按照时间过期多少删（默认7天）、按照大小来删
服务端数据的一致性
其实也就是分区和副本之前的一致性。比如说我们P0有9条消息，因为每个节点同步数据（网络，IO等原因）所以导致R0 和 R3 之间的数据并不一致。
HW：高水位，消费者消费最高的位置，其实也就是木桶原理，所以只能到下面图中的第四条消息。
LEO：log写文件的最后一个位置。
ISR：也就是一个分区和备份节点的队列。比如P0,R0,R3.
如果我们的备份节点挂掉了：
1 首先它会从ISR中剔除，当恢复正常的时候，会向主分片获取 HW 高水位线，与自己的 LEO 比对，如果自己的 LEO 超过 HW 则干掉超过的部分，小于的话就从主分片复制数据过来。
2 复制的时候，如果复制之后的 LEO 与 HW 持平的话，那么就会重新加入到 ISR 同步队列中
如果我们的主分区挂掉了：
1 从ISR中剔除，选择数据最多的数据为主分片。
2 活过来的时候，发现已经有顶替的 leader 角色（主分片）了，那么就跟随，也就是向 leader 获取 HW 高水位线，与自己的 LEO 比对，大于 LEO 则删除，小于 LEO 则从 leader 这边复制数据过去。
3 复制数据的进度如果赶上了主分片的 HW 的话，那么就继续加入到 ISR 队列中。
但是我们主分片数据最多，为什么要把后面的数据干掉呢，这样不是会丢失消息吗？
这样其实是保证了数据的一致性，也就是保证分区和备份节点的都是同样的进度。
数据不丢失问题是由Producer来保证的，也就是有重试机制，如果没有发送成功的话，就会从新发送，但是消费者一侧一定要做幂等。
