中文字幕免费精品_亚洲视频自拍_亚洲综合国产激情另类一区_色综合咪咪久久

Django中實現(xiàn)一個高性能計數(shù)器(Counter)實例
來源:易賢網(wǎng) 閱讀:1293 次 日期:2014-07-11 19:28:16
溫馨提示:易賢網(wǎng)小編為您整理了“Django中實現(xiàn)一個高性能計數(shù)器(Counter)實例”,方便廣大網(wǎng)友查閱!

計數(shù)器(Counter)是一個非常常用的功能組件,這篇blog以未讀消息數(shù)為例,介紹了在 Django中實現(xiàn)一個高性能計數(shù)器的基本要點。

故事的開始:.count()

假設(shè)你有一個Notification Model類,保存的主要是所有的站內(nèi)通知:

代碼如下:

class Notification(models.Model):

    """一個簡化過的Notification類,擁有三個字段:

    - `user_id`: 消息所有人的用戶ID

    - `has_readed`: 表示消息是否已讀

    """

    user_id = models.IntegerField(db_index=True)

    has_readed = models.BooleanField(default=False)

理所當(dāng)然的,剛開始你會通過這樣的查詢來獲取某個用戶的未讀消息數(shù):

代碼如下:

# 獲取ID為3074的用戶的未讀消息數(shù)

Notification.objects.filter(user_id=3074, has_readed=False).count()

當(dāng)你的Notification表比較小的時候,這樣的方式?jīng)]有任何的問題,但是慢慢的,隨著業(yè)務(wù)量 的擴大。消息表里面有了 上億條數(shù)據(jù) 。很多懶惰的用戶的未讀消息數(shù)都到了上千條。

這時候,你就需要實現(xiàn)一個計數(shù)器,讓這個計數(shù)器來統(tǒng)計每個用戶的未讀消息數(shù),這樣 比起之前的 count() ,我們只需要執(zhí)行一條簡單的主鍵查詢(或者更優(yōu))就可以拿到實時的未讀消息數(shù)了。

更優(yōu)的方案:建立計數(shù)器

首先,讓我們得建立一個新表來存儲每個用戶的未讀消息數(shù)。

代碼如下:

class UserNotificationsCount(models.Model):

    """這個Model保存著每一個用戶的未讀消息數(shù)目"""

    user_id = models.IntegerField(primary_key=True)

    unread_count = models.IntegerField(default=0)

    def __str__(self):

        return '<UserNotificationsCount %s: %s>' % (self.user_id, self.unread_count)

我們?yōu)槊恳粋€注冊用戶提供了一條對應(yīng)的 UserNotificationsCount 記錄來保存他的未讀消息數(shù)。 每次獲取他的未讀消息數(shù)的時候,只需要 UserNotificationsCount.objects.get(pk=user_id).unread_count 就可以了。

接下來,問題的重點來了,我們?nèi)绾沃朗裁磿r候應(yīng)該更新我們的計數(shù)器?Django在這方面提供了什么捷徑嗎?

挑戰(zhàn):實時更新你的計數(shù)器

為了讓我們的計數(shù)器正常的工作,我們必須實時的更新它,這包括:

1.當(dāng)有新的未讀消息過來的時候,為計數(shù)器 +1

2.當(dāng)消息被異常刪除時,如果關(guān)聯(lián)的消息為未讀,為計數(shù)器 -1

3.當(dāng)閱讀完一個新消息的時候,為計數(shù)器 -1

讓我們一個一個來解決這些情況。

在拋出解決方案之前,我們需要先介紹Django中的一個功能: Signals ,Signals是django提供的一個事件通知機制,它可以讓你在監(jiān)聽某些自定義或者 預(yù)設(shè)的事件,當(dāng)這些事件發(fā)生的時候,調(diào)用實現(xiàn)定義好的方法。

比如 django.db.models.signals.pre_save & django.db.models.signals.post_save 表示的是 某個Model調(diào)用save方法之前和之后會觸發(fā)的事件,它和Database提供的觸發(fā)器在功能上有一點相似。

關(guān)于Signals更多的介紹可以參考官方文檔,下面讓我們來看看Signals能給我們的計數(shù)器帶來什么好處。

1. 當(dāng)有新的消息過來的時候,為計數(shù)器 +1

這個情況應(yīng)該是最好處理的,使用Django的Signals,只需要短短幾行代碼,我們便可以實現(xiàn)這種 情況下的計數(shù)器更新:

