现象：规则串了、配额被吃了，问题往往出在共享层
AB页跳转是本文的核心主题。前一阵有个做工具类应用的客户找过来，说他们一套跳转服务上同时跑着三个投放项目。结果某天A项目的规则一更新，B项目那边有一部分流量莫名其妙就跳到A的落地页去了。查下来原因挺简单——两个项目在规则库里用了同一个规则键名，加载的时候后面那个把前面那个覆盖掉了。你说这算配置写错吗？其实不算，问题出在共享命名空间下键撞了。
还有一种症状也常见，就是资源被抢。某个项目赶上大促放量，跳转服务的连接池和CPU直接吃满，别的项目决策延迟从几十毫秒一下子飙到几百毫秒，放行逻辑开始超时降级。乍一看像是容量不够，往深了挖才发现是租户级的资源配额和隔离边界没做。
这两种毛病说到底指向的是同一件事：AB页跳转多租户隔离。它不是说要把服务拆成好几套，而是在共享基础设施上，靠命名空间和配额把租户之间的耦合面给切开。
定义与机制：命名空间管逻辑，配额管物理
什么是规则命名空间
规则命名空间你可以理解成每个租户规则集合各自待的一个逻辑容器。每个租户有自己的键空间，规则ID、规则名称、优先级序号这些都在自己空间里编号，跨租户之间不共享也不会打架。规则引擎做加载和匹配的时候，第一步是按租户上下文路由到对应的命名空间，然后再在那个空间里面做优先级仲裁。
划分粒度上，通常有三种做法。按投放账户来分，代理或者代运营的场景比较适合这种。按项目或业务线来分，自有团队多产品线并行的时候用得多。还有就是按环境分，测试、预发、生产各一套，需要隔离验证链路的团队会选这个。实际落地的时候，账户粒度和项目粒度经常会叠着用，形成两级命名空间。
资源配额管什么
资源配额说白了就是给租户能消耗的物理资源设个上限。常见的维度有这几块：
- 规则条数上限。单个命名空间能加载多少条规则得有个数，不然某个租户规则一膨胀，全局匹配都被拖慢。
- 决策QPS上限。租户每秒能发多少跳转决策请求，超了就排队或者直接拒掉。
- 连接数和并发上限。租户占用的后端连接、工作线程或者协程数量都得管住。
- 缓存配额。共享缓存层里，租户能占多少键或者多少内存字节，这个也要卡。
- 日志与存储配额。决策日志、审计记录的写入速率和保留周期同样得设限。
配额这东西不建议写死。比较成熟的做法是搞基础配额加弹性配额——基础配额保证租户日常够用，弹性配额就是在全局资源空闲的时候按优先级临时借一点，紧张了再收回来。
输入、处理与输出的隔离点
从请求的整个生命周期来看，隔离会落在四个位置上。请求进来的时候，先解析租户标识、绑定租户上下文，这是输入侧。到了处理侧，规则加载、匹配、优先级仲裁全在租户自己的命名空间里完成，缓存键前缀也带上租户标识。输出侧呢，决策结果和日志写入按租户分区，方便单独审计和限流。运行边界侧比较特殊，配额检查在决策入口和资源申请点各做一次，入口那次是快速拒绝，资源申请点那次是防止慢速泄漏。
适用条件与边界：什么时候必须做，什么时候可以缓
多租户隔离不是所有AB页跳转场景都得上的。判断要不要做，主要看三条。
租户之间有没有规则键冲突的风险？多个项目共用规则库、键名又没有全局唯一约束的话，那隔离就是刚需。租户之间会不会抢资源？某个租户的流量峰值能明显影响其他租户的决策延迟或者成功率，配额隔离就有必要。还有一条是合规和审计上的隔离要求——金融、医疗这些行业的投放项目，经常要求决策日志按主体分开留存。
反过来说，如果就是单租户独占一套跳转服务，或者租户数量很少、流量互相也不干扰，那引入完整的多租户隔离反而增加配置复杂度和运维成本，收益有限。这种情况下先做个命名空间前缀约定就行，配额机制等租户多起来再补也不迟。
一个中小团队的落地过程
有个做本地生活服务的团队，日均跳转决策请求几十万量级，服务器是四台中等规格的实例。他们一开始把三个城市站点的规则全放在同一个规则库里，用城市编码做前缀来区分。跑了两个月，其中一个城市搞活动，规则条数从几十条涨到三百多条，全局匹配耗时肉眼可见地上升，另外两个城市的决策延迟也跟着抖。
后来调整分了两步。先把规则库按城市拆成三个命名空间，加载和匹配各自独立，键冲突的问题先解决掉。接着给每个命名空间设了规则条数上限和决策QPS上限，活动期间临时申请弹性配额。调完之后，单个城市规则膨胀不会再影响其他城市的决策耗时，活动期间的延迟波动也被限制在申请配额的那个租户里面。这个案例里没用上什么复杂的配额调度算法，命名空间拆分加静态上限就把大部分问题解决了。
相邻概念对比：隔离、分组与限流不是一回事
与规则分组的关系
规则分组是按业务维度对规则做的逻辑归类，分组里的规则还是共享同一个键空间和资源池。多租户隔离是在分组之上又加了键空间隔离和资源边界。分组解决的是可读性和管理效率，隔离解决的是冲突和争抢，两码事。
限流管的是请求速率，一般作用在单个租户或者全局入口上。资源配额比限流宽，除了速率还覆盖规则条数、缓存占用、存储写入这些维度。所以说限流是多租户隔离的一个子集，它兜不住全部。
与部署隔离的关系
部署隔离就是给租户分独立实例或者独立集群，隔离最彻底，成本也最高。多租户隔离追求的是在共享实例内用逻辑边界达到可接受的隔离效果，成本和隔离强度正好卡在完全共享和完全独立中间。选哪种，看租户数量、流量规模和合规要求这三者怎么组合。
落地时的检查项与常见误区
命名空间划分要覆盖三个地方：规则键、缓存键、日志分区键。只做了其中一处，隔离就是不完整的。配额设置要区分硬限制和软限制，硬限制用来防止资源耗尽，软限制用来触发告警和弹性调度。还有一点，租户标识必须在请求入口就绑定好，不能等到规则匹配阶段再去解析，不然缓存和日志早就写错分区了。
误区主要有两个。一个是命名空间拆了但缓存键忘了带租户前缀，结果A租户的决策结果被B租户命中了。另一个是配额只设了QPS，规则条数和缓存占用没管，某租户靠大量小规则或者缓存键慢慢把共享资源吃掉。这两类问题在租户少的时候不容易暴露，租户一多就会集中冒出来。
AB页跳转多租户隔离的本质，是在共享基础设施上给每个租户划出一条可观测、可限流、可审计的决策边界。命名空间负责逻辑隔离，资源配额负责物理隔离，两者缺一不可。对于多项目、多账户并行投放的团队来说，这套机制是跳转链路稳定性保障的基础设施之一。
