Zookeeper lock #111
Zookeeper lock #111
Conversation
|
Hi @ZLBer, welcome to mosn community, Please sign Contributor License Agreement! After you signed CLA, we will automatically sync the status of this pull request in 3 minutes. |
|
@ZLBer thanks for your contribute! could you please add a quickstart for this component? such as a |
|
恩恩 目前的代码只实现了组件部分，其实还需要一些细碎的配套工作，包括在layotto的main里注册组件，demo（client、config.json)，文档，这些工作量不大但是很有必要 稍等哈我在写《组件开发指南》，描述下有哪些配套工作 |
|
@zhenjunMa @seeflood fine, i will add a quickstart after the guide book is finished. |
|
@ZLBer Hi, I just added a developer guide.See https://github.com/mosn/layotto/blob/main/docs/zh/development/developing-component.md Please improve this pr according to the guide. |
|
@ZLBer 我在《组件开发者指南》中补充了单元测试的mock方法，供参考~ |
|
有几个问题抛出来讨论下：
于是，同一时刻有两个app有同一把锁，出现了正确性问题 |
|
@seeflood 2.为什么不复用连接? 一开始想的是， 为了保证在任何情况下，都可以释放锁， 依赖于临时节点和connection的生命周期保持一致，所以需要connection和每次请求保持一致，当超过expireTime时间时需要主动close掉connection，但复用好像也不存在错误的情况？
|
恩恩，不管是阻塞锁还是非阻塞锁，其实都有这个带锁故障问题，我理解zk是靠session timeout解决的，但是这东西是每个连接固定好了的，不能既复用连接、又在每次处理请求时改timeout值 这个问题本质上是：api定义成了要求超时时间任意，但是zk（不开启ttl节点功能的话）不能任意。 那么推理一下我们有以下几种选择：
Life is hard,and defining API is harder! |
|
所以如果我们想追求复用连接的话，那么有几条路： 方案c.复用连接，tryLock后起个定时任务删节点实际ttl=session_timeout or 定时任务ttl（用户传的ttl) 对比一下： 方案c的正确性保证并没有比原生方案差 但是这里coding的时候需要处理”定时任务失败，但是过了一会心跳恢复、session没断“的情况，需要对定时任务做重试 如果不考虑定时任务重试的话会有问题，比如我举个特殊场景： 网络抖动，app unlock失败，app无视这次失败不做重试；但是这段时间sidecar和zk server心跳还正常 10秒后，sidecar定时任务启动，准备删节点，但是这会儿sidecar和zk server网络抖动了，定时任务删除失败 失败后，我们期望session timeout、节点被删，但不幸的是过了会心跳好了（zk sdk自己有一些fail over策略，连接断了后会fo到别的zk server，尝试心跳、维持之前的session） 于是，定时任务没有重试，节点永远不会被删，死锁发生了 方案d. 改API，不要传什么ttl了方案e. 用ttl node实现这个功能，不开ttl的zk不支持 |
为什么redis实现这个API简单，为什么zk实现这个API这么复杂，复杂度来源于哪？本质上是因为：TTL是个好东西，如果server端支持TTL，那么多个节点之间不需要做状态同步、故障检测，反正故障的时候server来自动删除锁，app和sidecar啥也不用管，就是俩无状态节点，偷懒美滋滋； 而如果server端不支持TTL，我们就要做多个有状态节点（app、sidecar、server)之间的状态同步、可靠故障检测，就有了上面这些问题 （zk原生sdk里的锁，本质上是帮用户实现了这些状态同步、故障检测） 分布式锁防止死锁的两种模式a. 基于server TTL 的无状态架构 b. 基于节点之间状态同步、故障检测的有状态架构 两种模式对sdk的依赖如果选择了a,那么app端不需要sdk，直接用grpc api就行 如果选择了b，那么app端必然有逻辑，必然要开发sdk，想做到app不依赖sdk、直接用grpc api不现实（除非它自己实现sdk的逻辑） 后续API的演进方向我们后面要加阻塞锁Lock(),其实也可以弄两种API,LockWithTTL(key,expire)和Lock(key) 想不依赖sdk的，调LockWithTTL；愿意依赖sdk的，调Lock |
|
@seeflood 所以我们现阶段先采用哪个方案呢？ |
|
@ZLBer 我理解其实方案a和方案c的差别只是复用连接。方案a也要考虑上面的定时任务删除失败了怎么重试 所以我个人倾向于选择c方案+允许通过ttl node来实现 如果能一步到位，我们就c方案+ttl node，如果太麻烦了我们就一步一步来？这样如何~抛出来讨论下 |
|
关于api演进的一种思路，供讨论：
|
|
@seeflood |
同意！ @ZLBer 我本来想干脆不管这种情况了，是因为看zk的文档，说zk server有配置、限制session_timeout的范围，总归不能设置太大。但是确实方案a对于”粗粒度锁"的正确性保证更好一些，那就方案a+ttl node好了，性能问题我们倒是可以通过连接池优化 |
|
补充一下，关于a方案性能问题的思考：我们后续可以优化成连接池（现在先不用管） 当然这些以后做性能优化的时候再说 |
# Conflicts: # components/go.mod
|
@seeflood |
# Conflicts: # cmd/layotto/main.go # components/go.mod # components/go.sum # go.mod # go.sum
# Conflicts: # components/go.mod # components/go.sum # go.sum
|
@ZLBer CI流程里校验格式化没通过~ 然后git提交下有改动的东西即可 |
|
另外就是文档侧边栏需要加上~ |
|
@seeflood |
|
这个pr厉害了，升级golang/mock包后，发现了以前的configuration api相关的ut错误 |
Codecov Report
@@ Coverage Diff @@
## main #111 +/- ##
=======================================
Coverage 46.95% 46.95%
=======================================
Files 41 41
Lines 1640 1640
=======================================
Hits 770 770
Misses 820 820
Partials 50 50 Continue to review full report at Codecov.
|
|
Thanks again for your contribution! |
What this PR does:
add zookeeper lock
Which issue(s) this PR fixes:
Fixes #104
Special notes for your reviewer:
@seeflood
Does this PR introduce a user-facing change?: