用redis实现悲观锁（后端语言以php为例）

锁机制

通常使用的锁分为乐观锁，悲观锁这两种，简单介绍下这两种锁，作为本文的背景知识，对这类知识已经有足够了解的同学可以跳过这部分。

乐观锁

先来看下百度百科上的解释：大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

其实说白了，就是好比一个健身房里只有一台跑步机，在健身房门口有个排号机，每个进健身房的人都得先领一个号码才能进入，如果跑步机上有人，则在一边做做热身、喝喝水，如果跑步机上没人，则确认跑步机上当前显示的号码（上一个用过跑步机的人的号码）是否比自己手持的小，如果小，则可以使用；否则，就意味着过号，而过号在现实中我们的都知道要么走，要么重排，就是不能插队，在系统中也是一样的，通常是返回错误。

悲观锁

同样，来看下百度百科的解释：具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

然后，也同样通俗的解释下，还是那个健身房。这次在门口不需要排号机了，而是挂着把钥匙（只有一把），想进去的人必须拿到这把钥匙才行，拿到钥匙的人可以进入，不管是热身、喝水还是跑步都可以，直到他出来把钥匙挂回墙上，下一个才能去争取，拿到的才可以再进去。听着好像有点不人性化，所以悲观锁比较适合强一致性的场景，但效率比较低，特别是读的并发低。乐观锁则适用于读多写少，并发冲突少的场景。

背景

先说下，本文的开发背景，方便大家