博客项目第四天

celery

发送验证码时出现发送请求容联云无法响应，整个sms_view会卡住，整个页面无法返回。服务器许多请求都在等待容联云返回，一直占用资源，导致服务器崩溃。

解决方法：redis生产者消费者模型，celery是一个简单，领过且可靠的，处理大量消息的分布式系统，它是专注于实时处理的任务队列，同时也支持任务调度，降低主营业务阻塞的问题。
缺陷：无法保证实时反馈。适用于异步场景。
名词解释：
（1）broker-消息传输的中间件，生产者一旦有消息发送，将发至broker，【RQ，redis】
（2）backen - 用于存储消息、任务结果，如果需要跟踪和查询任务状态，则需添加要配置相关
（3）worker - 工作者-消费/执行broker中消息/任务的进程

使用-创建worker
from celery import Celery
app = Celeery(‘guoxiaonao’,broker='redis://:password@127.0.0.1:6379/1)
#链接redis数据库,password没有时填为空

#创建任务函数
@app.task
def task_test():
print(‘task is runnning’)

使用后-启动worker
#Ubuntu终端中，tasks.py文件同级目录下执行celery -A tasks worker --loglevel=info
此模式默认为前台启动，终端会输出相关日志

使用-创建生产者-推送任务
在tasks.py文件的同级目录进入ipython3执行如下代码
from tasks import task_test
task_test.delay()
执行完毕后，观察worker日志，delay可传入参数

首先在服务器启动worker，worker就会处于等待中，监听redis的队列，当有任务时就会触发worker执行。在生产者中引用调用worker定义好的函数，然后delay，此任务就会放入队列，轮到的时候worker中的对应函数就会在work中被调用

celery-2

使用-存储执行结果=worker
celery提供存储任务执行结果的方案，需借助redis或mysql或Memcached等,存储后的结果供生产者调用
from celery import Celery
app = Celery(‘demo’,broker=‘redis://@127.0.0.1:6349/1’,
backend = 'redis://@127.0.0.1:6349/2)

#创建任务函数
@app.task
def task_test(a,b):
print(‘task is running’)
return a+b

django中使用celery

1、创建celery配置文件
项目同名目录下创建celery.py
2、应用下创建task.py集中定义对应的worker函数
3、视图函数充当生产者，推送具体worker函数
4、项目目录下启动worker
celery -A 项目同名目录名 worker -l info

正式环境后台启动celery，在项目目录下，即可看到manage.py文件的目录启动celery，celery和django在一起用的时候setting中的debug一定要用false，不然会造成内存泄漏问题。
启动命令：
nohub celery -A proj worker -P gevent -c 1000 > celery.log 2>&1 &
#1、nuhup:忽略所有挂断（SIGHUP）信号
#2、标准输入是文件描述符0。他是命令的输入，缺省式键盘，也可以是文件或者其他命令的输出
#3、&代表命令在后台执行
-p gevent表示并发以协程的方式进行 -c 1000指定为1000个协程

启动后可在日志中查找到已加载的worker函数
celery结果查询：
https://blog.csdn.net/u011519550/article/details/108685342

文章系统

一、模型类

#1、后端给前端全部内容，前端自己截取 浪费网络，数据库带宽
#2、后端从数据库中获取全部文章内容，截取好后。相应给前端 与数据库之间网络带宽浪费
#3、数据库冗余一个字段【简介】，后端只截取字段内容，使用此种方式
文章内容textfield，外键关联使用ForeighKey进行多对多关联。

二、发布文章
论坛文本输入类：富文本编辑器
前端初始化后即可使用，下载代码后，加载。根据文档要求初始化。
var content = editor.txt.html()；返回带有样式的文本
var content_text = editor.txt.text(); 返回不带有样式的文本，此部分是为了标签的截取，使用第一种方式会导致截取到一半的标签。

由于文章存在增删改查多操作，所以使用视图类，url处为TopicView.asview(),views中为class TopicView(View)

使用F12的网络查看浏览器发送的信息，在后端编写对应的编码。

创建数据时，author直接取request中的myuser，是在验证登录时获得的用户对象

三、列表页-1
根据restful语义，获取列表页为get视图，使用查询字符串传入想要访问的作者名。

在获取文章的时候，要区分此用户是否是作者。访问者由于可能是未登录的，只能使用Authorization的token进行辨别是否登录且用户名是谁。浏览器本地存储的dnblog_user无法通过get参数上传，get上传的时候查询字符串的参数还有请求头中所带的的参数。从数据库获取到的对象使用点方法把数据拿出来，编写成json字符串格式

四、列表页-2
展示文章列表
取文章的时候，从数据库取出的时间是一个datatime对象，使用strftime（‘%Y-%m-%d %H:%M:%S’）格式化。

五、详情页-1
前端页面detail，后端在topicview中的Topicview类中的get

六、详情页-2
使用ORM实现上一页下一页内容。上一页的逻辑为t_id比目前小的最后一个，下一页为t_id比目前大的第一个

七：文章系统-缓存-1

（1）缓存方案1-cache_page(过期时间s)
优点：简单
缺点：1、无法按照具体的访客身份，进行针对性的存储，例如：存储的是博主访问自身博客的数据，当非博主访客到访时，可能会触发博主存储的缓存。2、删除缓存成本太高【博主更新博客后，重新访问，无法看到新的数据，新旧数据不一致问题】

（2）缓存方案2-局部-cache.set/get
优点：灵活，存储成本最优,删除成本低
缺点：代码实现成本高
案例：模型类中定义classmethod
class Topic
@classmethod
def get_topic_list(cls,):
if cache:
return
data = cls.objects.filter()
#cache in 存储cache
return data

本项目使用重写方案1的装饰器
当装饰器需要传参时需要在外面再加一层def，使用cache.get和cache.set对缓存进行操作。
1、区分场景-只对列表页进行缓存
2、根据关键字传参和request的uername得到是否为博主访问
3、对于两种角色生成不同的cachekey
4、查询是否存在并存储
@method_decorator(cache_set(30))

删除缓存：cache.delete_many（）批量清除缓存
例子：
http://www.chenxm.cc/article/730.html?a=1
request.get_host() #
不带查询字符串
request.path # article/730.html
带查询字符串
request.get_full_path() article/730.html?a=1