前面，我们讨论了乐观锁和悲观锁的实现，这两者都是在整体架构的场景中。 现在，让我们总结一下，看看如何在分布式情况下实现锁定机制。 常见场景让我们看看下一个场景。假设我现在要做一个分布式系统下的业务逻辑消费动作。如何保证我的消费动作只消费一次，不重复消费？有同学第一时间想到了MQ，比如Zookeeper。 今天，我们就不说MQ了。其实核心是代码执行的锁定机制。 让我们看另一个场景。我们有一个需要经常检查数据库DB数据的接口。如果场景允许，我们会经常给它增加一层缓存，并设置过期时间。 假设在某个时刻，缓存到期，但此时并发量非常大，大量请求会穿透数据库请求数据，产生缓存雪崩效应。 所以可以考虑锁机制，只让一个请求执行查询DB升级缓存的操作。 回顾一下基本原理，我们之前讲过锁的原理。分布式锁也是一样。要实现它们，必须满足以下要求:1 .互斥:任何时候只有一个客户端可以锁定它们；2.避免死锁:要充分考虑到某个用户终端在锁持有期间崩溃，不能导致后续其余用户锁不上；3.谁锁谁解锁:锁和解锁必须是同一个客户端，否则很容易出现A客户端解锁B客户端，导致锁机制失效的情况。 例子我们仅以Redis为例来说明分布式锁的实现。 以Redis的单机部署为例。如果有分布式Redis集群部署，可以参考Redlock算法的实现。 让我们进入Redis+Lua实现分布式锁的实践。 让我们看看示例代码，以php为例。 锁定锁定锁定。你注意到代码的每个细节了吗？至关重要。 上面的集合是封装好的，我们就简单解释一下这个方法，对应上面锁需要满足的条件。 比如NX操作保证锁的互斥，设置过期时间避免死锁，唯一请求ID用来标记客户端，解锁时可以用来检查是否是同一个客户端自己的锁。 解锁这个动作很有意思，看似简单实则暗藏玄机，也是很重要的一个环节。 因为有一个判断，解锁是锁定客户端的操作，那么就进行解锁。 但是我们在这个if判断中要考虑高并发情况下操作的原子性，这其实和PHP等其他语言代码中考虑高并发的原则有很大的不同(有兴趣的读者也可以思考一下为什么有判断的时候要保证原子性，可能出现的问题场景有哪些) 如果我们保证操作的原子性呢？第一反应是想到生意？这里我们用Lua脚本保证原子性，Redis的eval命令执行Lua脚本保证原子性。 这里注意，redis在执行整个lua脚本时是独占的，同一时间只有一个线程可以执行这个脚本。这一点很关键，可以用在多线程需要独占原子性保证的所有高并发场景，比如股票判断和扣球，避免负库存和超卖。 Redis本身是单线程的(不同于每个PHP文件的单线程执行，PHP服务器(apache/nigix/php-fpm)是多线程的；Redis是排队解决每一个进来的请求，后面的解决方案是多线程和复用io。 所以PHP有并发问题，redis是线程安全的)，它有原子性，lua本身也有原子性。 解锁下面我们也来解释一下解锁代码。 其实很简单，就是执行一个Lua脚本。这个脚本实现了获取当前锁值，即唯一的请求ID值，并判断是否可以获取同一客户端的请求ID。如果是，则执行Redis的del操作。 好了，Redis实现分布式锁定到此为止。这里只是一个简单的例子来理解。实际生产中会需要考虑更多的场景和因素，比如集群、Zookeeper实现、时间和能力有限，这里就不赘述了。 参考:浅谈Redis分布式锁实现nginx嵌入lua的两个例子(nginx-lua模块 根据不同的请求参数返回指定的5xx错误快照，避免在nginx中直接写逻辑难以维护；直接将PHP请求分发到异步，类似ajax但少于其请求，启动lua协同异步请求异步输出各部分的页面内容。 Python本身没有协同学。 Lua作为游戏中C调用的逻辑求解脚本的例子(协进程，与C/C++很好的集成，热升级 从语言的通用层面来说，C/C++的低通用层面更适合底层逻辑的支持，而Lua脚本由于其高通用层面更适合游戏逻辑的实现。 脚本运行在虚拟机上，虚拟机运行在游戏逻辑上。作为解释性语言，我们可以随时修改，及时在游戏中展现，快速完成开发。当然，游戏的核心是C++ C/C++做不到。对于一个庞大的游戏项目来说，每次修改都需要重新编译，成本很高。 试想一下，如果所有的功能都用C/C++实现，对开发者来说将是一场灾难。 相关门户:乐观锁和悲观锁的实现