第 12 篇:加缓存为接口提速

2020/07/17 08:57
阅读数 15

作者:HelloGitHub——追梦人物

目前,用户对于接口的操作基本都需要查询数据库。获取文章列表需要从数据库查询,获取单篇文章需要从数据库查询,获取评论列表也需要查询数据。但是,对于博客中的很多资源来说,在某个时间段内,他们的内容几乎都不会发生更新。例如文章详情,文章发表后,除非对其内容做了修改,否则内容就不会变化。还有评论列表,如果没人发布新评论,评论列表也不会变化。

要知道查询数据库的操作相对而言是比较缓慢的,而直接从内存中直接读取数据就会快很多,因此缓存系统应运而生。将那些变化不那么频繁的数据缓存到内存中,内存中的数据相当于数据库中的一个副本,用户查询数据时,不从数据库查询而是直接从缓存中读取,数据库的数据发生了变化时再更新缓存,这样,数据查询的性能就大大提升了。

当然数据库性能也没有说的那么不堪,对于大部分访问量不大的个人博客而言,任何关系型数据库都足以应付。但是我们学习 django-rest-framework 不仅仅是为了写博客,也许你在工作中,面对的是流量非常大的系统,这时候缓存就不可或缺。

确定需缓存的接口

先来整理一下我们已有的接口,看看哪些接口是需要缓存的:

接口名 URL 需缓存
文章列表 /api/posts/
文章详情 /api/posts/:id/
分类列表 /categories/
标签列表 /tags/
归档日期列表 /posts/archive/dates/
评论列表 /api/posts/:id/comments/
文章搜索结果 /api/search/

补充说明

  1. 文章列表:需要缓存,但如果有文章修改、新增或者删除时应使缓存失效。
  2. 文章详情:需要缓存,但如果文章内容修改或者删除了应使缓存失效。
  3. 分类、标签、归档日期:可以缓存,但同样要注意在相应的数据变化时使缓存失效。
  4. 评论列表:可以缓存,新增或者删除评论时应使缓存失效。
  5. 搜索接口:因为搜索的关键词是多种多样的,可以缓存常见搜索关键词的搜索结果,但如何确定常见搜索关键词是一个复杂的优化问题,这里我们不做任何缓存处理。

配置缓存

django 为我们提供了一套开箱即用的缓存框架,缓存框架对缓存的操作做了抽象,提供了统一的读写缓存的接口。无论底层使用什么样的缓存服务(例如常用的 Redis、Memcached、文件系统等),对上层应用来说,操作逻辑和调用的接口都是一样的。

配置 django 缓存,最重要的就是选择一个缓存服务,即缓存结果存储和读取的地方。本项目中我们决定开发环境使用本地内存(Local Memory)缓存服务,线上环境使用 Redis 缓存。

开发环境配置

在开发环境的配置文件 settings/local.py 中加入以下的配置项即开启本地内存缓存服务。

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
    }
}

线上环境配置

线上环境使用到 Redis 缓存服务,django 并未内置 Redis 缓存服务的支持,不过对于 Redis 来说当然不缺乏第三方库的支持,我们选择 django-redis-cache,先来安装它:

$ pipenv install django-redis-cache

然后在项目的线上环境配置文件 settings/production.py 中加入以下配置:

CACHES = {
    "default": {
        "BACKEND": "redis_cache.RedisCache",
        "LOCATION": "redis://:UJaoRZlNrH40BDaWU6fi@redis:6379/0",
        "OPTIONS": {
            "CONNECTION_POOL_CLASS": "redis.BlockingConnectionPool",
            "CONNECTION_POOL_CLASS_KWARGS": {"max_connections": 50, "timeout": 20},
            "MAX_CONNECTIONS": 1000,
            "PICKLE_VERSION": -1,
        },
    },
}

这样,django 的缓存功能就启用了。至于如何启动 Redis 服务,请参考教程最后的 Redis 服务部分。

drf-extensions Cache

django 的缓存框架比较底层,drf-extensions 在 django 缓存框架的基础上,针对 django-rest-framework 封装了更多缓存相关的辅助函数和类,我们将借助这个第三方库来大大简化缓存逻辑的实现。

首先安装它:

$ pipenv install drf-extensions

那么 drf-extensions 对缓存提供了哪些辅助函数和类呢?我们需要用到的主要有这些:

KeyConstructor

可以理解为缓存键生成类。我们先来看看 API 接口缓存的逻辑,伪代码是这样的:

