• 慌张而黑糖
    2020-08-06
    栅栏令牌怎么有点乐观锁的意思，感觉是悲观锁和乐观锁的结合

    作者回复: 栅栏令牌是悲观锁，在锁被判定超时的情况下，可能其实锁持有方并没有完全死掉，之后它又回来更新共享资源，栅栏令牌是对这种情况的一个修复。

    共 2 条评论
    4
  • what if
    2020-10-23
    老师请教个问题，数据库本身就有实现丰富的锁机制，锁管理，死锁检测，锁超时处理，这里设计乐观锁，还有悲观锁时，都把这部分逻辑放到应用侧去实现，而不是DB里实现，是因为DB不容易水平扩容以及DB锁代价高的原因吗？

    作者回复: 数据库内部的锁，是为了解决数据库内部的并发控制而设计的，它并不能直接应用到数据库以外的场景。为了支持业务上一些需要锁机制的场景，某些数据库也对外提供一些锁机制。这两类锁是面向不同场景的锁。 而业务上一些需要锁机制的场景，可以借助数据库表所对外提供的一些锁机制，来实现乐观锁和悲观锁。当然，除了数据库依赖，redis或者zookeeper之类也提供锁机制。另外，除了锁的具体底层实现以外，一般业务端还要写一些封装代码。

    
    1
  • tenyears
    2021-02-28
    请假下波波老师企业中用的分布式锁zk 实现用的多还是redis 用的多？

    作者回复: 对于分布式锁场景，中大型互联网公司zk用得多，小规模公司redis/DB用得多。因为总体上小规模公司更多，所以我认为redis/DB的使用量更广泛。 打个比方，zk是重量级武器，功能更强大，运维部署成本也高。redis是轻量级武器，功能只能算够用，但是运维部署成本低。

    
    
  • what if
    2020-10-23
    悲观锁里的栅栏令牌，看上去就是基于版本号的乐观锁: )

    作者回复: 有点类似

    
    
  • Sam Fu
    2021-11-14
    这里面的乐观锁机制很好用。尤其是在状态机更新的时候，校验更新时数据库中中的状态必须等于预期的状态，否则更新失败。
    
    2
  • 丁小明
    2020-11-19
    还可以通过一种watch dog的机制，业务方主动续约延长过期时间，不过这种机制无法应对gc导致的jvm卡顿导致延期的问题。
    
    1
  • 九时四
    2022-11-05 来自北京
    栅栏令牌锁场景:如果微服务1比微服务2提前更新数据,还是有问题啊,怎么保证只更新一次?
    
    