多租户与幂等性
AiHummer 是 多租户：一个网关可以从一个数据库为多个工作区提供服务，同时保持它们的数据分离。有两种机制可以保证其安全—— Postgres 行级安全（RLS） 用于读/写隔离，以及一个 幂等层 这样重试和转换恢复就不会重复现实世界中的副作用。
等级： 行级安全多租户隔离由付费版控制 企业 层级 — 不属于免费/社区平台；幂等层是核心的一部分。
使用行级安全的租户隔离
隔离是在数据库层面强制执行的，而不仅仅是在应用程序代码中。AiHummer通过一个 受限的 Postgres 角色 (aihummer_app) 已应用 RLS 策略，因此数据库本身会拒绝不属于活动租户的行。
RLS是 选择加入. 您可以通过为网关提供第二个用于受限角色的连接字符串来激活它：
# gateway.env
# Owner pool — runs migrations and privileged maintenance
AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable
# Restricted role — activates RLS for normal request traffic
AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable[!NOTE] 对于本地主机安装，安装程序会设置
AIHUMMER_DB_APP_URL自动，因此在标准部署中，RLS 默认是开启的。如果 变量缺失时，网关仅在所有者池上运行，并且 RLS 不启用 活跃的。
每租户范围
在受限角色内，每个请求都限定在其租户范围内：网关在连接上设置当前租户上下文，以便 RLS 策略针对正确的工作空间进行解析。 WHERE tenant_id = … 过滤器并不是到处手动设置的；该策略在中央强制执行，这意味着遗漏的过滤器不会泄露其他租户的行。
系统 / 绕过模式
有些工作确实是跨租户的——后台作业、调度程序和在整个实例中运行的维护任务。这些运行在 系统 / 绕过模式 这样他们就能看到他们需要的内容。绕过仅限于受信任的内部员工，不适用于处理请求的路径。
[!WARNING] 迁移始终在所有者池上运行，绝不处于受限角色下。 所有者连接具有更改架构和应用行级安全性的权限 政策；受限角色故意不这样做。保持这两个连接 独特的字符串并授予
aihummer_app角色只做它需要做的事。
幂等副作用
一个回合可能会产生现实世界的副作用：发送邮件、在频道中发布消息。如果一个回合被重试——因为暂时性错误，或因为网关在回合中途重启并且恢复时重新执行——这些副作用必须 不 发生两次。AiHummer通过两个协作部分保证这一点。
可恢复稳定的账户账本密钥
每种副作用都被记录在 恢复稳定分类账密钥：一个从轮次确定性派生的密钥，因此同一轮次的重放会计算出相同的密钥，而不是新的密钥。账本会记住哪些密钥已经被操作过。
副作用屏障
在诸如……这样的效果之前 邮件 或者 频道发送 被执行时，它会经过一个 副作用屏障 检查账本。如果这个键已经触发，屏障就会短路，效果会被跳过；如果没有，效果就会执行，键会被提交。
side-effect requested
└─▶ compute resume-stable ledger key
└─▶ barrier: key already committed?
├─ yes ─▶ skip (no double-send)
└─ no ─▶ perform effect ─▶ commit key结果是 即使内部传递至少一次，也能实现外部行为的精确一次. 重试是从设计上就安全的，这就是为什么可以进行转向恢复（见 可靠的交付和回收) 重播中断的回合，确保客户不会收到同一封电子邮件或同样的回复两次。
[!TIP] 这就是为什么AiHummer可以提供保证交付和自动回转恢复的原因 没有通常的重复消息风险——幂等性是基础 交付保证是建立在……上的。