用TTL分布式锁
当我们使用TTL的分布式锁定时，锁可能会因为TTL配置而到期，并且该锁定尚未完成计算的过程，并且它将继续操纵其获取的对象，因为它不知道该锁定的对象该锁已经过期。我们如何避免这种情况？
When we have a distributed lock with TTL, it is possible that lock will expire because of TTL config and the process which had that lock has not finished computation and it will continue to manipulate the object for which it acquired lock as it doesn't know that lock has already expired. How can we avoid that scenario?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您要查找的解决方案称为“围栏代币”。长篇小说短 - 每个突变命令/操作都应包括令牌，而执行人应检查令牌是否仍然有效。
令牌只是一个数字，称其为“术语”，每次发布新锁时，该术语都会增加。
执行人具有简单的逻辑，它永远不会接受旧术语的命令。
可以说，这是真正避免任何相关问题的唯一选择。诸如具有时间戳或明确的锁版本之类的东西 - 所有这些都固有地容易出现各种种族问题。
我建议查看的另一个指针 - 红色锁定算法；以及它存在的问题 - 在此处提供更多信息： https://martin.kleppmann.com/2016/02/08/how-to-to-do-do-distribed-locking.html
The solution you are looking for is called "fencing token". Long story short - every mutation command/operation should include the token and the executor should check if the token is still valid.
The token is just a number, call it "term", every time a new lock is issued, the term get increased.
The executor has a simple logic, it never accepts commands with an old term.
Arguably, this is the only option to truly avoid any lock related issues. Stuff like having timestamps, or explicit lock releases - all of them are inherently prone to various race issues.
Another pointer I recommend to look at - Red Lock algorithm; and the issues it has - more on this here: https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html