前言
好久没有写博客了,到了阿里后空闲的时间更少了,很少有机会再专门研究技术了。这篇博客是刚去时在内网发布的一篇博客,利用了阿里的tair分布式缓存。tair是不开源的。但笔者觉得这篇博客还是有必要分享的,因为思路。很多人实现锁,并未真的抓住乐观锁、悲观锁的区别,理解上甚至会混淆。所以笔者把这篇博文搬出来,大家看思路就好。
正文
基于tair的分布式锁,在阿里内部技术社区已经有很多讨论了,不过基本上都是基于悲观锁的实现,基本特征是互斥或者阻塞。但实际的业务场景中,并不是所有的地方都需要悲观锁,写冲突很少的场景(例如:员工、门店信息修改),使用乐观锁更为合适。
那么如何设计和使用乐观锁呢?在看具体的代码前需要先对乐观锁的原理有个简单的了解。
乐观锁
乐观锁特点
version,版本控制,是乐观锁的根基。乐观锁并不是真的锁,它只是加了一个标识,用于区分数据是否有被意料之外的更改过。若没有,那就正常提交事物结束操作;若有,则回滚事物,撤销所有操作。所以,乐观锁除了需要应用于写冲突很少的场景,还要求系统支持事物回滚或补偿。
乐观锁操作流程
trylock(获取版本)--> transaction --> unlock(版本检查) --- 正常---> version+1 commit
--- 异常---> rollback
设计要求
- 1.只要能获取版本,就认为trylock成功
- 2.版本检查则更新version,一般是加1;否则,异常处理,version不变,并开启回滚
- 3.多事物同时获得乐观锁时,unlock只能有一个成功,其余的都应该失败
结合tair
有了上述设计要求,具体的实现就要参考tair api的特点了。这里笔者使用的是zcache,是蚂蚁基于 ldc 逻辑对 tair 的封装