“乐观锁”是咱们程序员在面试的过程中经常会碰到的，那么这里我们来聊一下它的重要性。
乐观锁与高并发
如果面试官和你聊“乐观锁”，那么大概率是要延展到“高并发”。技术人都知道“乐观锁”适合“读多写少”的业务场景，并且可以较大程度的提高业务接口的吞吐量，还能保证数据一致性，从这个角度上来看，它是真的太香了。当然这里的香是相对于“悲观锁”而言的。
是不是使用“乐观锁”之后，我们的业务接口就可以高枕无忧了呢？答案是否定的，乐观锁只是降低了“悲观锁”的锁冲突的概率，或者简单的说是为了延缓锁冲突。
使用乐观锁会带来哪些技术风险呢？
- 如果是框架实现的乐观锁，框架都会有统一的乐观锁异常机制，乐观锁冲突次数达到阈值之后，会触发异常机制，并将异常显示的抛给业务服务。如果业务服务，没有正确的处理这个异常，则会影响业务服务接口的可用性；
- 如果是自研的，则需要针对“乐观锁”做好超时调用和异常机制的可用性保护措施。
当业务服务的并发量上来之后，“乐观锁”反而成为影响业务服务吞吐量的定时炸弹，为什么要这么说呢？咱们可以这样想，10个线程处理一行数据，只能有一个线程处理成功，其他9个全是失败的。假如，你处理的数据是热点数据，同时有10000个线程在处理热点数据，造成锁冲突的概率是非常高的。并且还有一个致命的问题，那就是“乐观锁”的流量会触及到系统资源，也就是会真实的暂用业务服务的系统资源，而“悲观锁”从应用层就拦截了业务流量。
所以这个就解释了“为什么乐观锁适合读多写少”的问题，主要目的是“既要提高业务接口的并发性，也要减少锁冲突带来的不必要的性能损耗，尤其是并发量非常高的业务场景”。
但是真实的业务场景中，尤其是中小型公司，业务接口并发量能够达到100或者1000就已经很不错了，你想想，一个订单接口，并发量达到1000是什么概念，老板估计都是偷者数钱了。
面试官聊“乐观锁”，就是要考察咱们程序员的“高并发”的处理能力。
乐观锁与性能
上面说到了“乐观锁”在一定的并发量之后，会严重的影响业务接口的可用性，甚至会拖慢整个微服务体系。那么问题来了，我们如何检测这个“并发量的阈值了”，这个也是面试官希望候选人知道的知识点。
咱们的业务接口在使用“乐观锁”之前和之后，接口性能有多少提升，这些都是程序员在使用“乐观锁”之后需要考虑的。
好吧，如果是笔者，笔者会使用压测工具来压测性能，并得出接口的性能指标。与此同时，会结合全链路追踪系统，实时的追踪“添加了乐观锁”之后的业务和业务上下游的其他业务服务的线上运行指标。这样我们就可以充分的了解接口的性能，并结合峰值和峰谷阶段的并发度和性能指标，动态的调整接口的超时时间、乐观锁失败的重试次数等等。当然这个规则的调整都是实时的，业务服务是可以感知的。
乐观锁与数据
为什么说“乐观锁”与数据关系很大了，因为咱们使用“乐观锁”就是为了保护我们数据的一致性，所以如果聊乐观锁，肯定会考察与数据相关的知识点，比如MySQL的锁，ElasticSearch的乐观锁等等，其实还有很多大数据框架底层也采用了乐观锁，比如Spark等，只是实现乐观锁的形式不太一样，有些是使用Version，有些是使用时间戳。
这么说“乐观锁”如果往前延伸，那就是涉及到数据处理了，好吧，从面试官的角度去看这个确实是一个好问题。
公众号初衷
知识输出是笔者的初衷，借助知识输出，能够认识更多的牛人,能够和牛人沟通，也是自己技术提升的一个机会。