给定一个 URL, 尝试从缓存中查找这个 URL 接口的响应结果
if 结果在缓存中:
    return 缓存中的结果
else:
    生成响应结果
    将响应结果存入缓存 (以便下一次查询)
    return 生成的响应结果

缓存结果是以 key-value 的键值对形式存储的,这里关键的地方在于存储或者查询缓存结果时,需要生成相应的 key。例如我们可以把 API 请求的 URL 作为缓存的 key,这样同一个接口请求将返回相同的缓存内容。但是在更为复杂的场景下,不能简单使用 URL 作为 key,比如即使是同一个 API 请求,已认证和未认证的用户调用接口得到的结果是不一样的,所以 drf-extensions 使用 KeyConstructor 辅助基类来提供灵活的 key 生成方式。

KeyBit

可以理解为 KeyConstructor 定义的 key 生成规则中的某一项规则定义。例如,同一个 API 请求,已认证和未认证的用户将得到不同的响应结果,我们可以定义 key 的生成规则为请求的 URL + 用户的认证 id。那么 URL 可以看成一个 KeyBit,用户 id 是另一个 KeyBit。

cache_response 装饰器

这个装饰器用来装饰 django-rest-framework 的视图(单个视图函数、视图集中的 action 等),被装饰的视图将具备缓存功能。

缓存博客文章

我们首先来使用 cache_response 装饰器缓存文章列表接口,代码如下:

blog/views.py

from rest_framework_extensions.cache.decorators import cache_response

class PostViewSet(
    mixins.ListModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet
):
    # ...
    @cache_response(timeout=5 * 60, key_func=PostListKeyConstructor())
    def list(self, request, *args, **kwargs):
        return super().list(request, *args, **kwargs)

    @cache_response(timeout=5 * 60, key_func=PostObjectKeyConstructor())
    def retrieve(self, request, *args, **kwargs):
        return super().retrieve(request, *args, **kwargs)

这里我们分别装饰了 list(获取文章列表的 action)和 retrieve(获取单篇文章),timeout 参数用于指定缓存失效时间, key_func 指定缓存 key 的生成类(即 KeyConstructor),当然 PostListKeyConstructor、和 PostObjectKeyConstructor 还未定义,接下来我们就来定义这两个缓存 key 生成类:

blog/views.py

from rest_framework_extensions.key_constructor.bits import (
    ListSqlQueryKeyBit,
    PaginationKeyBit,
    RetrieveSqlQueryKeyBit,
)
from rest_framework_extensions.key_constructor.constructors import DefaultKeyConstructor

class PostListKeyConstructor(DefaultKeyConstructor):
    list_sql = ListSqlQueryKeyBit()
    pagination = PaginationKeyBit()
    updated_at = PostUpdatedAtKeyBit()


class PostObjectKeyConstructor(DefaultKeyConstructor):
    retrieve_sql = RetrieveSqlQueryKeyBit()
    updated_at = PostUpdatedAtKeyBit()

PostListKeyConstructor 用于文章列表接口缓存 key 的生成,它继承自 DefaultKeyConstructor,这个基类中定义了 3 条缓存 key 的 KeyBit:

  1. 接口调用的视图方法的 id,例如 blog.views. PostViewSet.list。
  2. 客户端请求的接口返回的数据格式,例如 json、xml。
  3. 客户端请求的语言类型。

另外我们还添加了 3 条自定义的缓存 key 的 KeyBit:

  1. 执行数据库查询的 sql 查询语句
  2. 分页请求的查询参数
  3. Post 资源的最新更新时间

以上 6 条分别对应一个 KeyBit,KeyBit 将提供生成缓存键所需要的值,如果任何一个 KeyBit 提供的值发生了变化,生成的缓存 key 就会不同,查询到的缓存结果也就不一样,这个方式为我们提供了一种有效的缓存失效机制。例如 PostUpdatedAtKeyBit 是我们自定义的一个 KeyBit,它提供 Post 资源最近一次的更新时间,如果资源发生了更新,返回的值就会发生变化,生成的缓存 key 就会不同,从而不会让接口读到旧的缓存值。PostUpdatedAtKeyBit的代码如下:

blog/views.py

from .utils import UpdatedAtKeyBit

class PostUpdatedAtKeyBit(UpdatedAtKeyBit):
    key = "post_updated_at"

因为资源更新时间的 KeyBit 是比较通用的(后面我们还会用于评论资源),所以我们定义了一个基类 UpdatedAtKeyBit,代码如下:

blog/utils.py

