前言

前幾天給網(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)容對大家的學習或者工作能帶來一定的幫助，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

最新評論