为了账号安全,请及时绑定邮箱和手机立即绑定

[技术分享]Django项目缓存优化

2019.08.16 11:01 2381浏览

​大家可以想一下Django的请求响应流程:
→ 用户浏览器输入URL地址
→ Web服务器将HTTP请求转发给uWSGI服务器
→ uWSGI服务器将Request请求转发给Django应用
→ Django中间件处理Request请求
→ 视图View处理
→ 模型类Models获取数据
→ 模板Template渲染
→ 再次经过Django中间件返回
→ uWSGI服务器将Response返回给Web服务器
→ Web服务器响应客户端的HTTP请求。

​这其中耗时最多的2个环节通常是视图中业务逻辑处理和从Models获取数据(SQL查询),对于相同目的请求,也就是业务处理逻辑和SQL查询的数据都一样的请求,每次都进行了重复的计算,并且数据是从硬盘读取而非内存。

​所以使用缓存有如下好处:

  • 降低服务器负载
  • 避免重复计算
  • 提高系统性能

​ 很简单,一个Request请求过来,先去缓存中查询,有就返回;没有就去数据库查询并处理,然后把结果缓存好(供下次请求使用),再返回。用伪代码解释的话就是这样

1565188410729

三、缓存的类型

1. Memcached 效率最高,最快的缓存
2. Database caching 数据库缓存,这个指把数据缓存到数据表,比如你项目中使用的MySQL,就在MySQL中建表来专门缓存数据。不是指用Redis数据库
3. Filesystem caching 文件系统缓存,将缓存会把键值存储到独立的文件中去
4. Local-memory caching 使用系统内存缓存
5. Dummy caching (for development) 假缓存,只在开发过程中使用,以调试缓存接口,数据并没有真正缓存
6. Using a custom cache backend 自定义缓存后端,比如使用Redis

那么问题来了,我该使用哪种缓存呢?

其实常用的也就2种:Memcached或者Reids,其它基本不用考虑了。Redis国内用得多,支持RDB和AOF两种持久化方式,支持高可用集群,技术和方案很成熟,比如我的Django高级实战课程 https://coding.imooc.com/class/333.html,使用就是Redis缓存,将业务数据,Django channels,Celery任务分别缓存到4个不同的Redis库,甚至可以做成Redis集群的方式。而Memcached是纯内存存储,本身不支持持久化,不支持分布式,但是它内存管理效率高。

  1. Per-site cache 把整个网站都缓存了,只需要在项目中设置加入缓存中间键的配置,系统便会自动对整个网站进行缓存
  2. Per-view cache 缓存某个视图
  3. Template fragment caching 模板的片段,比如Django模板继承base.html,通常是不变的导航栏
  4. Low-level cache API 低级别缓存API,比如缓存某个函数的结果,或者某个API接口

那么问题又来了,项目中我该选择什么样的缓存粒度?

是否需要缓存很简单,看内容是否变化。如果整个视图的数据通常都不变,就使用视图缓存,某些模板片段的数据不变就使用模板片段缓存等等。所以一个项目里面多种缓存粒度都有的,在Django高级实战课程 <https://coding.imooc.com/class/333.html里面使用到了per-view cache, Template fragment caching, low-level cache API三种,给大家帖一页PPT

1565191011613

这里只说一下Redis和Memcached的,其它很少用的就不罗列了,需要注意的是系统上要安装对应的缓存服务,Django开发环境中要安装连接缓存服务的包(比如django-redis或pymemcache)

  1. Memcache缓存设置

最简单的,配置地址和端口,不一定是要在本机,也可以是其它网段的服务器或集群

1565191940886

在本机的话,也可以使用unix Socket

1565191999123

也可以使用多态服务器,不同端口缓存

1565192049422

  1. Redis缓存设置

截图一下实战课程中Redis缓存的配置,缓存网站的数据

1565193028231

Django channels频道层的缓存

1565193103650

Celery缓存,broker和任务的执行结果

1565193166931