代碼如下:

from django.db.models.signals import post_save, post_delete

def incr_notifications_counter(sender, instance, created, **kwargs):

    # 只有當(dāng)這個instance是新創(chuàng)建,而且has_readed是默認(rèn)的false才更新

    if not (created and not instance.has_readed):

        return

    # 調(diào)用 update_unread_count 方法來更新計數(shù)器 +1

    NotificationController(instance.user_id).update_unread_count(1)

# 監(jiān)聽Notification Model的post_save信號

post_save.connect(incr_notifications_counter, sender=Notification)

這樣,每當(dāng)你使用 Notification.create 或者 .save() 之類的方法創(chuàng)建新通知 時,我們的 NotificationController 便會得到通知,為計數(shù)器 +1。

但是請注意,因為我們的計數(shù)器是基于Django的signals,如果你的代碼里面有地方 在使用原始sql,沒有通過Django ORM方法來添加新通知的話,我們的計數(shù)器是不會得到 通知的,所以,最好規(guī)范所有的新通知建立方式,比如使用同一個API。

2. 當(dāng)消息被異常刪除時,如果關(guān)聯(lián)的消息為未讀,為計數(shù)器 -1

有了第一個的經(jīng)驗,這種情況處理起來也比較簡單,只需要監(jiān)控Notification的post_delete 信號就可以了,下面是一段實例代碼:

代碼如下:

def decr_notifications_counter(sender, instance, **kwargs):

    # 當(dāng)刪除的消息還沒有被讀過時,計數(shù)器 -1

    if not instance.has_readed:

        NotificationController(instance.user_id).update_unread_count(-1)

post_delete.connect(decr_notifications_counter, sender=Notification)

至此,Notification的刪除事件也能正常的更新我們的計數(shù)器了。

3. 當(dāng)閱讀一個新消息的時候,為計數(shù)器 -1

接下來,當(dāng)用戶閱讀某條未讀消息的時候,我們也需要更新我們的未讀消息計數(shù)器。 你可能會說,這有什么難的?我只要在我的閱讀消息的方法里面,手動更新我的計數(shù)器不就好了?

比如這樣:

代碼如下:

class NotificationController(object):

    ... ...

    def mark_as_readed(self, notification_id):

        notification = Notification.objects.get(pk=notification_id)

        # 沒有必要重復(fù)標(biāo)記一個已經(jīng)讀過的通知

        if notication.has_readed:

            return

        notification.has_readed = True

        notification.save()

        # 在這里更新我們的計數(shù)器,嗯,我感覺好極了

        self.update_unread_count(-1)

通過一些簡單的測試,你可以會覺得你的計數(shù)器工作的非常好,但是,這樣的實現(xiàn)方式有一個 非常致命的問題, 這個方式?jīng)]有辦法正常處理并發(fā)的請求 。

打一個比方,你擁有一個id為100的未讀消息對象,這個時候同時有了兩個請求過來,都要標(biāo)記這個通知為已讀:

代碼如下:

# 因為兩個并發(fā)的請求,假設(shè)這兩個方法幾乎同時被調(diào)用

NotificationController(user_id).mark_as_readed(100)

NotificationController(user_id).mark_as_readed(100)

顯而易見的,這兩次方法都會成功的標(biāo)記這條通知為已讀,因為在并發(fā)的情況下, if notification.has_readed 這樣的檢查無法正常工作,所以我們的計數(shù)器將會被錯誤的 -1 兩次 ,但其實我們只讀了一條請求。

那么,這樣的問題應(yīng)該怎么解決呢?

基本上,解決并發(fā)請求產(chǎn)生的數(shù)據(jù)沖突只有一個辦法: 加鎖 ,介紹兩種比較簡單的解決方案:

使用 select for update 數(shù)據(jù)庫查詢

select ... for update 是數(shù)據(jù)庫層面上專門用來解決并發(fā)取數(shù)據(jù)后再修改的場景的,主流的關(guān)系數(shù)據(jù)庫 比如mysql、postgresql都支持這個功能, 新版的Django ORM甚至直接提供了這個功能的shortcut 。 關(guān)于它的更多介紹,你可以搜索你使用的數(shù)據(jù)庫的介紹文檔。

使用 select for update 后,我們的代碼可能會變成這樣:

代碼如下:

from django.db import transaction

