前言

前幾天給網(wǎng)站的文章增加了pv統(tǒng)計(jì)，之前只有uv統(tǒng)計(jì)。之前沒加pv統(tǒng)計(jì)是覺得每個(gè)用戶每訪問一次文章，我都需要數(shù)據(jù)庫(kù)寫操作實(shí)在是有損性能，畢竟從用戶在the5fire博客的的一次訪問來(lái)看，只需要從數(shù)據(jù)庫(kù)里拿到對(duì)應(yīng)的文章（通常情況下是從緩存中拿），然后返回給瀏覽器。寫操作無(wú)意義。之前的uv，也是針對(duì)每個(gè)用戶24小時(shí)內(nèi)只會(huì)有一次寫操作。

不過(guò)話說(shuō)回來(lái)，就對(duì)于the5fire博客這么個(gè)小站點(diǎn)來(lái)說(shuō)，就算每次訪問我寫十幾次數(shù)據(jù)庫(kù)都沒啥影響，畢竟量小的可憐。但是咱們碼農(nóng)不是得有顆抗億級(jí)流量的心嘛。

對(duì)于不理解的同學(xué)，可以出門調(diào)研下，看看別人家的網(wǎng)站。對(duì)，就是那些訪問量上億，十億，百億的網(wǎng)站，看看他們是怎么處理用戶寫入的，比如留言。

PV的意義

說(shuō)完原因，再說(shuō)業(yè)務(wù)。所有的網(wǎng)站都會(huì)有pv，uv這樣的統(tǒng)計(jì)。甚至是停留時(shí)長(zhǎng)，各類型頁(yè)面轉(zhuǎn)換率等等各方各面的統(tǒng)計(jì)。我在搜狐的工作，大白話來(lái)說(shuō)就是做網(wǎng)站。關(guān)注的業(yè)務(wù)指標(biāo)就是流量相關(guān)的東西。同時(shí)作為站長(zhǎng)這么多年，也會(huì)參考百度統(tǒng)計(jì)里的一些指標(biāo)來(lái)做些調(diào)整。

不過(guò)這次只說(shuō)pv，一篇文章的pv。

單純的說(shuō)價(jià)值沒啥感覺，古人不是說(shuō)了嗎，價(jià)值能換幾斗米。（我胡謅的）

拿現(xiàn)在的所有新聞網(wǎng)站/媒體平臺(tái)來(lái)說(shuō)，pv是可以和￥劃等號(hào)的。流量越大，意味著能夠有更多的收入，無(wú)論是來(lái)自廣告的收入，還是把流量釋放到其他渠道。有時(shí)候我也考慮，一切的目標(biāo)真的是更好的理解用戶，給用戶推送他想看的東西嗎？或許是吧，但是始終繞不開的一個(gè)問題是，構(gòu)建一個(gè)商業(yè)模式，讓廣告主和投資人為用戶的停留時(shí)長(zhǎng)買單。讓用戶更多的停留在平臺(tái)上，消費(fèi)更多的時(shí)間。（純屬個(gè)人觀點(diǎn)，明辨之，慎思之）

再拿另外一個(gè)更直接的例子，現(xiàn)在自媒體盛行，多少人想要100000+，一個(gè)好的公眾號(hào)，可以根據(jù)以往文章的瀏覽量（或者粉絲量）來(lái)定價(jià)廣告/軟文等各種類型合作的價(jià)格。其實(shí)你到微播易或者易贊看看就知道了。
這么看來(lái)pv是不是變得有吸引力了。

統(tǒng)計(jì)的方式

對(duì)于網(wǎng)站來(lái)說(shuō)，the5fire了解到的pv，uv的統(tǒng)計(jì)方式有這么幾種

• 像the5fire早期的做法：用戶每訪問一篇文章，文章pv+1，uv+1。傻大粗的做法。
• the5fire博客現(xiàn)在的做法，寫一個(gè)分布式的任務(wù)服務(wù)，然后在業(yè)務(wù)代碼中調(diào)用。
• 頁(yè)面埋點(diǎn)，標(biāo)簽，或者引用js來(lái)發(fā)送數(shù)據(jù)到統(tǒng)計(jì)服務(wù)器上。
• 收集nginx access-log（如果是用nginx的話），當(dāng)然，格式需要自定義，起碼得加上user_id，然后做離線統(tǒng)計(jì)、匯總。

