wordpress 多说 httpsseo搜索引擎专员

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.消息积压问题--高可用

1. 如果业务正常，只是因为消费者消费太慢，则增加partition数量，增加消费者数量即可。
2. 发送消息时，尽量保证消息在各个Partition分布均匀；
3. 如果业务异常，则降级处理，人工介入分析该问题。