zk相关问题

ZooKeeper踩坑点

如果说要选出应用开发者在使用ZooKeeper的过程中,最需要了解清楚的事情?那么根据我们之前的支持经验,一定是异常处理。

当所有一切(宿主机,磁盘,网络等等)都很幸运的正常工作的时候,应用与ZooKeeper可能也会运行的很好,但不幸的是,我们整天会面对各种意外,而且这遵循墨菲定律,意料之外的坏事情总是在你最担心的时候发生。

所以务必仔细了解 ZooKeeper 在一些场景下会出现的异常和错误,确保您正确的理解了这些异常和错误,以及知道您的应用如何正确的处理这些情况。

  1. 异常处理
    ConnectionLossException 和 Disconnected 事件
    简单来说,这是个可以在同一个 ZooKeeper Session 恢复的异常(Recoverable), 但是应用开发者需要负责将应用恢复到正确的状态。发生这个异常的原因有很多,例如应用机器与ZooKeeper节点之间网络闪断,ZooKeeper节点宕机,服务端Full GC时间超长,甚至你的应用进程Hang死,应用进程 Full GC 时间超长之后恢复都有可能。要理解这个异常,需要了解分布式应用中的一个典型的问题,如下图:
    在这里插入图片描述
    在一个典型的客户端请求、服务端响应中,当它们之间的长连接闪断的时候,客户端感知到这个闪断事件的时候,会处在一个比较尴尬的境地,那就是无法确定该事件发生时附近的那个请求到底处在什么状态,Server端到底收到这个请求了么?已经处理了么?因为无法确定这一点,所以当客户端重新连接上Server之后,这个请求是否应该重试(Retry)就也要打一个问号。

所以在处理连接断开事件中,应用开发者必须清楚处于闪断附近的那个请求是什么(这常常难以判断),该请求是否是幂等的,对于业务请求在Server端服务处理上对于"仅处理一次" “最多处理一次” "最少处理一次"语义要有选择和预期。

举个例子,如果应用在收到 ConnectionLossException 时,之前的请求是Create操作,那么应用的catch到这个异常,应用一个可能的恢复逻辑就是,判断之前请求创建的节点的是否已经存在了,如果存在就不要再创建了,否则就创建。

再比如,如果应用使用了exists Watch 去监听一个不存在的节点的创建的事件,那么在ConnectionLossException的期间,有可能遇到的情况是,在这个闪断期间,其它的客户端进程可能已经创建了节点,并且又已经删除了,那么对于当前应用来说,就miss了一次关心的节点的创建事件,这种miss对应用的影响是什么?是可以忍受的还是不可接受?需要应用开发者自己根据业务语义去评估和处理。
2.
SessionExpiredException 和 SessionExpired 事件
Session 超时是一个不可恢复的异常,这是指应用Catch到这个异常的时候,应用不可能在同一个Session中恢复应用状态,必须要重新建立新Session,老Session关联的临时节点也可能已经失效,拥有的锁可能已经失效。

3 zk锁的优势
1 服务挂掉可删除临时节点

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值