分布式锁设计实践

背景

开发时，碰到互斥问题，需要保证数据的一致性，避免重复性操作，我们就需要用锁来解决，简单的讲锁其实就是为了解决并发所带来的问题。

常见问题可查看从线上事故看mongodb事务ACID强弱

举个例子：库存,并发情况下，我们通过ab模拟，一次10个请求，假设我们下单去核销库存数量，先查询订单数量，后扣除库存，那么在10个请求并发下，我们就可能获取到了错误的库存数量。这在事务中我们认为是脏读或幻读。

数据库的并发控制机制不外乎就两种情况：

• 悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。

悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的，因此在悲观锁的环境中，在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁，加锁的时间可能会很长，这样可能会长时间的限制其他用户的访问，也就是说悲观锁的并发访问性不好。

• 乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性，乐观锁不能解决脏读和多读的问题。

乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的，因此乐观锁直到你准备提交所作的更改时才将对象锁住，当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短，乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象，那么当他完成了自己的更改进行提交时，数据库就会发现该对象已经变化了，这样，第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中，会增加并发用户读取对象的次数。

我们经常用的lock就是一种悲观锁。

乐观锁

todo

悲观锁

基于redis的分布式锁

关于redis的分布式锁，redis官方引出了一个算法，命名为redlock。
同时，提供了各类的实现可供使用，例如Redlock-rb for Ruby、Redlock-py for Python、Redisson for Java等。
因此，深入了解Redis分布锁的运用同时分析下node-redlock。