kafka不支持读写分离原理分析
作者：cartoon
这篇文章主要为大家介绍了kafka不支持读写分离原理分析,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
引言
前段时间在看 kafka 相关内容，发现 kafka “所有的”读写流量都在主 partition 上，从 partition 只负责备份数据。
那么为什么 kafka 从 partition 不跟其他中间件一样承接读流量？
读写分离的初衷
读写分离的初衷我觉得是利用读流量 & 写流量不同的特性做针对性的优化，而这两种流量我觉得区别如下
| 读流量 | 写流量 | |
|---|---|---|
| 业务特性 | 展示类的业务 | 操作类业务 |
| 流量占比 | 高 | 低 |
| 可接受数据延迟 | 较大 | 非常小 |
| 增长的可预见性 | 高峰/安全攻击可能会突发增长 | 总体平稳 |
使用 kafka 的业务特征
- 操作型业务，consumer 消费 producer 生产的消息，进行自身业务，这个消息就类似于 trigger
- 可支撑的流量较大，并且可支撑下游 consumer 较多，rebalance 需要一定的时间
kafka 架构
- 以 topic 为单位，一 topic 可拆分多个 partition，每个 partition 都可以有多个从 partition，不同 partition 分布在不同 broker 上
以 partition 为单位，形成 AR（Assigned Repllicas），ISR（In Sync Repllicas），OSR（Out Sync Repllicas），主 partition 接收到消息后按照 ack 策略同步到 ISR 中从 partition
ack = 0，producer 发出消息后就不管了
ack = 1，producer 发出消息写入主 partition 所在 broker 的磁盘就算成功
ack = all，producer 发出消息写入主 partition 以及 ISR 上所有副 partition 的磁盘才算成功
kafka 没有主从读写分离的原因
不能主从读写分离的原因
kafka 承接的大多是操作型业务，这部分读操作对数据延迟非常敏感。
kafka 主从同步为半同步复制，并且有部分 partition 在 OSR 上，数据延迟较大
kafka 主 partition 接收到消息后，可以根据 ack 策略落盘，如果不是 all 的话存在数据丢失的风险
不需要主从读写分离的原因
kafka 本身就是多 partition 的架构，不同 parition 在不同的 broker 上，多主节点的结构本身分流了流量
kafka 本身就有成熟的 rebalance 机制，partition 上线与下线都比较无感
以上就是kafka不支持读写分离原理分析的详细内容，更多关于kafka不支持读写分离的资料请关注脚本之家其它相关文章！