网站开发涉及到哪些知识产权,wordpress 替换图标,网页开发代码,个人的网站怎么备案1.生产者缓存机制--高性能
生产者缓存机制的主要目的是将消息打包#xff0c;减少网络IO频率
kafka生产者端存在消息累加器RecordAccumulator#xff0c;它会对每个Partition维护一个双端队列#xff0c;队列中消息到达一定数量后 或者 到达一定时间后#xff0c;通过sen…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给BrokerPID是该Producer的唯一标识SN是消息序号。Broker端会维护这个SN的序列号。如果发送端SN服务端SN则重复应答即可如果发送端SN服务端SN则说明发送的消息有丢失如果发送端SN服务端SN1则正常接收消息。
多分区发送的幂等性问题需要事务机制来保证
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的最后一个OffsetHW(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分布均匀如果业务异常则降级处理人工介入分析该问题。