class NotificationController(object):

    ... ...

    def mark_as_readed(self, notification_id):

        # 手動讓select for update和update語句發(fā)生在一個完整的事務(wù)里面

        with transaction.commit_on_success():

            # 使用select_for_update來保證并發(fā)請求同時只有一個請求在處理,其他的請求

            # 等待鎖釋放

            notification = Notification.objects.select_for_update().get(pk=notification_id)

            # 沒有必要重復(fù)標(biāo)記一個已經(jīng)讀過的通知

            if notication.has_readed:

                return

            notification.has_readed = True

            notification.save()

            # 在這里更新我們的計數(shù)器,嗯,我感覺好極了

            self.update_unread_count(-1)

除了使用``select for update``這樣的功能,還有一個比較簡單的辦法來解決這個問題。

使用update來實現(xiàn)原子性修改

其實,更簡單的辦法,只要把我們的數(shù)據(jù)庫改成單條的update就可以解決并發(fā)情況下的問題了:

代碼如下:

def mark_as_readed(self, notification_id):

        affected_rows = Notification.objects.filter(pk=notification_id, has_readed=False)\

                                            .update(has_readed=True)

        # affected_rows將會返回update語句修改的條目數(shù)

        self.update_unread_count(affected_rows)

這樣,并發(fā)的標(biāo)記已讀操作也可以正確的影響到我們的計數(shù)器了。

高性能?

我們在之前介紹了如何實現(xiàn)一個能夠正確更新的未讀消息計數(shù)器,我們可能會直接使用UPDATE 語句來修改我們的計數(shù)器,就像這樣:

代碼如下:

from django.db.models import F

def update_unread_count(self, count)

    # 使用Update語句來更新我們的計數(shù)器

    UserNotificationsCount.objects.filter(pk=self.user_id)\

                                  .update(unread_count=F('unread_count') + count)

但是在生產(chǎn)環(huán)境中,這樣的處理方式很有可能造成嚴(yán)重的性能問題,因為如果我們的計數(shù)器在頻繁 更新的話,海量的Update會給數(shù)據(jù)庫造成不小的壓力。所以為了實現(xiàn)一個高性能的計數(shù)器,我們 需要把改動暫存起來,然后批量寫入到數(shù)據(jù)庫。

使用 redis 的 sorted set ,我們可以非常輕松的做到這一點。

使用sorted set來緩存計數(shù)器改動

redis是一個非常好用的內(nèi)存數(shù)據(jù)庫,其中的sorted set是它提供的一種數(shù)據(jù)類型:有序集合, 使用它,我們可以非常簡單的緩存所有的計數(shù)器改動,然后批量回寫到數(shù)據(jù)庫。

代碼如下:

RK_NOTIFICATIONS_COUNTER = 'ss_pending_counter_changes'

def update_unread_count(self, count):

    """修改過的update_unread_count方法"""

    redisdb.zincrby(RK_NOTIFICATIONS_COUNTER, str(self.user_id), count)

# 同時我們也需要修改獲取用戶未讀消息數(shù)方法,使其獲取redis中那些沒有被回寫

# 到數(shù)據(jù)庫的緩沖區(qū)數(shù)據(jù)。在這里代碼就省略了

通過以上的代碼,我們把計數(shù)器的更新緩沖在了redis里面,我們還需要一個腳本來把這個緩沖區(qū) 里面的數(shù)據(jù)定時回寫到數(shù)據(jù)庫中。

通過自定義django的command,我們可以非常輕松的做到這一點:

代碼如下:

# File: management/commands/notification_update_counter.py

# -*- coding: utf-8 -*-

from django.core.management.base import BaseCommand

from django.db.models import F

# Fix import prob

from notification.models import UserNotificationsCount

from notification.utils import RK_NOTIFICATIONS_COUNTER

from base_redis import redisdb

import logging

logger = logging.getLogger('stdout')

class Command(BaseCommand):

    help = 'Update UserNotificationsCounter objects, Write changes from redis to database'

    def handle(self, *args, **options):

        # 首先,通過 zrange 命令來獲取緩沖區(qū)所有修改過的用戶ID

        for user_id in redisdb.zrange(RK_NOTIFICATIONS_COUNTER, 0, -1):

            # 這里值得注意,為了保證操作的原子性,我們使用了redisdb的pipeline

            pipe = redisdb.pipeline()

            pipe.zscore(RK_NOTIFICATIONS_COUNTER, user_id)

            pipe.zrem(RK_NOTIFICATIONS_COUNTER, user_id)

            count, _ = pipe.execute()

            count = int(count)

            if not count:

                continue

            logger.info('Updating unread count user %s: count %s' % (user_id, count))

            UserNotificationsCount.objects.filter(pk=obj.pk)\

                                          .update(unread_count=F('unread_count') + count)

