首先绝大部分业务,读要比写的操作多,而且相差的不是一点半点而是几个数量级。
说白了就是新增、修改、删除的次数要远远比查询的次数少,所以负责写的节点的压力一定是比负责读的节点压力小。
其次 ZK 其实并不是 Leader 负责写,而是由 Leader 负责通知其他 Follower 写。每个 Follower 也是可以接收写请求的,只不过自己先不执行写,而是要转发给 Leader,等 Leader 通知它写了、才开始写。这一点跟其他一些读写分离方案不太一样,比如 MySql 读写分离的只读节点压根就不接受写请求。
最后,ZK 写时有半数 ACK 机制,外加 ZAB 协议来确保写入时强一致的,就读取而言确实可能读到非最新数据,但其本身是单调读的,再加上提供了 Watch 功能,所以可以确保最终一致。
所以你问怎么办?Watch 后再读一遍呗。
P.S. CAP 这玩意儿一般来说都是保 AP,C 的话选最终一致,有的甚至就没 C 了;CP 的话也有。但既要 AP 还要强一致的,就没有了。
P.S.P.S. ZK 当初有一些设计最后被证明不太合理,但出于兼容性等历史包袱的考虑,也只能这么着了。可以考虑用用后起之秀 etcd。
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…