Django 模型中的并发控制 [英] Concurrency control in Django model

问题描述

如何在 Django 模型中处理并发?我不希望读取同一记录的另一个用户覆盖对记录的更改.

How do I handle concurrency in a Django model? I don't want the changes to the record being overwritten by another user who reads the same record.

推荐答案

简而言之，这确实不是 Django 提出的问题.

The short answer, this really isn't a Django question as presented.

并发控制通常作为一个技术问题出现，但在很多方面都是一个功能需求问题.您希望/需要您的应用程序如何工作?在我们知道这一点之前，很难给出任何针对 Django 的建议.

Concurrency control is often presented as a technical question, but is in many ways a question of functional requirements. How do you want/need your application to work? Until we know that, it will be difficult to give any Django-specific advice.

但是，我想漫无边际，所以这里是...

But, I feel like rambling, so here goes...

在面对并发控制的需求时，我倾向于问自己两个问题:

There are two questions that I tend to ask myself when confronted with the need for concurrency control:

• 两个用户需要同时修改同一条记录的可能性有多大?
• 如果用户对记录的修改丢失，对他/她有什么影响?

如果冲突的可能性相对较高，或者丢失修改的影响很严重，那么您可能正在考虑某种形式的悲观锁定.在悲观方案中，每个用户必须在打开记录进行修改之前获得一个逻辑锁.

If the likelihood of collisions is relatively high, or the impact of losing a modification is severe, then you may be looking at some form of pessimistic locking. In a pessimistic scheme, each user must acquire a logical lock prior to opening the record for modification.

悲观锁定带来了很多复杂性.必须同步对锁的访问，考虑容错，锁过期，锁可以被超级用户覆盖，用户可以看到谁拥有锁，等等.

Pessimistic locking comes with much complexity. You must synchronize access to the locks, consider fault tolerance, lock expiration, can locks be overridden by super users, can users see who has the lock, so on and so on.

在 Django 中，这可以通过单独的 Lock 模型或锁定记录上的某种锁定用户"外键来实现.使用锁表可以让你在获取锁的时间、用户、笔记等方面有更大的灵活性.如果你需要一个可用于锁定任何类型记录的通用锁表，请查看django.contrib.contenttypes 框架，但很快这可以转化为抽象宇航员综合症.

In Django, this could be implemented with a separate Lock model or some kind of 'lock user' foreign key on the locked record. Using a lock table gives you a bit more flexibility in terms of storing when the lock was acquired, user, notes, etc. If you need a generic lock table that can be used to lock any kind of record, then take a look at the django.contrib.contenttypes framework, but quickly this can devolve into abstraction astronaut syndrome.

如果不太可能发生冲突或丢失的修改很容易重新创建，那么您可以在功能上使用乐观并发技术.这种技术很简单，也更容易实现.本质上，您只需跟踪版本号或修改时间戳，并拒绝您检测到的任何不正常的修改.

If collisions are unlikely or lost modifications are trivially recreated, then you can functionally get away with optimistic concurrency techniques. This technique is simple and easier to implement. Essentially, you just keep track of a version number or modification time stamp and reject any modifications that you detect as out of whack.

从功能设计的角度来看，您只需考虑这些并发修改错误如何呈现给您的用户.

From a functional design standpoint, you only have to consider how these concurrent modification errors are presented to your users.

就Django而言，可以通过覆盖模型类上的save方法来实现乐观并发控制...

In terms of Django, optimistic concurrency control can be implemented by overriding the save method on your model class...

def save(self, *args, **kwargs):
    if self.version != self.read_current_version():
        raise ConcurrentModificationError('Ooops!!!!')
    super(MyModel, self).save(*args, **kwargs)

当然，要使这些并发机制中的任何一个变得健壮，您必须考虑 交易控制.如果您不能保证交易的 ACID 属性，那么这些模型都不是完全可行的.

And, of course, for either of these concurrency mechanisms to be robust, you have to consider transactional control. Neither of these models are fully workable if you can't guarantee ACID properties of your transactions.

这篇关于Django 模型中的并发控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！