假设 机房3突然和机房2和机房1的网络断了 即机房3出现了网络分区 网络划分 机房间网络划分 机房3 机房内还是通的 理论层zk集群还可以用 实际情况整个zk集群都不可用了 一旦网络发生分区 就会选举多个主节点 就会不一致了
原因是
ServerB2作为新服务 此时注册ZK不成功 因为机房3中的ZK节点已经脱离了ZK集群 不能通过ZK对服务进行扩容、重启、部署
期望的效果
期望的是跨机房不可用但机房3中的ServiceA调用ServiceB是可以用的 虽然说有多机房 很多情况下更鼓励在同一个机房内服务之间调用 机房内服务调用 服务内响应延迟会变的很低 服务每个机房都成了孤岛 每个机房调用只拿到本机房的服务列表 反而有更好的服务链路调用效果 千万不能因为自身的任何问题 破坏了服务之间的联通性
原生ZK
但原生的ZK同机房的服务调用也不可用 因为ZK是CP模型 为了保证网络分区下P （脑裂下）C一致性 A的可用性也让它不可用
ZK存储了大量的信息
1、写到zk里面的任何一个写操作 为了保证cp 都会在从节点上都会在写一份 2、keepalive 、心跳信息、节点注册 全部都会在集群中同步 3、服务发布大量注册写请求 4、毫秒级服务健康状态的写请求
ZK集群最多支持1000台
zk是分布式的 根据paxios协议 选zk主 zk从 zk主 是写入单点 不能水平扩展 从节点可以扩展 类似mysql 主从 主只能有一个 zk集群规模不能很多 1000台撑死了 集群有1万台 就会不堪负载
根据业务功能 垂直拆分集群?
根据业务功能 垂直拆分集群 58 房产、招聘、二手车 房产有自己的zk集群 招有自己的zk集群 二手车有自己的zk集群 破坏了公司整体服务的连通性 彼此不可以调用了 业务整合联通性不可预知 比如搜索业务1000台机器zk 推荐业务1000台机器zk 若将搜索和推荐做一个集群 zk 2000台 就不行了
为什么zk 到1000台就不行了？
有大量的持久化存储和事务
其实不需要存储 目的是为了做cp 所以存储了
ZK 2PC 两阶段提交事务
leader和其他节点数据提交 全部是二阶段提交 2PC(Propose ACK Commit) 强一致性 每一步都是2pc 同步阻塞写
ZK探活机制
track机制即tcp长连接 向网络发一个ping命令
