为何使用消息系统
- 解耦：跨部门或团队协作
- 削峰：减少高峰流量对系统的冲击
- 异步：处理比较耗时或者实时性不是很高的任务
- 有序：可以保障数据有序处理
应用场景
- 流量统计，例如PV，UA
- 系统监控，例如CPU，内存使用率
- 日志收集，业务中的记录存储，秒杀活动
点对点与发布订阅区别
-
点对点：Queue，不可重复消费
-
发布/订阅：Topic，可以重复消费
kafka 为什么快
Kafka速度的秘诀在于，它把所有的消息都变成一个批量的文件，并且进行合理的批量压缩，减少网络IO损耗，通过mmap提高I/O速度，写入数据的时候由于单个Partion是末尾添加所以速度最优；读取数据的时候配合sendfile直接暴力输出。
Kafka的ACK机制
-
acks=0，生产者在成功写入消息之前不会等待任何来自服务器的响应.
-
acks=1,只要集群的leader分区副本接收到了消息，就会向生产者发送一个成功响应的ack.
-
acks=all,表示只有所有参与复制的节点(ISR列表的副本)全部收到消息时，生产者才会接收到来自服务器的响应，此时如果ISR同步副本的个数小于min.insync.replicas的值，消息不会被写入.
为什么不支持读写分离
Redis和MySQL都支持主从读写分离，我个人觉得这和它们的使用场景有关。对于那种读操作很多而写操作相对不频繁的负载类型而言，采用读写分离是非常不错的方案——我们可以添加很多follower横向扩展，提升读操作性能。反观Kafka，它的主要场景还是在消息引擎而不是以数据存储的方式对外提供读服务，通常涉及频繁地生产消息和消费消息，这不属于典型的读多写少场景，因此读写分离方案在这个场景下并不太适合。
如果leader crash时，ISR为空怎么办
kafka在Broker端提供了一个配置参数：unclean.leader.election,这个参数有两个值：
- true（默认）：允许不同步副本成为leader，由于不同步副本的消息较为滞后，此时成为leader，可能会出现消息不一致的情况。
- false：不允许不同步副本成为leader，此时如果发生ISR列表为空，会一直等待旧leader恢复，降低了可用性。
Kafka中是怎么体现消息顺序性的？
Kafka只能保证分区内消息顺序有序，无法保证全局有序
Kafka稀疏索引
-
稀疏索引： 在稀疏索引中，不会为每个搜索关键字创建索引记录。此处的索引记录包含搜索键和指向磁盘上数据的实际指针。要搜索记录，我们首先按索引记录进行操作，然后到达数据的实际位置。如果我们要寻找的数据不是我们通过遵循索引直接到达的位置，那么系统将开始顺序搜索，直到找到所需的数据为止。
-
Kafka的segment index file采取稀疏索引存储方式，它减少索引文件大小，通过mmap可以直接内存操作，稀疏索引为数据文件的每个对应message设置一个元数据指针,它比稠密索引节省了更多的存储空间，但查找起来需要消耗更多的时间。