Marzlam的博客

​同步条件：Follower 需在 replica.lag.time.max.ms 时间内追上 Leader 的数据进度，否则会被踢出 ISR 并标记为 OSR（Out-of-Sync Replica）。​OSR 兜底：若 ISR 为空，根据 unclean.leader.election.enable 配置决定是否允许 OSR 成为 Leader（默认禁止，防止数据丢失）​数据提交规则：消息必须被所有 ISR 副本确认后，才会被标记为已提交（Committed），此时消费者才能读取。

消息队列解耦异步削峰提到消息队列，脑海中就应该有这三个要素出来1：之前处理业务逻辑得话是以操作代码关注点进行得，比如一个电商系统中下单这个操作成功后会有多个后续操作，加积分，加金币，发短信等等，如果需要新的操作就加；2：慢慢的在这种操作前提下发现如果系统庞大起来，那么一个下单方法中可能操作越多，时间就越慢，于是乎为了解决响应速度，多线程开始异步处理这些操作来节省时间，但是相应的每次会进行线程相关代码的维护也是比较麻烦；3：所以将关注点聚焦于操作的思想转变至将关注点聚焦于 消息，每一个操作 对应的是一

什么是 Kafka?一种分布式的消息管理工具随着业务系统规模庞大，各个服务之间的消息传递变得频繁且繁琐，比如在电商系统中，下单流程中就涉及支付，短信，金额，积分各种服务的消息处理，若是直接A -B-C-D 4个服务建立联系，耦合性特别强，一旦某个服务要改可能涉及的服务也要去调整接口，可以发现没有缓冲区域，不太友好去应对这种 消息网过于复杂的情况。一是不太好找 二是不太好维护。所以需要一种能够帮忙处理 各个分布式 服务之间 消息传递的一个 中间商也就是 一种消息队列消息队列知识消费消息模式..