老师你好，我看你讲解通过版本号实现乐观锁的时候，你说如果真实系统中简单这么做的话是有问题的，这个具体是什么问题呢？我感觉使用版本号匹配的话，没有问题啊

Question

老师你好，我看你讲解通过版本号实现乐观锁的时候，你说如果真实系统中简单这么做的话是有问题的，这个具体是什么问题呢？我感觉使用版本号匹配的话，没有问题啊，没有思考出来有问题的场景，麻烦老师解答下~

Answer 1

翔仔 2019-09-10 11:26:42

同学好，首先，相比悲观锁，乐观锁的话是到提交的时候才会去检查是否能够执行成功，这也就意味着，针对写多读少的场景来讲，往往会造成写入要重试多次，增加读取次数，影响用户体验；其次，这里说的"简单这么做"是指单纯通过数据库表的版本字段去控制，这个会有问题，特别是针对分布式计算系统，如果只有单库，仅通过该库查询版本号会有性能瓶颈，如果将版本号副本存储到多个数据库中又会造成数据不一致

• 提问者 慕仔3163040 #1

  感谢翔仔热心解答。
  那针对写多读少的场景来讲，往往会造成写入要重试多次，增加读取次数，影响用户体验；针对这个问题业界有解决手段吗？
  以及分布式场景下，如果只有单库，仅通过该库查询版本号会有性能瓶颈；如果将版本号副本存储到多个数据库中又会造成数据不一致；针对这个问题，业界大概是怎么处理的啊？
  
  00

• 翔仔 回复 提问者 慕仔3163040 #2

  同学好，针对写多读少的场景，乐观锁都会存在失败重试的问题，可以依据业务折衷选择悲观锁来处理；数据库毕竟性能有限，可以通过cas的方式配合redis集群或者消息队列来代替

• 提问者 慕仔3163040 回复 翔仔 #3

  老师你好，这个使用cas并配合redis集群，再给具体描述下吧，感谢

点开查看后面1条评论