# 没有必要重复标记一个已经读过的通知
if notication.has_readed:
return
notification.has_readed = True
notification.save()
# 在这里更新我们的计数器，嗯，我感觉好极了
self.update_unread_count(-1)
通过一些简单的测试，你可以会觉得你的计数器工作的非常好，但是，这样的实现方式有一个 非常致命的问题， 这个方式没有办法正常处理并发的请求 。
打一个比方，你拥有一个id为100的未读消息对象，这个时候同时有了两个请求过来，都要标记这个通知为已读：
# 因为两个并发的请求，假设这两个方法几乎同时被调用
NotificationController(user_id).mark_as_readed(100)
NotificationController(user_id).mark_as_readed(100)
显而易见的，这两次方法都会成功的标记这条通知为已读，因为在并发的情况下， if notification.has_readed 这样的检查无法正常工作，所以我们的计数器将会被错误的 -1 两次 ，但其实我们只读了一条请求。
那么，这样的问题应该怎么解决呢？
基本上，解决并发请求产生的数据冲突只有一个办法： 加锁 ，介绍两种比较简单的解决方案：
使用 select for update 数据库查询
select ... for update 是数据库层面上专门用来解决并发取数据后再修改的场景的，主流的关系数据库 比如mysql、postgresql都支持这个功能， 新版的Django ORM甚至直接提供了这个功能的shortcut 。 关于它的更多介绍，你可以搜索你使用的数据库的介绍文档。
使用 select for update 后，我们的代码可能会变成这样：
from django.db import transaction
class NotificationController(object):
... ...
def mark_as_readed(self, notification_id):
# 手动让select for update和update语句发生在一个完整的事务里面
with transaction.commit_on_success():
# 使用select_for_update来保证并发请求同时只有一个请求在处理，其他的请求
# 等待锁释放
notification = Notification.objects.select_for_update().get(pk=notification_id)
# 没有必要重复标记一个已经读过的通知
