kafka特性：
- 快速性：面对海量消息，具有快速存储和查询的实时性，虽然他是将消息存在磁盘，但是他是以顺序读写的方式访问磁盘，提高了性能
磁盘总有满的一天，怎样解决这个问题？
日志清理，日志压缩-
批量性：支持批量读写消息，并会对消息进行压缩
-
分区性：支持消息分区，分区内消息顺序传输，分区之间可以并发操作
-
容灭性：服务端：每个topic可以分为多个分区，每个分区的消息是不同的，每个分区有多个副本，只有leader负责读写，其他人负责同步消息到分区就行了，要是leader出现故障，在follower中重新进行选举就行了；消费端：消费者通过pull从服务端拉取消息的时候都会保存自己的消费位置
-
消费者，分区，topic，消费者组之间的关系
一个分区可以分配给一个消费者，一个消费者可以同时处理多个分区，多个消费者可以构成消费者组，一个消费者组可以订阅多个topic,要是一个消费者组里面的消费者增加或者减少，要通过rebalance进行平衡处理- 异步通信性:例如：A和B系统要通过网络进行数据交换，A可以将数据放在kafka中,然后A去处理别的事情，当B从kafka中取消息并处理后返回给kafka后,A将消息取了应解析响应
kafka元素定义
-
消息：由key和value\[\]byte数组组成，key是为了保证同一key都在同一个分区，value才是真实的数据
-
toipc&分区&log
topic:一个消费集合；一个topic可以有多个分区，不同分区的消息是不同的，每个消息在被添加在分区的时候，会分配一个offset,因此可以保证分区内消息的有序性，但是一个topic不同分区之间是没有有序性的，同一个topic的不同分区可以分配给不同的broker,来增加kfaka的并行处理能力
分区和Log:一个分区对应着一个log,消息写入分区实际就是写入log对应磁盘文件夹下面的Segment,Segment是有大小限制的，超大小限制会创建新的Segment,因为kafka采取顺序IO，只会在新的Segmen添加消息，索引文件采用稀疏索引-
保留策略：产生原因：无论消息是否被消费，都会存在磁盘，但是这样磁盘就会占满，因此就出现了他，通过启动一个线程，定期进行检查，有两种需要删除，1，超过指定时间就可以删出。2,超过指定日志大小就会删出
-
日志压缩：消息间的key-value的value是不断变化的，启动线程，定期将key保留最新value即可
-
broker:kafka server,他主要负责接收发来的消息，分配offset,将消息保存在磁盘；接收消费者或者其他broker的请求，根据请求做相应处理并返回响应，一般同一分区的多个副本会在不同的broker
-
isr集合：可用且消息量和leader差不多的集合，需满足两个条件：1,副本所在节点必须维持着与ZooKeeper的连接；副本最后一条消息的offset与Leader副本的最后一条消息的offset之间的差值不能超出指定的阈值，例如：要是有哪个副本因某种原因无法拉取leader的消息进行同步，超出某个阈值就会被踢出isr集合，要是他之后正常并且跟上了，就又加进来,总结就是要跟leader的数据差不多多
-
hw:一个offset,hw对于消费者来说是不可见的，但是消费者只能拉取hw之前的消息，他是由leader管理的，当所有的isr都保存消息到了hw这个offset时，leader就会递增hw的值，hw之前的证明leader和isr都有，被称为commit,简单来说，他就像是一个都得有的及格线
-
leo:所有副本都有的一个offset,指向追加到当前副本的最后一个消息的offset,当一个分区内添加了消息，那么他的offset就会增加
kafka为什么要有上面的设计?
-
同步复制和异步复制都有一些问题，将其结合才是最好的答案
-
同步复制：主要是看hw,但是这里看的不是isr和leader又就和可以递增hw,而是全部，要是一个follower副本宕机，那么hw就不能递增因为没有达到同意到达一个点，那么消费者一直只能拉取hw之前的
-
异步复制：leader在收到消息就认为消息提交成功，但是可能其他的follower还没有同步到，那要是此时leader驾崩了，从follower中选取的新的leader就没有leader消息，出现了消息丢失的情况
-
那么kafka就引入了isr,要是某个follower延迟过高，就提出isr,hw以就可以递增，要是leader宕机，就从isr中选拔，他们都有hw之前的信息，避免了消息的丢失
-
Cluster:多个broker可集成一个Cluster,Cluster会选择一个broker当作Controller,Controller时指挥中心，当他出现故障，就进行选拔新的Controller从broker中
-
消费者：从topic拉取消息，自己维护消费分区内的offset,可以实现一定的灵活性，比如，可以跳过某些key，或者对某些key进行反复消费
-
消费者组：消费者组订阅的topic的每个分区对应一个消费者，可以实现广播：多个消费者组订阅了一个topic,那就时的多个在不同消费者组里面的消费者对应一个分区；独播：将所有的消费者放在一个消费者族里面，也就是只有一个消费者组处理这个topic,他里面的分区也就只给一个消费者
消费者的水平扩展和故障转移
一个消费者可以消费多个分区，当他处理不过来的时候，就需要通过添加消费者进行reblance来实现水平扩展 当消费者出现故障时，他所负责的分区要转移给其他消费者
每天进步一点点！
疑问(欢迎评论区大佬们的发言-通俗易懂哈)
-
稀疏索引是什么？
-
leo的作用是什么？