多租户策略
一套分布式数据库集群可以用于支持多个业务，通过分配多个数据库实例进行管理，这就是多租户策略。多租户是分布式数据库实现资源隔离与未来进行云化发展的基础，通过多租户还可以实现安全的隔离、故障的隔离、运维的隔离等。
首先是租户资源的隔离，租户是资源分配的最小单元，每个租户可以进行CPU、内存、存储、网络带宽、连接数等的资源控制。CPU等资源可以在租户创建时进行指定，也可以按需进行动态调整。每个租户之间的资源不进行复用，以避免资源的抢占带来的稳定性问题。
其次是安全的隔离，租户有对应的用户权限，每个租户的用户只能访问自己租户内的实例以及相关租户资源。不存在可以进行跨租户访问的超级用户，实现了安全策略的可控，避免了数据安全问题。
再次是故障的隔离，因为硬件资源的隔离，单个租户的“抖动”、资源不足、数据错误等不会影响其他租户，对于分布式数据库的监控最小采集粒度是租户级别，数据库的故障影响分析也从租户维度进行关联分析。
最后是运维的隔离，租户是资源分配的最小单元，在进行资源调度、集群扩容时按照租户进行迁移，集群的备份与恢复也从租户维度进行控制。
“异地多活”之“三地五中心”
《商业银行数据中心监管指引》要求金融机构设立异地模式的灾备中心，其中重要系统的灾难恢复能力要达到《信息安全技术 信息系统灾难恢复规范》中定义的灾难恢复等级第5级（含）以上。具体要求是，RPO为数分钟到两天，RTO为0～30分钟。传统银行中最常见的是“两地三中心”模式，具备同城的机房级容灾能力，实现了同城一个机房故障下RPO为0，异地数据弱一致。网商银行从“两地三中心”的“异地多活”进一步发展到“三地五中心”，实现RP0为0，RTO在1分钟内的城市级容灾架构，保证了银行系统的高可用和不间断的用户服务能力，实现了金融服务的随时在线。
常见部署模式
（1）同城双机房采用主备模式，应用访问主数据库，进行数据写入。（2）同城双机房间采用存储设备的同步复制，保障同城双机房之间的数据实时一致。（3）异地机房用异步复制方式进行数据同步，备份节点数据非强一致，对数据实时性要求不高的可以进行读访问。（4）同城主备库之间进行故障检测，出现异常时进行主备切换。（5）应用端可以通过使备库只读而降低主库压力。这种部署模式本质上只能做到机房级容灾，当城市1异常时，城市2的数据是不完整的，无法实现城市级的容灾。
分布式数据库“两地三中心”（见图3-1-5）
传统银行的“两地三中心”（见图3-1-4）
（1）“两地三中心”模式有三个副本，采用主备模式，应用访问主数据库，进行数据写入主库。
（2）主库数据实时同步到所有备库，基于一致性协议，在1/2的节点完成数据的同步后，即认为数据同步完成。同城机房因耗时更短，两个机房的数据保持实时同步。
（3）异地机房因耗时较长，在数据同步上有延迟，但相对于传统银行的备份节点，该延迟较小，在1分钟以内。
（4）两个从节点都可以提供数据的弱一致性只读服务。三个副本中最多允许有一个故障点，所以这种模式只具备城市2的城市级容灾能力，不具备城市1的容灾能力。分布式数据库“三地五中心”（见图3-1-6）
“三地五中心”模式有五个副本，最多允许存在两个异常节点，所以采用2-2-1的方式进行分布建设。当任意一个城市的机房发生城市级的故障时，数据库都依然能够继续提供服务。
五副本在进行数据写入实时同步时，需要三个节点完成写入，因一个城市最大节点只有两个，所以必然会存在跨城市的实时同步，带来耗时的增加。具体耗时的增加与城市间的距离有关，例如从杭州到上海，需要增加6～8毫秒。
城市3只有单节点，无法满足城市内的容灾要求，一旦有故障，应用都需要跨城访问数据库，所以在部署时，城市3不进行应用的部署。由于不提供数据服务，城市3可以进一步降低成本，机房5作为日志副本，无全量数据，参与一致性协议投票选举主节点。
