利用Celery實現(xiàn)Django博客PV統(tǒng)計功能詳解
前言
前幾天給網(wǎng)站的文章增加了pv統(tǒng)計,之前只有uv統(tǒng)計。之前沒加pv統(tǒng)計是覺得每個用戶每訪問一次文章,我都需要數(shù)據(jù)庫寫操作實在是有損性能,畢竟從用戶在the5fire博客的的一次訪問來看,只需要從數(shù)據(jù)庫里拿到對應的文章(通常情況下是從緩存中拿),然后返回給瀏覽器。寫操作無意義。之前的uv,也是針對每個用戶24小時內(nèi)只會有一次寫操作。
不過話說回來,就對于the5fire博客這么個小站點來說,就算每次訪問我寫十幾次數(shù)據(jù)庫都沒啥影響,畢竟量小的可憐。但是咱們碼農(nóng)不是得有顆抗億級流量的心嘛。
對于不理解的同學,可以出門調研下,看看別人家的網(wǎng)站。對,就是那些訪問量上億,十億,百億的網(wǎng)站,看看他們是怎么處理用戶寫入的,比如留言。
PV的意義
說完原因,再說業(yè)務。所有的網(wǎng)站都會有pv,uv這樣的統(tǒng)計。甚至是停留時長,各類型頁面轉換率等等各方各面的統(tǒng)計。我在搜狐的工作,大白話來說就是做網(wǎng)站。關注的業(yè)務指標就是流量相關的東西。同時作為站長這么多年,也會參考百度統(tǒng)計里的一些指標來做些調整。
不過這次只說pv,一篇文章的pv。
單純的說價值沒啥感覺,古人不是說了嗎,價值能換幾斗米。(我胡謅的)
拿現(xiàn)在的所有新聞網(wǎng)站/媒體平臺來說,pv是可以和¥劃等號的。流量越大,意味著能夠有更多的收入,無論是來自廣告的收入,還是把流量釋放到其他渠道。有時候我也考慮,一切的目標真的是更好的理解用戶,給用戶推送他想看的東西嗎?或許是吧,但是始終繞不開的一個問題是,構建一個商業(yè)模式,讓廣告主和投資人為用戶的停留時長買單。讓用戶更多的停留在平臺上,消費更多的時間。(純屬個人觀點,明辨之,慎思之)
再拿另外一個更直接的例子,現(xiàn)在自媒體盛行,多少人想要100000+,一個好的公眾號,可以根據(jù)以往文章的瀏覽量(或者粉絲量)來定價廣告/軟文等各種類型合作的價格。其實你到微播易或者易贊看看就知道了。
這么看來pv是不是變得有吸引力了。
統(tǒng)計的方式
對于網(wǎng)站來說,the5fire了解到的pv,uv的統(tǒng)計方式有這么幾種
- 像the5fire早期的做法:用戶每訪問一篇文章,文章pv+1,uv+1。傻大粗的做法。
- the5fire博客現(xiàn)在的做法,寫一個分布式的任務服務,然后在業(yè)務代碼中調用。
- 頁面埋點,標簽,或者引用js來發(fā)送數(shù)據(jù)到統(tǒng)計服務器上。
- 收集nginx access-log(如果是用nginx的話),當然,格式需要自定義,起碼得加上user_id,然后做離線統(tǒng)計、匯總。
前兩種都是耦合比較重的實現(xiàn)方式,需要在具體頁面里插代碼。后兩種也類似,本質上都是收集nginx日志,但是收集的階段不同,第三種是頁面完全打開之后,nginx才會收到日志。而第四種是只要訪問頁面,并且upstream返回狀態(tài)碼為200就算成功,那怕最終用戶并未看到頁面。
總之,各有利弊,可以相互參考。
博客實現(xiàn)的方式
上面也說了,主要也是為了用下celery這個分布式任務隊列。在Django中使用是比較簡單的事情。
在Django中使用Celery,需要Celery運行時能夠使用這個Django項目的各個模塊,因此首先要指明settings模塊。我用的Django版本為1.11。在wsgi.py同級目錄下增加celery.py,代碼如下:
# coding:utf-8 from __future__ import absolute_import, unicode_literals import os from celery import Celery PROFILE = os.environ.get('DJANGO_SELFBLOG_PROFILE', 'develop') # 我是把settings.py拆成了:develop.py,product.py os.environ.setdefault("DJANGO_SETTINGS_MODULE", "django_selfblog.settings.%s" % PROFILE) app = Celery('selfblog', broker="redis://127.0.0.1:6666/2") app.config_from_object('django.conf:settings', namespace='CELERY') # Load task modules from all registered Django app configs. app.autodiscover_tasks()
這里使用了官方并不建議的redis作為broker,而不是Rabbitmq,主要是緩存用的是Redis,為了不引入更多需要維護的系統(tǒng)。
定義好啟動文件之后,就需要定義具體的tasks,在app/tasks.py中寫具體的任務:
# coding:utf-8 from __future__ import unicode_literals from django.db.models import F from .models import Post from django_selfblog.celery import app @app.task def increase_pv(post_id): return Post.objects.filter(id=post_id).update(pv=F('pv')+1) @app.task def increase_uv(post_id): return Post.objects.filter(id=post_id).update(uv=F('uv')+1)
在訪問文章頁面的views.py對應位置增加調用:
from .tasks import increase_pv, increase_uv # ....省略上下文 increase_pv.delay(self.post.id) increase_uv.delay(self.post.id)
這樣,每次用戶訪問時計算pv和uv的邏輯就放到分布式的任務管理器中去執(zhí)行了,不會影響本次訪問。
如果你想要查看任務的執(zhí)行狀態(tài),比如通過:
r = increase_pv.delay(self.post.id) print r.ready()
想要這樣查看任務是否完成,那就需要引入django-celery-results,使用步驟如下:
pip install django-celery-results
- 把django_celery_results放到INSTALLED_APPS中
- 配置
CELERY_RESULT_BACKEND = 'django-db'
或者'django-cache' - 如果配置的是django-db,意味著結果需要存儲到數(shù)據(jù)庫中,那就要執(zhí)行
python manage.py migrate django_celery_results
來建表
這些配置完成之后,剩下的就是部署了,the5fire博客每次更新完代碼重新部署時都是通過fabric來做的 fab re_deploy:master 代碼就會部署到服務器上。增加celery之后,只需要增加supervisord的配置,現(xiàn)在畢竟celery的代碼也是在博客代碼里。
supervisord增加配置:
[program:celery] command=celery -A selfblog worker -P gevent --loglevel=INFO --concurrency=5 directory=/home/the5fire/selfblog/ process_name=%(program_name)s_%(process_num)d umask=022 startsecs=0 stopwaitsecs=0 redirect_stderr=true stdout_logfile=/tmp/log/celery_%(process_num)02d.log numprocs=1 numprocs_start=1 environment=DJANGO_SELFBLOG_PROFILE=product
這樣每次重新部署,celery進程也會重新啟動。
Django Tips
在Django項目中,性能損耗最多的就是ORM,不熟悉的話很容易被坑。
就拿增加pv來說,用戶每次訪問一篇文章,pv字段+1,用代碼來說就是:
# 絕對不要寫這么蠢的代碼 post = Post.objects.get(pk=post_id) post.pv = post.pv + 1 post.save()
這是最簡單的做法,但是大部分情況,用戶訪問一篇文章,這篇文章通常會在緩存中,畢竟不需要每次都去數(shù)據(jù)庫中獲取。這樣的話應該怎么處理呢,直觀的做法還是先獲取到post,然后+1,save,如上一樣。但這樣會存在競爭的問題。
比方說,同時100個人訪問一篇文章,我是啟動了多個線程/進程來處理請求,有可能出現(xiàn)所有進程在同一時刻執(zhí)行了 post = Post.objects.get(pk=post_id) 假設現(xiàn)在數(shù)據(jù)庫中這篇文章的pv是100,那么此時post.pv就是100。那所有用戶執(zhí)行完post.save()之后,結果均為101,也就是一百次并發(fā)訪問,可能出現(xiàn)pv只加1的情況。
要解決這個問題,兩個辦法。
一、加鎖,這個據(jù)我的了解Django沒有提供,需要自己來實現(xiàn)。但是沒人會這么做吧。 二、用mysql來執(zhí)行自增,也就是我上面用到的。
對于方法二,在Django中怎么實現(xiàn)呢。其實翻譯為sql就是
UPDATE `blog_post` SET `pv` = (`blog_post`.`pv` + 1) WHERE `blog_post`.`id` = <post_id>;
Django代碼就是: Post.objects.filter(id=post_id).update(pv=F('pv')+1)
,關于F表達式可以參考官方文檔:https://docs.djangoproject.com/en/1.11/ref/models/expressions/#django.db.models.F
總結
以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學習或者工作能帶來一定的幫助,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。
相關文章
Python實現(xiàn)判斷一個整數(shù)是否為回文數(shù)算法示例
這篇文章主要介紹了Python實現(xiàn)判斷一個整數(shù)是否為回文數(shù)算法,結合實例形式分析了Python針對字符串的翻轉、判斷等相關操作技巧,需要的朋友可以參考下2019-03-03PyQt5的安裝配置過程,將ui文件轉為py文件后顯示窗口的實例
今天小編就為大家分享一篇PyQt5的安裝配置過程,將ui文件轉為py文件后顯示窗口的實例,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2019-06-06Python判斷一個list中是否包含另一個list全部元素的方法分析
這篇文章主要介紹了Python判斷一個list中是否包含另一個list全部元素的方法,結合實例形式對比分析了Python針對列表list元素包含關系的相關轉換、判斷操作技巧,需要的朋友可以參考下2018-12-12python實現(xiàn)微信發(fā)送郵件關閉電腦功能
這篇文章主要介紹了python實現(xiàn)微信發(fā)送郵件關閉電腦功能,具有一定的參考價值,感興趣的小伙伴們可以參考一下2018-02-02python中requests庫+xpath+lxml簡單使用
這篇文章主要介紹了python中requests庫+xpath+lxml簡單使用,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2021-04-04