如何在Django模型中管理并发性
为单用户服务的桌面系统的日子已经过去了 - 网络应用程序现在正在为数百万用户提供服务，许多用户出现了广泛的新问题 - 并发问题。
在本文中，我将介绍在Django模型中管理并发性的两种方法
问题
为了演示常见的并发问题，我们将使用银行账户模型：
开始我们为帐户实例提供一个简单的存款和撤销方法：
这似乎是足够简单的，甚至可能通过本地主机的单元测试和集成测试。 但是， 当两个用户同时在同一个帐户上执行操作时会发生什么？
1、用户A提取帐户 - 余额为100 $。
2、用户B提取帐户 - 余额为100 $。
3、用户B退出30 $ - 余额更新为100 $ - 30 $ = 70 $。
4、用户A存款50 $ - 余额更新为100 $ + 50 $ = 150 $。
这里发生了什么？
用户B要求提取30 $，用户A存入50 $ - 我们预期余额为120 $，但最终为150 $。
为什么会这样呢？
在步骤4，当用户A更新余额时，他在存储器中存储的金额已经过时（用户B已经退出30 $）。
为了防止这种情况发生，我们需要确保我们正在处理的资源在我们正在计算的过程中不会改变。
悲观的做法
悲观的做法表明，您应该完全锁定资源，直到完成它 。 如果没有人可以在您处理对象时获取对象上的锁定，那么可以确保对象没有被更改。
我们使用数据库锁有几个原因：
1、 数据库非常擅长管理锁并保持一致性。
2、数据库是访问数据的最低级别 - 获取最低级别的锁也会防止其他进程尝试修改数据。 例如，DB中的直接更新，cron作业，清理任务等。
3、Django应用程序可以在多个进程 （例如工作者）上运行。 在应用程序级别维护锁将需要大量（不必要的）工作。
要在Django中锁定一个对象，我们使用select_for_update 。
让我们用悲观的方法来实行安全的存款和取款：
按以下步骤：
1、我们在我们的查询器上使用select_for_update来告诉数据库锁定对象，直到事务完成。
2、在数据库中锁定一行需要一个数据库事务 - 我们使用Django的装饰器transaction.atomic来定义事务。
3、我们使用类方法而不是实例方法 - 我们告诉数据库要上锁，然后它会返回锁的对象给我们。 为了实现这一点，我们需要从数据库中获取对象。 如果我们使用self，那么就是在操作一个已经从数据库中获取出来的对象，这个对象无法保证自己是没有被上锁的。
4、帐户中的所有操作都在数据库事务中执行。
让我们看看如何通过我们的新方法来阻止前面说的情况：
1、用户A要求退出30 $：
- 用户A获取帐户上的锁。
-余额为100美元。
2、用户B要求存入50 $：
- 尝试获取锁定帐户失败（由用户A锁定）。
- 用户B等待锁释放 。
3、用户A撤回30 $：
- 余额是70 $。
- 帐户上的用户A的锁定被释放 。
4、用户B获取帐户上的锁。
-余额是70 $。
- 新余额为70 $ + 50 $ = 120 $。
5、账号上用户B的锁定被释放，余额为120 $。
Bug消失了！
这里你需要了解select_for_update
1、在我们的方案中，用户B等待用户A释放锁，我们可以告诉Django 不要等待锁释放并引发DatabaseError。 为此，我们可以将select_for_update的nowait参数设置为True， …select_for_update(nowait=True) 。
2、选择相关对象也被锁定 -当使用select_for_update与select_related时，相关对象也被锁定。
例如，如果我们选择与用户一起select_related帐户，用户和帐户将被锁定。 如果在存款期间，例如有人正在尝试更新名字，该更新将失败，因为用户对象被锁定。
如果您正在使用PostgreSQL或Oracle，这可能不是一个问题，由于即将到来的Django 2.0 的新功能 。 在此版本中，select_for_update具有“of”选项，用于显式地声明要锁定查询中的哪些表 。
我用过去的银行账户示例来展示我们在Django模型中使用的常见模式，欢迎您在本下文中跟进：
https://medium.com/@hakibenita/bullet-proofing-django-models-c080739be4e
乐观的方法
与悲观的方法不同，乐观的方法不需要锁定对象。 乐观的方法假定冲突不是很常见 ，并且指出只应确保在更新时对对象没有做任何更改。
我们如何用Django来实现这样的事情？
首先，我们添加一列以跟踪对该对象所做的更改：
然后，当我们更新一个对象时，我们确保版本没有改变：
接着：
1、我们直接在实例上操作（没有类方法）。
2、我们依赖于每次更新对象时增加版本的事实。
3、仅当版本没有更改时，我们才会进行更新：
- 如果对象没有被修改，我们获取它，而不是对象被更新 。
- 如果被修改 ，则查询将返回零记录，并且对象不会被更新 。
4、Django返回更新行数。 如果“更新”为零，则表示有人在我们获取对象之后更改了对象。
乐观锁定在我们的场景中如何工作：
1. 用户A获取帐户 - 余额为100 $，版本为0。
2. 用户B提取帐户 - 余额为100 $，版本为0。
3. 用户B要求退出30 $：
- 余额更新为100 $ - 30 $ = 70 $。
- 版本增加到1。
4. 用户A要求存入50 $：
- 计算余额为100 $ + 50 $ = 150 $。
- 该帐户不存在与版本0 - > 没有更新。
您需要了解乐观的方法：
不像悲观的方法，这种方法需要一个额外的空间和很多规则 。 克服纪律问题的一个方法是抽象这个行为。 django-fsm 使用如上所述的版本字段来实现乐观锁定 。 django-optimistic-lock似乎也是这样做的。 我们没有使用任何这些包，但灵感来自这里。
在具有大量并发更新的环境中，这种方法可能是浪费的。
这种方法不会对应用程序之外的对象进行修改。 如果您有直接修改数据的其他任务（例如，不通过模型），则需要确保它们也使用该版本。
使用乐观的方法， 函数可以失败并返回false。 在这种情况下，我们很可能想要重试操作。 使用悲观的方法与nowait = False操作不能失败 - 它将等待释放锁。
我应该使用哪一个？
像任何伟大的问题一样，答案取决于以下：
如果您的对象有很多并发更新，那么悲观的方式更好。
如果您在ORM之外发生更新（例如，直接在数据库中），则悲观的方法更安全。
如果您的方法具有远程API调用或操作系统调用等副作用，请确保它们是安全的。 还有些事情要考虑 - 远程通话可能需要很长时间吗？ 远程电话是否正常（重试安全）？