之后,通過 python manage.py notification_update_counter 這樣的命令就可以把緩沖區(qū) 里面的改動批量回寫到數(shù)據(jù)庫了。我們還可以把這個命令配置到crontab中來定義執(zhí)行。

總結(jié)

文章到了這里,一個簡單的“高性能”未讀消息計數(shù)器算是實現(xiàn)完了。說了這么多,其實主要的知識點就是這么些:

1.使用Django的signals來獲取Model的新建/刪除操作更新

2.使用數(shù)據(jù)庫的select for update來正確處理并發(fā)的數(shù)據(jù)庫操作

3.使用redis的sorted set來緩存計數(shù)器的修改操作

希望能對您有所幫助。 :)

更多信息請查看IT技術(shù)專欄

更多信息請查看腳本欄目
由于各方面情況的不斷調(diào)整與變化,易賢網(wǎng)提供的所有考試信息和咨詢回復(fù)僅供參考,敬請考生以權(quán)威部門公布的正式信息和咨詢?yōu)闇?zhǔn)!

2026上岸·考公考編培訓(xùn)報班

  • 報班類型
  • 姓名
  • 手機號
  • 驗證碼
關(guān)于我們 | 聯(lián)系我們 | 人才招聘 | 網(wǎng)站聲明 | 網(wǎng)站幫助 | 非正式的簡要咨詢 | 簡要咨詢須知 | 新媒體/短視頻平臺 | 手機站點 | 投訴建議
工業(yè)和信息化部備案號:滇ICP備2023014141號-1 云南省教育廳備案號:云教ICP備0901021 滇公網(wǎng)安備53010202001879號 人力資源服務(wù)許可證:(云)人服證字(2023)第0102001523號
云南網(wǎng)警備案專用圖標(biāo)
聯(lián)系電話:0871-65099533/13759567129 獲取招聘考試信息及咨詢關(guān)注公眾號:hfpxwx
咨詢QQ:1093837350(9:00—18:00)版權(quán)所有:易賢網(wǎng)
云南網(wǎng)警報警專用圖標(biāo)
中文字幕免费精品_亚洲视频自拍_亚洲综合国产激情另类一区_色综合咪咪久久
欧美日本国产在线| 国产伦理一区| 欧美国产视频在线观看| 欧美激情综合五月色丁香小说| 欧美三级在线视频| 亚洲高清久久| 欧美精品精品一区| 99国内精品| 欧美 日韩 国产在线| 国产精品久久久久久久9999| 亚洲欧美精品一区| 激情综合色综合久久| 欧美日韩精品久久| 久久国产精品毛片| 亚洲国产成人高清精品| 久久久久久91香蕉国产| 欧美午夜视频一区二区| 免费久久99精品国产自| 中文精品视频一区二区在线观看| 国产精品久久一区二区三区| 久久久精品网| 亚洲欧洲日产国产网站| 美国十次成人| 欧美大片在线观看| 久久久久91| 亚洲免费伊人电影在线观看av| 国产精品久久久久久一区二区三区 | 亚洲专区一区| 亚洲国产一区二区三区高清| 国产精品白丝av嫩草影院| 这里只有视频精品| 国产日韩一区二区| 国产精品日韩欧美一区二区三区 | 这里只有视频精品| 亚洲国语精品自产拍在线观看| 国产精品影片在线观看| 欧美激情中文字幕乱码免费| 久久国产精品免费一区| 国产精品99久久99久久久二8| 韩国av一区二区三区在线观看| 亚洲成人资源| 激情欧美亚洲| 国产亚洲激情| 国产精品国产a级| 国产精品女同互慰在线看| 欧美国产日韩二区| 免费成人黄色片| 麻豆成人91精品二区三区| 欧美二区不卡| 午夜亚洲视频| 精品999久久久| 国产一区二区三区久久悠悠色av| 毛片一区二区三区| 国产精品jizz在线观看美国| 国产亚洲免费的视频看| 日韩网站在线观看| 免费欧美日韩国产三级电影| 国产一区二区三区高清播放| 国产欧美日韩激情| 欧美精品在线播放| 久久国内精品视频| 亚洲美女免费精品视频在线观看| 欧美精品系列| 日韩亚洲精品视频| 欧美日韩激情小视频| 欧美综合第一页| 亚洲激情综合| 欧美三级视频在线观看| 99v久久综合狠狠综合久久| 欧美黄色日本| 欧美视频一区二区三区在线观看| 久久精品国产欧美亚洲人人爽| 国内成人在线| 国产精品xxxxx| 美女图片一区二区| 国产精品综合视频| 欧美三日本三级三级在线播放| 午夜激情综合网| 国内精品一区二区| 欧美 日韩 国产 一区| 午夜免费电影一区在线观看| 亚洲一区二区在线| 一区二区三区高清不卡| 国产综合视频在线观看| 国产精品国产精品国产专区不蜜| 国产精品日本精品| 国产欧美一区二区色老头| 欧美日韩免费观看一区=区三区| 久久久亚洲国产美女国产盗摄| 一区二区精品| 久久久久久久一区二区三区| 欧美在线在线| 久久精品成人一区二区三区| 欧美影院成年免费版| aa成人免费视频| 亚洲欧美中文在线视频| 午夜精品一区二区三区在线视| 一区二区三区精品视频在线观看| 亚洲老板91色精品久久| 久热精品视频| 欧美激情一区二区三区蜜桃视频| 欧美粗暴jizz性欧美20| 欧美黄色日本| 久久最新视频| 国产一区二区三区自拍| 在线看视频不卡| 99国产精品一区| 亚洲综合色婷婷| 韩国女主播一区| 亚洲综合久久久久| 欧美电影美腿模特1979在线看| 欧美激情成人在线视频| 欧美极品一区| 亚洲日本一区二区三区| 久久伊人一区二区| 欧美破处大片在线视频| 国产一区二区日韩精品| 伊人成人在线视频| 裸体素人女欧美日韩| 国内精品一区二区| 欧美在线视频在线播放完整版免费观看| 精品福利免费观看| 亚洲特色特黄| 欧美午夜一区二区福利视频| 亚洲国产精品女人久久久| 免费国产自线拍一欧美视频| 国产亚洲第一区| 久久婷婷激情| 亚洲伦理自拍| 国产精品日本一区二区| 久久riav二区三区| 亚洲精品一二三| 国产精品视频网址| 欧美国产精品人人做人人爱| 中文精品99久久国产香蕉| 国产精品久久久久天堂| 久久国产婷婷国产香蕉| 日韩一区二区精品在线观看| 国产精品免费看| 国产综合久久久久久| 国产一区二区三区高清在线观看| 国产精品jizz在线观看美国| 国产精品日韩一区二区三区| 在线观看欧美亚洲| 在线亚洲国产精品网站| 久久亚洲精品网站| 老色鬼久久亚洲一区二区| 欧美sm极限捆绑bd| 国产农村妇女精品一区二区| 久久爱www| 一区二区视频免费完整版观看| 久久激情网站| 性欧美超级视频| 中文久久乱码一区二区| 国产视频观看一区| 欧美肥婆在线| 欧美.www| 麻豆av福利av久久av| 亚洲综合色在线| 亚洲欧美日本国产专区一区| 亚洲天堂免费在线观看视频| 国产一区999| 国模叶桐国产精品一区| 亚洲第一福利视频| 亚洲国产另类久久久精品极度| 猫咪成人在线观看| 欧美日韩高清区| 久久国产一区| 欧美超级免费视 在线| 久久午夜羞羞影院免费观看| 久久久97精品| 久久国产一区| 欧美在线视频网站| 一本色道综合亚洲| 在线免费观看视频一区| 国产精品私拍pans大尺度在线 | 国内精品国语自产拍在线观看| 国产精品视频yy9299一区| 欧美日韩精品综合| 国外成人在线视频网站| 国产在线精品一区二区夜色| 亚洲美女av黄| 久久se精品一区精品二区| 午夜日韩在线| 欧美精品日韩精品| 国产精品盗摄一区二区三区| 欧美日韩中文字幕在线视频| 国产亚洲一区二区精品| 亚洲国产精品日韩| 99国内精品久久| 性久久久久久| 国产精品久久久久久av福利软件 | 久久精品人人做人人综合 | 亚洲国产欧美在线| 在线国产精品播放| 正在播放日韩| 欧美性大战久久久久久久蜜臀| 亚洲第一视频网站| 欧美一区国产一区| 国产欧美69|