前兩種都是耦合比較重的實(shí)現(xiàn)方式，需要在具體頁(yè)面里插代碼。后兩種也類似，本質(zhì)上都是收集nginx日志，但是收集的階段不同，第三種是頁(yè)面完全打開之后，nginx才會(huì)收到日志。而第四種是只要訪問頁(yè)面，并且upstream返回狀態(tài)碼為200就算成功，那怕最終用戶并未看到頁(yè)面。

總之，各有利弊，可以相互參考。

博客實(shí)現(xiàn)的方式

上面也說(shuō)了，主要也是為了用下celery這個(gè)分布式任務(wù)隊(duì)列。在Django中使用是比較簡(jiǎn)單的事情。

在Django中使用Celery，需要Celery運(yùn)行時(shí)能夠使用這個(gè)Django項(xiàng)目的各個(gè)模塊，因此首先要指明settings模塊。我用的Django版本為1.11。在wsgi.py同級(jí)目錄下增加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，為了不引入更多需要維護(hù)的系統(tǒng)。

定義好啟動(dòng)文件之后，就需要定義具體的tasks，在app/tasks.py中寫具體的任務(wù)：

# 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)

在訪問文章頁(yè)面的views.py對(duì)應(yīng)位置增加調(diào)用:

from .tasks import increase_pv, increase_uv
# ....省略上下文
increase_pv.delay(self.post.id)
increase_uv.delay(self.post.id)

這樣，每次用戶訪問時(shí)計(jì)算pv和uv的邏輯就放到分布式的任務(wù)管理器中去執(zhí)行了，不會(huì)影響本次訪問。

如果你想要查看任務(wù)的執(zhí)行狀態(tài)，比如通過(guò):

r = increase_pv.delay(self.post.id)
print r.ready()

想要這樣查看任務(wù)是否完成，那就需要引入django-celery-results，使用步驟如下：

• pip install django-celery-results
• 把django_celery_results放到INSTALLED_APPS中
• 配置CELERY_RESULT_BACKEND = 'django-db'或者'django-cache'
• 如果配置的是django-db，意味著結(jié)果需要存儲(chǔ)到數(shù)據(jù)庫(kù)中，那就要執(zhí)行python manage.py migrate django_celery_results來(lái)建表

這些配置完成之后，剩下的就是部署了，the5fire博客每次更新完代碼重新部署時(shí)都是通過(guò)fabric來(lái)做的 fab re_deploy:master 代碼就會(huì)部署到服務(wù)器上。增加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進(jìn)程也會(huì)重新啟動(dòng)。

Django Tips

在Django項(xiàng)目中，性能損耗最多的就是ORM，不熟悉的話很容易被坑。

就拿增加pv來(lái)說(shuō)，用戶每次訪問一篇文章，pv字段+1，用代碼來(lái)說(shuō)就是:

# 絕對(duì)不要寫這么蠢的代碼
post = Post.objects.get(pk=post_id)
post.pv = post.pv + 1
post.save()

這是最簡(jiǎn)單的做法，但是大部分情況，用戶訪問一篇文章，這篇文章通常會(huì)在緩存中，畢竟不需要每次都去數(shù)據(jù)庫(kù)中獲取。這樣的話應(yīng)該怎么處理呢，直觀的做法還是先獲取到post，然后+1，save，如上一樣。但這樣會(huì)存在競(jìng)爭(zhēng)的問題。

比方說(shuō)，同時(shí)100個(gè)人訪問一篇文章，我是啟動(dòng)了多個(gè)線程/進(jìn)程來(lái)處理請(qǐng)求，有可能出現(xiàn)所有進(jìn)程在同一時(shí)刻執(zhí)行了 post = Post.objects.get(pk=post_id) 假設(shè)現(xiàn)在數(shù)據(jù)庫(kù)中這篇文章的pv是100，那么此時(shí)post.pv就是100。那所有用戶執(zhí)行完post.save()之后，結(jié)果均為101，也就是一百次并發(fā)訪問，可能出現(xiàn)pv只加1的情況。

要解決這個(gè)問題，兩個(gè)辦法。

一、加鎖，這個(gè)據(jù)我的了解Django沒有提供，需要自己來(lái)實(shí)現(xiàn)。但是沒人會(huì)這么做吧。 二、用mysql來(lái)執(zhí)行自增，也就是我上面用到的。

對(duì)于方法二，在Django中怎么實(shí)現(xiàn)呢。其實(shí)翻譯為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) ，關(guān)于F表達(dá)式可以參考官方文檔：https://docs.djangoproject.com/en/1.11/ref/models/expressions/#django.db.models.F

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來(lái)一定的幫助，如果有疑問大家可以留言交流，謝謝大家對(duì)腳本之家的支持。

最新評(píng)論