共计 976 个字符，预计需要花费 3 分钟才能阅读完成。
前段时间在看 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 上线与下线都比拟无感
本文首发于 cartoon 的博客
转载请注明出处:https://cartoonyu.github.io
正文完