如何基于Riak KV实现多租户应用适配？

针对Riak 2.0 原生三段式寻址（桶类型:桶:键）没有独立原生命名空间的问题，结合生产环境多租户共享集群的落地经验，隔离性、性能、运维成本综合最优的方案是基于桶类型的租户前置分层设计，核心逻辑与GAE Datastore的命名空间隔离效果对齐，可适配多应用共享同一Riak集群的场景。

核心实现规则 #

• 第一级硬隔离：用带租户前缀的专属桶类型做租户边界
  不将租户标识塞入普通桶名或键名，而是利用Riak桶类型本身是独立配置、独立权限、独立副本策略单元的特性，建立统一的桶类型命名规范：tenant_<唯一租户ID>_<通用业务桶类型名>。
  举个实操例子：租户ecom_001的用户数据桶类型为tenant_ecom_001_user_profile，订单数据桶类型为tenant_ecom_001_order；租户sass_002的对应数据桶类型为tenant_sass_002_user_profile、tenant_sass_002_order。
  这种设计的隔离强度和Datastore命名空间完全一致：不同租户的桶类型无逻辑交叉，可直接为每个租户配置专属的Riak安全访问凭证，权限严格限制在自身前缀的桶类型范围内，从机制上杜绝跨租户越权访问的可能。

• 第二级软隔离：同租户下的业务域通过桶名切割
  同租户的不同合作应用、不同业务模块，统一复用租户前缀下的通用桶类型，在桶名层面做业务域区分即可，比如在tenant_ecom_001_user_profile桶类型下，分别建app_mall、app_crm两个桶存对应业务的数据，不需要为每个业务单独创建新的桶类型，避免集群内桶类型数量无意义膨胀（Riak单集群桶类型数量长期维持在百级以内是最优阈值，数量过高会增加集群元数据同步的额外开销）。

配套落地的必要规则 #

• 所有Riak API请求由统一的接入网关做租户标识自动拼接，禁止业务代码直接手动拼接桶类型名称，从流程上避免漏加租户前缀导致的数据串写问题。
• 运维层面清理租户数据时，可直接定位删除对应租户前缀的所有桶类型，不需要遍历全集群数据做逐条筛选，清理效率远高于把租户标识塞在键名、桶名的方案。
• 租户级资源隔离可按桶类型单独配置副本数、读/写超时、冲突解决策略，不会出现单个租户的高负载请求拖垮同集群下其他租户的性能问题。

常见替代方案的不足 #

• 把租户ID塞在普通桶名里：同个公共桶类型下会堆积大量分属不同租户的桶，权限无法按租户粒度配置，只要拿到该桶类型的访问权限就能读取所有租户的数据，无法实现硬隔离，同时桶数量的膨胀会快速抬升集群元数据规模，拖慢元数据同步效率。
• 把租户ID塞在键名里：所有租户数据混杂在同一个桶下，既无法做租户级的权限控制，也无法实现租户数据的快速清理，大租户的热点键还会直接干扰其他租户的请求稳定性，完全不适合多租户场景。

注：该方案不需要对Riak内核做二次修改，完全基于原生2.0以上版本的能力实现，适配现有API的改造量最小。

内容的提问来源于stack exchange，提问作者quarks