Celery 를 이용 하여 Django 블 로그 PV 통계 기능 에 대한 상세 한 설명 을 실현 합 니 다.

머리말
며칠 전 사이트 의 글 에 pv 통 계 를 추 가 했 는데 그 전에는 uv 통계 만 있 었 다.pv 통 계 를 추가 하지 않 은 것 은 모든 사용자 가 글 을 방문 할 때마다 저 는 데이터 베 이 스 를 한 번 작성 해 야 한 다 는 것 이 성능 에 해 를 끼 친다 고 생각 합 니 다.왜냐하면 사용자 가 the5fire 블 로그 에 방문 한 것 을 보면 데이터 베이스 에서 해당 하 는 글(보통 캐 시 에서 가 져 옵 니 다)을 받 은 다음 에 브 라 우 저 에 게 돌아 가 야 합 니 다.쓰기 동작 은 무의미 하 다.이전의 uv 도 모든 사용 자 를 대상 으로 24 시간 동안 한 번 만 쓰기 동작 을 할 수 있 었 다.
그 나 저 나 the5fire 블 로그 라 는 작은 사이트 에 있어 서 저 를 방문 할 때마다 10 여 번 의 데이터 베 이 스 를 쓰 는 데 영향 을 주지 않 습 니 다.왜냐하면 양 이 적 고 불쌍 하기 때 문 입 니 다.근 데 우리 야드 농 사 는 억 대 유량 에 저항 하 는 마음 이 있어 야 되 잖 아.
이해 하지 못 하 는 학우 에 대해 서 는 밖 에 나 가 조사 연 구 를 해서 남 의 집 사 이 트 를 볼 수 있다.네,바로 수 억,10 억,100 억 에 달 하 는 사이트 입 니 다.그들 이 사용자 가 쓴 글 을 어떻게 처리 하 는 지 보 세 요.예 를 들 어 댓 글 등 입 니 다.
PV 의 의미
이 유 를 말 하고 업 무 를 말 하 다.모든 사이트 에는 pv,uv 와 같은 통계 가 있다.심지어 체류 시간 이 길 고 유형 별 페이지 전환 율 등 각 분야 의 통계 도 있다.나 는 소 후 에서 일 하 는데,말하자면 웹 사 이 트 를 만 드 는 것 이다.주목 하 는 업무 지 표 는 바로 데이터 와 관련 된 것 이다.또한 역장 으로서 몇 년 동안 바 이 두 통계 의 일부 지 표를 참고 하여 조정 할 것 이다.
하지만 이번 에는 pv,한 문장의 pv 만 말 합 니 다.
비정상적인 방문 을 떠 나 인터넷 의 한 글 이 그 를 많이 방문 할 수록 이 글 의 가치 가 높다 는 것 을 의미한다.값 진 물건 이 니까 시 켜 보 시 죠.이 방 문 량 은 uv(User View/Visit)입 니 다.그러면 pv 는 무엇 입 니까?한 편의 글 을 잘 썼 습 니 다.특히 기술 문장 은 여러 번 방문 할 수 있 습 니 다.예 를 들 어 저 는 좋 은 글 을 소장 하고 시간 이 있 을 때 돌 이 켜 보 는 것 을 좋아 합 니 다.매번 회고(페이지 새로 고침)는 pv 라 고 할 수 있 습 니 다.사람 독자 가 여러 번 읽 을 수 있 는 글 은 가치 가 더욱 높다.그래서 한 문장의 pv/uv 비도 문장의 가 치 를 평가 하 는 지표 이다.특히 표제 당 이 널리 퍼 진 시대.좋 습 니 다.여기 서 한 마디 만 더 비 뚤 어 지면 제목 당 은 미디어 시대 의 산물 이 아니 라 블 로그 시대 에 있 습 니 다.다만 미디어 시대 에 더욱 집중 적 으로 나타 날 뿐 입 니 다)
단순히 가 치 는 느낌 이 없다 고 했 잖 아.옛사람 들 이 말 했 잖 아.가 치 는 쌀 몇 말 을 바 꿀 수 있다 고.(허 튼 소리 하 다
현재 의 모든 뉴스 사이트/미디어 플랫폼 으로 볼 때 pv 는 전체 65509℃와 같은 번 호 를 그 릴 수 있 습 니 다.데이터 가 많 을 수록 더 많은 수입 을 얻 을 수 있다 는 것 을 의미한다.광고 수입 이 든 데이터 가 다른 경로 로 방출 되 든.가끔 은 저도 모든 목표 가 사용 자 를 더 잘 이해 하고 사용자 에 게 그 가 보고 싶 은 것 을 보 내 는 것 이 라 고 생각 합 니 다.글 쎄 요.하지만 돌아 갈 수 없 는 문 제 는 상업 모델 을 구축 하여 광고 주 와 투자 자 들 이 사용자 의 체류 시간 에 계산 하도록 하 는 것 입 니 다.사용 자 를 더 많은 플랫폼 에 머 무 르 게 하고 더 많은 시간 을 소비 하 게 합 니 다.(순 전 히 개인 적 인 관점 이다.
또 다른 직접적인 예 를 들 어 현재 언론 에서 유행 하고 있 으 며,얼마나 많은 사람들 이 100000+,좋 은 대중 번 호 를 원 하 는 지,기 존의 글 의 조회 수(또는 팬 덤)에 따라 광고/소프트 문 등 각종 유형의 합작 가격 을 정할 수 있다.사실 너 는 마이크로 방송 이나 이 찬 에 가서 보면 알 수 있다.
그 러 고 보 니 pv 가 매력 적 으로 변 했 나 봐 요.
통계 적 방식
사이트 에 대해 말하자면,the5fire 가 알 게 된 pv,uv 의 통계 방식 은 이렇게 몇 가지 가 있다

the5fire 초기 방법:사용자 가 한 편의 글 을 방문 할 때마다 pv+1,uv+1.어 리 석고 거 친 방법.4567918)

the5fire 블 로그 의 현재 방법 은 분포 식 작업 서 비 스 를 작성 한 다음 에 업무 코드 에서 호출 합 니 다.

페이지 에 점,라벨 을 묻 거나 js 를 인용 하여 통계 서버 에 데 이 터 를 보 냅 니 다.

nginx access-log(nginx 를 사용한다 면)를 수집 합 니 다.물론 형식 은 사용자 정의 가 필요 합 니 다.user 를 추가 해 야 합 니 다.id,그리고 오프라인 통계,집계.

앞의 두 가 지 는 모두 결합 이 비교적 무 거 운 실현 방식 으로 구체 적 인 페이지 에 코드 를 삽입 해 야 한다.뒤의 두 가지 도 비슷 합 니 다.본질 적 으로 nginx 로 그 를 수집 하지만 수집 단계 가 다 릅 니 다.세 번 째 는 페이지 가 완전히 열 려 야 nginx 가 로 그 를 받 을 수 있 습 니 다.네 번 째 는 페이지 에 접근 하고 upstream 이 상태 코드 를 200 으로 되 돌려 주면 성공 하 더 라 도 최종 사용자 가 페이지 를 보지 못 할 까 봐 걱정 입 니 다.
한 마디 로 하면 각각 장단 점 이 있 으 니 서로 참고 할 수 있다.
블 로그 구현 방식
위 에서 도 말 했 듯 이 주로 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()

Rabbitmq 가 아 닌 공식 적 으로 권장 하지 않 는 redis 를 broker 로 사 용 했 습 니 다.주로 캐 시 는 Redis 를 사용 합 니 다.더 많은 유지보수 시스템 을 도입 하지 않 기 위해 서 입 니 다.
시작 파일 을 정의 한 후 에는 구체 적 인 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 의 논 리 를 계산 하여 분포 식 작업 관리자 에 넣 고 실행 하 며 이번 방문 에 영향 을 주지 않 습 니 다.
만약 당신 이 작업 의 실행 상 태 를 보고 싶다 면,예 를 들 어 통과:

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

작업 이 완료 되 었 는 지 확인 하려 면 django-celery-results 를 도입 해 야 합 니 다.사용 절 차 는 다음 과 같 습 니 다.

pip install django-celery-results

djangocelery_결 과 는 INSTALLEDAPPS 중

설정CELERY_RESULT_BACKEND = 'django-db'또는'Django-cache'

django-db 를 설정 하면 결 과 를 데이터베이스 에 저장 해 야 한 다 는 뜻 이 라면python manage.py migrate django_celery_results표를 작성 해 야 합 니 다.

이 설정 이 완 료 된 후에 남 은 것 은 배치 입 니 다.the5fire 블 로 그 는 코드 를 업데이트 하고 재배 치 할 때마다 fabric 을 통 해 만 든 fab re 입 니 다.deploy:master 코드 가 서버 에 배 치 됩 니 다.celery 를 추가 한 후 슈퍼 visord 설정 만 추가 하면 됩 니 다.지금 은 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()

이것 은 가장 간단 한 방법 이지 만 대부분의 경우 사용자 가 글 을 방문 하면 이 글 은 보통 캐 시 에 있 습 니 다.매번 데이터 베 이 스 를 찾 을 필요 가 없 기 때 문 입 니 다.그렇다면 어떻게 처리 해 야 할 까?직관 적 인 방법 은 먼저 post 를 얻 은 다음 에+1,save,위 와 같다.하지만 경쟁 에 문제 가 있 을 수 있다.
예 를 들 어 100 명 이 한 편의 글 을 방문 하면 저 는 여러 개의 스 레 드/프로 세 스 를 시작 하여 요청 을 처리 합 니 다.모든 프로 세 스 가 같은 시간 에 post=Post.objects.get(pk=post 를 실 행 했 을 수도 있 습 니 다.id)현재 데이터베이스 에 있 는 이 글 의 pv 가 100 이 라 고 가정 하면 이때 post.pv 는 100 입 니 다.모든 사용자 가 post.save()를 실행 한 후 결 과 는 101,즉 100 번 의 동시 방문 으로 pv 가 1 만 추가 되 는 상황 이 발생 할 수 있 습 니 다.
이 문 제 를 해결 하려 면 두 가지 방법 이 있다.
1.자 물 쇠 를 추가 합 니 다.이것 은 제 가 알 기 로 는 Django 가 제공 하지 않 았 고 스스로 실현 해 야 합 니 다.근 데 아무 도 그 러 지 않 겠 지?2.my sql 로 자체 증 가 를 수행 합 니 다.즉,제 가 위 에서 사용 하 는 것 입 니 다.
방법 2 에 대해 서 는 Django 에서 어떻게 이 루어 질 까?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
총결산
이상 은 이 글 의 전체 내용 입 니 다.본 논문 의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 도움 이 되 기 를 바 랍 니 다.궁금 한 점 이 있 으 시 면 댓 글 을 남 겨 주 셔 서 저희 에 대한 지지 에 감 사 드 립 니 다.