django之Redis缓存功能

关于Redis经常被问到的问题：缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级等概念

一、缓存雪崩

缓存雪崩我们可以简单的理解为：由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

思路：从redis缓存中获取数据，如果存在返回数据，同时校验设置的缓存标记是否过期，如果过期及时更新信息(celery异步执行)；如果redis缓存中没有数据，数据库中查询信息，同时放置到redis缓存中。

1、配置项目celery。

from celery import Celery
from django.conf import settings
import os

# 为celery设置环境变量
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'Test.settings')

CELERYD_MAX_TASKS_PER_CHILD = 10

# 创建应用
app = Celery("demo")
# 配置应用
app.conf.update(
    # 配置broker, 这里我们用redis作为broker
    broker_url='redis://@127.0.0.1:6379/1',
)
# 设置app自动加载任务
# 从已经安装的app中查找任务
app.autodiscover_tasks(settings.INSTALLED_APPS)

2、项目app下面配置tasks文件。

import ctypes
from celery import Celery
from django.core.cache import cache

from Test.celery import app
from api import models

from api.ser import RegisterSerializer

# 创建任务函数
@app.task
def celery_get_data(cacheKey,cacheSign,cacheTime):
    '''缓存数据'''
    print('celery执行任务中，获取缓存数据')
    cache.set(cacheSign, '1', cacheTime)
    cacheValue = UserSerializer(instance=models.User.objects.all(), many=True).data
    cache.set(cacheKey, cacheValue, cacheTime * 2)
    return {'info': 200}

 3、配置模型。

class User(models.Model):
    name = models.CharField(max_length=128, verbose_name='姓名')
    mobile = models.CharField(max_length=11, verbose_name="手機號")
    pwd = models.CharField(max_length=128, verbose_name='密码')

    class Meta:
        db_table = 'users'
        verbose_name = "用戶信息"

    def __str__(self):
        return self.name

 4、配置序列化。

class UserSerializer(serializers.ModelSerializer):

    class Meta:
        model = models.User
        fields = '__all__'  # 输出所有字段

5、配置视图。

class TestView(ModelViewSet):
    authentication_classes = []
    queryset = models.Test.objects.all()
    serializer_class = TestSerializer

    def get_list(self, request, *args, **kwargs):
        '''获取热点数据'''

        cacheTime = 10
        cacheKey = 'user_list'
        # 缓存标记
        cacheSign = '%s_sign' % cacheKey
        # 获取缓存值
        cacheValue = cache.get(cacheKey)
        sign = cache.get(cacheSign)
        if (sign != None):
            return Response({'info': 'get redis', 'res': cacheValue})
        else:
            if cacheValue:
                # 执行celery异步缓存数据
                celery_get_data.delay(cacheKey, cacheSign, cacheTime)
                return Response({'info': 'get redis', 'res': cacheValue})
            else:
                cache.set(cacheSign, '1', cacheTime)
                cacheValue = UserSerializer(instance=models.User.objects.all(), many=True).data
                cache.set(cacheKey, cacheValue, cacheTime * 2)
                return Response({'info': 'get database', 'res': cacheValue})

 

二、缓存穿透

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴！

# 数据库中获取数据  
cacheValue = UserSerializer(instance=models.User.objects.all(), many=True).data
# 不管数据是否为空都添加都缓存当中，下次都能在缓存中取到数据（不管是否为空）
cache.set(cacheKey, cacheValue, cacheTime * 2)

三、缓存预热

缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

解决思路：

1、直接写个缓存刷新页面，上线时手工操作下；

2、数据量不大，可以在项目启动的时候自动进行加载；

3、定时刷新缓存；

 

四、缓存更新

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

（1）定时去清理过期的缓存；

（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

 

五、缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级

参考：https://www.toutiao.com/a6533812974807679495/