dubbo提供者配置 zookeeper和dubbo原理( 五 )


举个例子 , 如果应用在收到 ConnectionLossException 时 , 之前的请求是 Create 操作 , 那么应用的 catch 到这个异常 , 应用一个可能的恢复逻辑就是 , 判断之前请求创建的节点的是否已经存在了 , 如果存在就不要再创建了 , 否则就创建 。
再比如 , 如果应用使用了 exists Watch 去监听一个不存在的节点的创建的事件 , 那么在 ConnectionLossException 的期间 , 有可能遇到的情况是 , 在这个闪断期间 , 其它的客户端进程可能已经创建了节点 , 并且又已经删除了 , 那么对于当前应用来说 , 就 miss 了一次关心的节点的创建事件 , 这种 miss 对应用的影响是什么?是可以忍受的还是不可接受?需要应用开发者自己根据业务语义去评估和处理 。
SessionExpiredException 和 SessionExpired 事件
Session 超时是一个不可恢复的异常 , 这是指应用 Catch 到这个异常的时候 , 应用不可能在同一个 Session 中恢复应用状态 , 必须要重新建立新 Session , 老 Session 关联的临时节点也可能已经失效 , 拥有的锁可能已经失效 。…
我们阿里巴巴的小伙伴在自行尝试使用 ZooKeeper 做服务发现的过程中 , 曾经在我们的内网技术论坛上总结过一篇自己踩坑的经验分享
在该文中中肯的提到:
… 在编码过程中发现很多可能存在的陷阱 , 毛估估 , 第一次使用 zk 来实现集群管理的人应该有 80% 以上会掉坑 , 有些坑比较隐蔽 , 在网络问题或者异常的场景时才会出现 , 可能很长一段时间才会暴露出来 …
向左走 , 向右走阿里巴巴是不是完全没有使用 ZooKeeper?并不是!
熟悉阿里巴巴技术体系的都知道 , 其实阿里巴巴维护了目前国内乃至世界上最大规模的 ZooKeeper 集群 , 整体规模有近千台的 ZooKeeper 服务节点 。
同时阿里巴巴中间件内部也维护了一个面向大规模生产的、高可用、更易监控和运维的 ZooKeeper 的代码分支 TaoKeeper , 如果以我们近 10 年在各个业务线和生产上使用 ZooKeeper 的实践 , 给 ZooKeeper 用一个短语评价的话 , 那么我们认为 ZooKeeper 应该是 “The King Of Coordination for Big Data”!
在粗粒度分布式锁 , 分布式选主 , 主备高可用切换等不需要高 TPS 支持的场景下有不可替代的作用 , 而这些需求往往多集中在大数据、离线任务等相关的业务领域 , 因为大数据领域 , 讲究分割数据集 , 并且大部分时间分任务多进程 / 线程并行处理这些数据集 , 但是总是有一些点上需要将这些任务和进程统一协调 , 这时候就是 ZooKeeper 发挥巨大作用的用武之地 。
但是在交易场景交易链路上 , 在主业务数据存取 , 大规模服务发现、大规模健康监测等方面有天然的短板 , 应该竭力避免在这些场景下引入 ZooKeeper , 在阿里巴巴的生产实践中 , 应用对 ZooKeeper 申请使用的时候要进行严格的场景、容量、SLA 需求的评估 。
所以可以使用 ZooKeeper , 但是大数据请向左 , 而交易则向右 , 分布式协调向左 , 服务发现向右 。
写在最后感谢你耐心的阅读到这里 , 至此 , 我相信你已经理解 , 我们写这篇文章并不是全盘否定 ZooKeeper , 而只是根据我们阿里巴巴近 10 年来在大规模服务化上的生产实践 , 对我们在服务发现和注册中心设计及使用上的经验教训进行一个总结 , 希望对业界就如何更好的使用 ZooKeeper , 如何更好的设计自己的服务注册中心有所启发和帮助 。
最后 , 条条大路通罗马 , 衷心祝愿你的注册中心直接就诞生在罗马 。

推荐阅读