​对于Django项目缓存的数据,我们取出来或存进去操作,可以不需要直接操作底层的缓存数据,比如使用原生的Redis或Memcached命令,只需要使用Django提供的缓存API即可。就像我们使用Django ORM一样,无需关注底层数据库是MySQL, PostgreSQL或SQLite,ORM语句都一样。

​例如,访问缓存 1565229356143

​使用缓存

1565229404381

​除了set(), get()还有get_or_set(), get_many(), set_many(), delete(), delete_many(), clear(), touch(), incr(), decr(), close()操作。大家可以去看看官网文档一个个操作下,要注意的是有的API不是每一个Django版本都有,比如cache.touch()是Django 2.1版本才有的。

​缓存使用了,那效果怎么样,有什么指标可以衡量?用什么工具来衡量?

  1. Django Debug Toolbar

django-debug-toolbar是一个开源的工具,可以在看板上展示django对request/response处理的详细信息,比如当前请求响应的CPU耗时,settings/headers/request信息,当前请求使用的模板文件,静态文件,具体SQL语句和执行时间等等,看板要显示什么信息是可以灵活配置的。

在Django高级实战课程 <https://coding.imooc.com/class/333.html中,第12章 - 网站优化部分讲解了django-debug-toolar的时候,用来评估缓存优化,ORM语句和SQL优化的效果,如图:

右边的栏目就是django-debug-tool的看板

1565232827516

此页面共有9次SQL查询,耗时8.62毫秒

1565232877855

缓存命中3次,cache.get(),用时约0.91毫秒

1565232775407

  1. Jmeter压力测试

django-debug-tool是开发人员用,从功能角度测试缓存效果。而Jmeter就是专门测试人员用的,用于性能测试和压力测试。项目使用缓存后,整体性能是不是提高了,高负载情况下系统稳定性怎么样。测试方面的知识就不具体展开了,看慕课上有关于Jemeter的免费课,有兴趣的同学可以去看一下。

OK,今天的分享就到这里,关于Django项目缓存的,欢迎同学们提问,回头我把大家的问题和回答整理成文档发到群里。Bye~


  1. 缓存问题,有数据更新的时候是先写数据库还是先写缓存?脏读问题、或者先删缓存多线程又访问了,发现没有缓存又重新添加了缓存

【答】优先考虑先更新数据库,再删除缓存。关于缓存更新设计,当有数据更新的时候,你是打算更新缓存的数据,还是淘汰(删除)缓存的数据,所有就有了3种策略(没有先更新缓存,再更新数据库这种策略)。由于DB和Cache属于2个不同的系统,不能保证事务性的操作,一定涉及“哪个任务先做,哪个任务后做”的问题,解决这个问题的方向是:如果出现不一致,谁先做对业务的影响较小,就谁先执行。

  • 先删除缓存,再更新数据库
    低并发场景下,先删除缓存,更新数据库后,后续读操作会从数据库读取数据并更新缓存,仅会造成一次缓存未命中;
    低并发场景下,先删除缓存,更新数据库后,后续读操作会从数据库读取数据并更新缓存,仅会造成一次缓存未命中;
  • 先更新数据库,再更新缓存
    假设两个写线程T1、T2并发更新某一数据,T1先获取锁、更新数据库并且释放锁,T2获取锁、更新数据库然后释放锁;接下来T2更新缓存值,T1更新缓存值,这时候缓存中的数据T1为脏数据。
  • 先更新数据库,再删除缓存
    缓存数据失效的瞬间,读线程T1未命中缓存,然后到数据库取数据,取完数据后来了个写线程T2,T2先往数据库写数据,然后删除缓存,接着T1再把读到的老数据加载到缓存,此时也会造成脏读。这个情况出现的概率非常低,需要缓存失效的瞬间有并发的读写操作。而且数据库的写会比读慢很多,并且需要对数据加锁,所以T1必须在T2之前进入数据库进行操作,又要晚于T2更新缓存,所有这些条件都具备的概率非常低。

··················
欢迎关注课程:
《Django高级实战 开发企业级问答网站》

点击查看更多内容

本文首次发布于慕课网 ,转载请注明出处,谢谢合作

22人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 邀请有奖 帮助中心 APP下载
官方微信

举报

0/150
提交
取消