from datetime import datetime
from django.core.cache import cache
from rest_framework_extensions.key_constructor.bits import KeyBitBase

class UpdatedAtKeyBit(KeyBitBase):
    key = "updated_at"

    def get_data(self, **kwargs):
        value = cache.get(self.key, None)
        if not value:
            value = datetime.utcnow()
            cache.set(self.key, value=value)
        return str(value)

get_data 方法返回这个 KeyBit 对应的值,UpdatedAtKeyBit 首先根据设置的 key 从缓存中读取资源最近更新的时间,如果读不到就将资源最近更新的时间设为当前时间,然后返回这个时间。

当然,我们需要自动维护缓存中记录的资源更新时间,这可以通过 django 的 signal 来完成:

blog/models.py

from django.db.models.signals import post_delete, post_save

def change_post_updated_at(sender=None, instance=None, *args, **kwargs):
    cache.set("post_updated_at", datetime.utcnow())

post_save.connect(receiver=change_post_updated_at, sender=Post)
post_delete.connect(receiver=change_post_updated_at, sender=Post)

每当有文章(Post)被新增、修改或者删除时,django 会发出 post_save 或者 post_delete 信号,post_save.connect 和 post_delete.connect 设置了这两个信号的接收器为 change_post_updated_at,信号发出后该方法将被调用,往缓存中写入文章资源的更新时间。

整理一下请求被缓存的逻辑:

  1. 请求文章列表接口
  2. 根据 PostListKeyConstructor 生成缓存 key,如果使用这个 key 读取到了缓存结果,就直接返回读取到的结果,否则从数据库查询结果,并把查询的结果写入缓存。
  3. 再次请求文章列表接口,PostListKeyConstructor 将生成同样的缓存 key,这时就可以直接从缓存中读到结果并返回了。

缓存更新的逻辑:

  1. 新增、修改或者删除文章,触发 post_delete, post_save 信号,文章资源的更新时间将被修改。
  2. 再次请求文章列表接口,PostListKeyConstructor 将生成不同的缓存 key,这个新的 key 不在缓存中,因此将从数据库查询最新结果,并把查询的结果写入缓存。
  3. 再次请求文章列表接口,PostListKeyConstructor 将生成同样的缓存 key,这时就可以直接从缓存中读到结果并返回了。

PostObjectKeyConstructor 用于文章详情接口缓存 key 的生成,逻辑和 PostListKeyConstructor 是完全一样。

缓存评论列表

有了文章列表的缓存,评论列表的缓存只需要依葫芦画瓢。

KeyBit 定义:

blog/views.py

class CommentUpdatedAtKeyBit(UpdatedAtKeyBit):
    key = "comment_updated_at"

KeyConstructor 定义:

blog/views.py

class CommentListKeyConstructor(DefaultKeyConstructor):
    list_sql = ListSqlQueryKeyBit()
    pagination = PaginationKeyBit()
    updated_at = CommentUpdatedAtKeyBit()

视图集:

@cache_response(timeout=5 * 60, key_func=CommentListKeyConstructor())
@action(
        methods=["GET"],
        detail=True,
        url_path="comments",
        url_name="comment",
        pagination_class=LimitOffsetPagination,
        serializer_class=CommentSerializer,
    )
    def list_comments(self, request, *args, **kwargs):
        # ...

缓存其它接口

其它接口的缓存大家可以根据上述介绍的方法来完成,就留作练习了。

Redis 服务

本地内存缓存服务配置简单,适合在开发环境使用,但无法适应多线程和多进程适的环境,线上环境我们使用 Redis 做缓存。有了 Docker,启动一个 Redis 服务就是一件非常简单的事。

在线上环境的容器编排文件 production.yml 中加入一个 Redis 服务:

version: '3'

volumes:
  static:
  database:
  esdata:
  redis_data:

services:
  hellodjango.rest.framework.tutorial:
    ...
    depends_on:
      - elasticsearch
      - redis
  
  redis:
    image: 'bitnami/redis:5.0'
    container_name: hellodjango_rest_framework_tutorial_redis
    ports:
      - '6379:6379'
    volumes:
      - 'redis_data:/bitnami/redis/data'
    env_file:
      - .envs/.production

然后在 .envs/.production 文件中添加如下的环境变量,这个值将作为 redis 连接的密码:

REDIS_PASSWORD=055EDy65AAhLgBxMp1u1

然后就可以将服务发布上线了。


关注公众号加入我们

本文分享 CNBlog - 削微寒的程序员之路。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部