网站导航还值得做wordpress 阿里云 漏洞
1.生产者缓存机制--高性能
生产者缓存机制的主要目的是将消息打包，减少网络IO频率
kafka生产者端存在消息累加器RecordAccumulator，它会对每个Partition维护一个双端队列，队列中消息到达一定数量后 或者 到达一定时间后，通过sender线程批量的将消息发送给kafka服务端。（批量发送）
2.发送应答机制--高可用
发送应发机制保证了消息可以安全到达服务端！
Producer端一个不太起眼的属性ACKS_CONFIG：
- acks = 0，生产者不关心broker的应答；不安全，但是速度快
- acks = all or -1，生产者需要所有partition的应答；最安全，但是效率低一些
- acks = 1，生产者只需要Leader partition的应答；中和
3.生产者消息幂等性--高可用
防止消息重复发送到服务端Broker
（解决了单分区发送的问题）
每个Producer发送消息到Broker的时候，会携带<PID,SN>给Broker，PID是该Producer的唯一标识，SN是消息序号。Broker端会维护这个SN的序列号。如果发送端SN<=服务端SN，则重复应答即可；如果发送端SN>服务端SN，则说明发送的消息有丢失！如果发送端SN=服务端SN+1，则正常接收消息。
（多分区发送的幂等性问题需要事务机制来保证）
4.Controller Broker和Leader Partition--高可用
监控作用
基于Zookeeper的Controller选举机制，Controller Broker管理所有Broker的健康状态；
Leader Partition管理该Topic下的所有partition；
当一个broker中存在多个Leader partition的时候，会触发Leader partition的自平衡机制，涉及到大量消息的转移和同步。
5.Partition的故障恢复机制--高可用
保证各partition的数据一致性
- LEO(Log End Offset): 每个Partition的最后一个Offset
- HW(High Watermark): 一组Partiton中最小的LEO
当follower partition故障时，该Follower节点会读取本地记录的上一次的HW，将自己的日志中高于HW的部分信息全部删除掉，然后从HW开始，向Leader进行消息同步。
当Leader partition故障时，会选举出新的Leader partition，其他Follower会将各自的Log文件中高于HW的部分全部清理掉，然后从新的Leader中同步数据。
如果follower partition的HW不一致，那kafka通过epoch机制来进行数据同步。
（每个Leader Partition在上任之初，都会新增一个新的Epoch记录。这个记录包含更新后的epoch版本号，以及当前Leader Partition写入的第一个消息的偏移量。接下来其他Follower Partition要更新数据时，就可以不再依靠自己记录的HW值判断拉取消息的起点，而是根据这个最新的epoch条目来同步）
6.消息存储--高性能
三个日志文件存储kafka的消息，.log存储实际消息，.index以偏移量为索引，.timeindex以时间戳为索引
.log只可以进行消息顺序写的追加，不支持修改和删除！顺序写的效率很高！
.index类似于跳表！<offset,pos>，跳表的查询效率高，redis也用到跳表！
7.零拷贝--高性能
producer发送给broker的消息通过mmap持久化到磁盘；
consumer通过sendfile方式拉取broker的消息；
8.消费者防止消息重新消费--高性能
1）消费者通过订单的id去查看该消息是否已被消费过（消息如果被消费了，则该id已存在）
2）通过redis维持offset，消费时将消息的offset与redis中的offset进行比较
9.kafka消息零丢失方案--高可用
- 生产者发送消息到broker不丢失：acks = -1或者all；或者1。
- broker保证消息不丢失：1）配置多备份因子；2）合理刷盘频率
- 消费者防止异步处理丢失消息：手动提交offset更安全一些
10.消息积压问题--高可用
- 如果业务正常，只是因为消费者消费太慢，则增加partition数量，增加消费者数量即可。
- 发送消息时，尽量保证消息在各个Partition分布均匀；
- 如果业务异常，则降级处理，人工介入分析该问题。