Casbin使用MongoDB时如何优化查询性能？

Question

在使用 Casbin 结合 MongoDB 作为策略存储时，随着权限规则数量增长，基于默认的通用模型查询（如大量 use of `find()` 操作）会导致性能下降。常见问题是：每次权限校验都需从 MongoDB 中加载全部策略规则到内存，造成频繁且冗余的全表扫描，尤其在大型系统中引发显著延迟。此外，MongoDB 默认未对 Casbin 的关键字段（如 ptype、v0-v5）建立有效索引，导致查询效率低下。如何优化 MongoDB 查询性能，减少 I/O 开销并提升策略匹配速度，成为高并发场景下的关键挑战。

Answer 1

1. 问题背景与性能瓶颈分析

在现代微服务架构中，Casbin 作为一款强大的开源访问控制框架，广泛应用于 RBAC、ABAC 等权限模型的实现。当系统规模扩大时，权限策略数量可能达到数万甚至数十万条，若使用 MongoDB 作为持久化存储，默认配置下 Casbin 会通过 find() 操作加载全部策略规则至内存进行匹配。

这种机制在小规模场景下表现良好，但在高并发、大数据量环境下暴露出严重性能问题：

• 每次校验都触发全表扫描（collection scan），导致大量 I/O 开销；
• MongoDB 未对 ptype、v0-v5 等关键字段建立索引，查询效率低下；
• 频繁从数据库拉取完整策略集，造成网络延迟和内存浪费；
• 策略变更后同步不及时，影响一致性与实时性。

这些问题共同导致权限校验响应时间上升，成为系统瓶颈之一。

2. 核心优化路径：分层递进式改进策略

为解决上述问题，需从数据存储结构、查询机制、缓存策略及架构设计四个维度进行系统性优化。以下按由浅入深的顺序展开。

2.1 建立高效索引策略

最基础且高效的优化手段是为 Casbin 的策略集合创建复合索引。MongoDB 默认无索引，必须手动定义以加速 find() 查询。

字段名	含义	是否常用于查询	建议索引类型
ptype	策略类型（p, g, r 等）	高频	单字段或前缀
v0	主体（如用户ID）	高频	复合索引前导
v1	资源	高频	复合索引中间位
v2	操作	高频	复合索引末尾
v3-v5	扩展字段（如域）	视业务而定	按需加入

推荐创建如下复合索引：

db.casbin_rules.createIndex({
  "ptype": 1,
  "v0": 1,
  "v1": 1,
  "v2": 1
}, { name: "idx_ptype_v0_v1_v2" });

2.2 实现按需加载与懒加载机制

避免一次性加载所有策略，应根据请求上下文动态加载相关子集。例如，在 RBAC 模型中，仅加载特定角色或用户的授权规则。

Casbin 支持自定义适配器，可通过重写 loadPolicy() 方法实现条件过滤：

func (a *MongoAdapter) LoadPolicy(model model.Model) error {
    filter := bson.M{"ptype": "p"} // 只加载p类型规则
    cursor, err := a.collection.Find(context.TODO(), filter)
    if err != nil {
        return err
    }
    defer cursor.Close(context.TODO())

    for cursor.Next(context.TODO()) {
        var rule policyRule
        _ = cursor.Decode(&rule)
        line := strings.Join([]string{rule.PType, rule.V0, rule.V1, rule.V2, rule.V3, rule.V4, rule.V5}, ", ")
        parser.LoadPolicyLine(line, model)
    }
    return nil
}

2.3 引入两级缓存架构

采用“本地缓存 + 分布式缓存”双层结构，显著降低数据库压力。

1. 一级缓存（Local Cache）：使用 sync.Map 或 bigcache 存储最近访问的策略片段，TTL 控制在秒级；
2. 二级缓存（Redis）：共享缓存，支持多实例间同步，存储全量或分区策略快照；
3. 失效机制：监听策略变更事件，通过消息队列广播清除缓存。

流程图如下：

graph TD
    A[权限校验请求] --> B{本地缓存命中?}
    B -- 是 --> C[返回结果]
    B -- 否 --> D{Redis缓存命中?}
    D -- 是 --> E[更新本地缓存并返回]
    D -- 否 --> F[查询MongoDB]
    F --> G[写入Redis & 本地缓存]
    G --> C

2.4 使用分片策略应对海量规则

当策略总量超过百万级时，单一集合性能受限。可基于 v0（用户）或 v3（域/租户）进行水平分片。

示例分片键设置：

sh.shardCollection("mydb.casbin_rules", { "v3": "hashed" })

优点：

• 分散读写压力到多个 shard；
• 提升并行处理能力；
• 适用于多租户 SaaS 架构。

2.5 自定义适配器与查询裁剪

标准 Casbin MongoDB 适配器往往执行全量加载。可通过实现 FilteredAdapter 接口，支持带条件的策略加载。

Go 示例代码：

type FilteredMongoAdapter struct {
    collection *mongo.Collection
}

func (a *FilteredMongoAdapter) LoadFilteredPolicy(model model.Model, filter interface{}) error {
    var bsonFilter bson.M
    // 根据传入 filter 构造查询条件
    cursor, err := a.collection.Find(context.TODO(), bsonFilter)
    // ... 解码并加载到 model
}

调用时指定过滤器：

filter := &casbin.Filter{
    P: []string{"", "/api/users", "GET"}, // 匹配特定资源和动作
}
e.LoadFilteredPolicy(filter)

2.6 监控与性能评估体系构建

建立完整的可观测性链路，包括：

• MongoDB 慢查询日志监控（slowOpThresholdMs）；
• 索引命中率统计（explain("executionStats")）；
• 缓存命中率仪表盘；
• 权限校验 P99 延迟追踪。

执行计划分析示例：

db.casbin_rules.find({
  ptype: "p",
  v0: "uid-123",
  v1: "/api/orders"
}).explain("executionStats")

关注输出中的 totalDocsExamined 和 executionTimeMillis，确保已使用预期索引。