DjangoRedis缓存权限管理与用户角色控制

本文深入探讨了在 Django 中如何通过 Redis 智能缓存用户角色与权限映射关系（而非简单缓存布尔结果），以显著提升高并发场景下的权限校验性能；文章指出直接缓存 `user.has_perm()` 的返回值会导致动态权限失效、细粒度控制失灵等严重问题，转而推荐缓存用户 ID 对应的 Group 名称列表和显式 Permission codename 列表，并结合 `post_save`/`m2m_changed` 信号主动失效，再配合自定义认证后端实现“查缓存 + 内存计算”的高效权限判断——同时提醒读者注意 `permission_required`、`PermissionRequiredMixin` 和 Admin 权限过滤等易被忽略的绕过缓存路径，强调只有统一收口所有权限检查逻辑，才能真正发挥缓存价值。

为什么不能直接把 user.is_authenticated 之后的权限判断逻辑全塞进 Redis？

因为权限不是静态快照，而是动态依赖：用户可能刚被移出某个 Group，或刚被赋予新 Permission，但缓存没失效；更关键的是，Django 的 user.has_perm() 和 user.has_module_perms() 底层会查多张表（auth_permission、auth_group_permissions、auth_user_groups），直接缓存布尔结果会导致细粒度控制失灵。

真正该缓存的是「用户角色映射关系」——即用户 ID 到其所属 Group 名称列表、以及显式授予的 Permission codename 列表。这部分数据变更频率低，且能支撑后续所有权限检查的本地计算。

• 缓存键建议用 f"user_roles_{user.id}"，值为 Python list 序列化后的字符串（如 JSON）
• 务必设置过期时间（如 3600 秒），避免永久脏数据
• 在 Group 或 User 相关的 post_save/m2m_changed 信号中主动删除该键

如何用 Redis 缓存并快速查用户角色（含 Group + 直接 Permission）

不要复用 Django 默认的 django.contrib.auth.backends.ModelBackend，而是在自定义后端中提前加载缓存角色，再做本地判断。核心是把「查库」变成「查缓存 + 内存计算」。

示例片段（放在 backends.py 中）：

import json
import redis
from django.conf import settings
from django.contrib.auth.backends import ModelBackend
from django.contrib.auth.models import Permission
<p>r = redis.Redis(**settings.REDIS_CONFIG)</p><p>class CachedRoleBackend(ModelBackend):
def _get_user_roles(self, user):
key = f"user<em>roles</em>{user.id}"
cached = r.get(key)
if cached:
return json.loads(cached)</p><h1>缓存未命中：查库组装</h1><pre class="brush:php;toolbar:false"><code>    groups = list(user.groups.values_list("name", flat=True))
    perms = list(user.user_permissions.values_list("codename", flat=True))
    data = {"groups": groups, "perms": perms}
    r.setex(key, 3600, json.dumps(data))
    return data

def has_perm(self, user, perm, obj=None):
    if not user.is_authenticated:
        return False
    roles = self._get_user_roles(user)
    app_label, codename = perm.split(".", 1)
    # 先查直连权限
    if codename in roles["perms"]:
        return True
    # 再查组权限（需查 auth_permission 表获取 group-level 权限）
    for group_name in roles["groups"]:
        # 这里不查库！改用预加载的 group_perm_map 缓存（见下节）
        pass
    return False</code>

注意：has_perm 中对 Group 权限的判断不能只靠 group.name，必须关联到 Permission —— 所以还需一层 group_perm_map 缓存。

怎么缓存 Group → Permission 映射避免每次查 auth_group_permissions？

Group 权限极少变动，但每次调 user.has_perm() 都会触发 JOIN 查询，这是性能瓶颈。应单独缓存每个 Group 对应的所有 codename 列表。

• 键名用 f"group_perms_{group.id}"，值为 list 的 JSON 字符串
• 在 Group 的 post_save 和 m2m_changed（监听 permissions 关系）信号中刷新
• 在上一节的 has_perm 中，循环 roles["groups"] 时，用 Group 名反查 ID（可额外缓存 group_name_to_id），再取对应权限列表

若不想维护 name→id 映射，可直接缓存 f"group_perms_by_name_{group.name}"，但需确保 Group 名唯一且不带空格/特殊字符。

使用 CachedRoleBackend 后，哪些地方仍会绕过缓存？

最常被忽略的是 django.contrib.auth.decorators.permission_required 和基于类的 PermissionRequiredMixin —— 它们默认调用的是 request.user.has_perm()，而该方法走的是 User 模型自带逻辑，**不会自动使用你注册的 backend**。

必须显式覆盖：

• 在视图函数中，手动调用 backend.has_perm(request.user, "app.action_model")
• 在 CBV 中重写 has_permission()，实例化并调用你的 backend
• 或全局替换 AUTHENTICATION_BACKENDS，确保它排在第一位，并确认所有权限检查路径最终都走到你的 backend

另一个坑：Admin 界面的权限过滤（如 get_queryset 中的 user.has_perm）也容易漏掉缓存，必须统一收口到自定义 backend 调用。

缓存命中的价值取决于你是否堵死了所有「查库」入口 —— 只要漏一个，就白搭。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~