支撑千亿级日交易额，平安科技分布式数据库架构设计

过去十年，飞速发展的信息技术给企业的数据量带来了成百上千倍的增长，也让更多人受益于数据服务，与此同时，数据应用的场景变得越来越复杂，对实时性的要求也在提高。

在实时性、高可用等需求的推动下，越来越多公司开始使用分布式数据库。面对保险业务飞速发展，以及庞大业务量的挑战，平安集团在 2018 年引入了分布式数据库 TiDB，用来支撑金融、医疗健康、投资等业务。

在这期间，TiDB 数据库实例保障了 2019 年“1.08 财神节”单日交易额破千亿，并通过弹性的水平拓展，使数据库集群的性能有了量级的提升，使互联网保险业务可以抗住每秒几千单的压力……同时，平安集团基于 TiDB 基础的数据库引擎，自研了金融级分布式数据库 UbiSQL。2022 年，平安集团完成了首套传统商业集中式数据库迁移到 UbiSQL 的关键项目存储过程约 2 万行，之后，依次进行应用层功能的全回归测试、应用的性能压测以及数据库的压测，并对迁移后的数据库做相应的监控和报告，通过这套方法，平安集团对内部比较核心的统一支付、客户信息核心管理系统以及工作流系统进行了完整的迁移。

从架构设计角度出发，不同路线的分布式数据库应该怎么选择？分布式数据库带来的运维复杂性怎么解决？重建 OLAP 或者新建 HTAP 哪个更有效？为什么现在选择乐观协议的分布式数据库越来越少？本文，InfoQ 采访了平安科技总工程师及数据库团队负责人汪洋，试图探寻上述问题的答案。

2018 年，是平安集团开始使用 TiDB 的关键时间点。彼时，伴随着数字化转型，平安集团连续几年开展类似双十一的促销活动，在稳定性方面具有较大优势的传统商业集中式数据库，伴随着平安集团平稳走过了几个“开门红”活动。

由于当时还没有分布式数据库的模式，平安集团需要在大型活动前进行容量评估——是否需要将数据库从一台小规格的机器迁移到大规格的机器上？如果按需扩容，在活动结束后，采购的机器应该如何处理？……在这样的情况下，平安产险 2018 年的“开门红”活动中，首次尝试应用了原生的分布式数据库 TiDB，通过一个月的搭建和测试，TiDB 满足了平安集团对分布式数据库的预期，也很好地支撑了“开门红”活动。

当时，市面上供选择的分布式数据库已经有很多了，据汪洋回忆，平安集团选择引入 TiDB 主要有两方面的考虑。

一是技术层面，如前文所述，TiDB 的能力已经在平安集团的业务中得到了验证，而且对于开发人员和 DBA 而言，学习成本也可以接受，同时，作为国产数据库，TiDB 也能最大限度地保障信息自主可控。

二是生态层面，平安集团将数据库是否开源视为一个重要的考量因素。在 TiDB 之前，平安集团也引入过 Redis，MongoDB 等开源数据库，已经了解使用商业数据库可能带来的成本等各方面的问题，因此开源成为了选型的必选项。在开源的基础上，也关注开源社区的活跃程度：社区的生态好不好、有没有可持续性、软件迭代的速度快不快等。汪洋表示，TiDB 遍布世界各地的贡献者、针对数据库开设的培训课程、积极通过生态工具或者集成的方式增强产品性能等方面，都体现了社区的活力。

出于金融机构对数据库稳定性、高可用的要求，以及国内对信息自主可控的要求也在提升，平安集团也想推出自己的原生分布式数据库，这样不仅能降低数据库迁移的成本和风险，也能保证平安集团技术的自主可控，保障信息安全。

基于这些考虑，平安集团基于 PingCAP 公司的 TiDB 打造了金融级分布式数据库发行版 UbiSQL，在提升运维效率，满足金融监管要求以及信息技术自主可控 3 条线同时发力，持续适配不同金融场景。为了更好地处理 UbiSQL 的运维问题，平安集团将问题依据复杂程度划分为了三级，简单的问题内部解决，复杂的问题引入 PingCAP 的技术团队共同处理，同时，平安集团也在培训工程师，提高团队消化问题的能力。目前，UbiSQL 实现了研发能力、解决方案能力与交付运维能力的进化，也进一步适配了金融场景的需要。

凡事都有两面性，分布式也不例外。分布式的确在扩缩容和资源配置等方面带来了便捷，但从运维角度来看，分布式带来了很多不确定性，这给数据库的运维带来了很多挑战。

面对平安集团这样庞大的数据体量，数据库运维的压力更大。对此，汪洋表示，大规模运维有一个很好的理念——脚本工具化、工具平台化、平台产品化，平安集团也是按照这个思路，以云的理念和模式进行运维，主要有两个方面。

第一，依靠云的服务。在开源数据库和微服务架构兴起的趋势下，数据库实例会越来越多，每个环境都不一样，因此，大规模运维的终极解决方案就是通过云的模式，通过暴露服务的方式进行运维。像平安云 UbiSQL、TiDB Cloud，不仅可以对资源池成本进行更好的管理，也更适合大规模运维，给用户带来更好的体验。比如，将 UbiSQL 引擎的进一步封装，在云上通过 Database as a Service (DBaaS)的方式进行运维；云上的 Serverless 模式 可以更灵活的使用资源，同时满足运维的需求；或者将 SRE、DBRE 等概念，融合到容器化的 Operator 中，当故障发生或者存储不足时，帮助系统自愈或者进行扩展。汪洋认为，通过云原生的 Operator，未来数据库会走向容器化，进一步提高开发和运维的效率。

第二，数据库标准化、规范化建设。云的优势之一，就是能够将资源统一管控，将资源的价值最大化。因此同一种数据库架构、配置相同的情况下，用户的定制化改动都能被配置中心记录下来，这样就给大规模复杂运维创造了条件。同时，因为所有的环境都是标准化的，所以在发生问题后可以将解决方案下发到数据库的所有实例中去解决，避免问题再次发生。

围绕分布式数据库架构设计在时效性、技术路线、微服务化等热门话题，InfoQ 也与汪洋进行了进一步的探讨，以下为主要的观点及未来设想。

汪洋：技术无分对错，只有最合适的场景的技术。OLAP 与 HTAP，或者说 MPP 与 HTAP 解决的是不同场景中的问题。

MPP 数据库，或者说我们现在说的一些数据仓库，更侧重在战略的层面，对大规模数据进行加工、分析和处理，生成报表，提供 BI，它对时效性的要求没有 HTAP 那样高。而且，MPP 数据库在大规模数据加工、处理方面、应对负载的能力更好。

OLAP 与 OLTP 是两种完全不同的形态，数据库引擎有三大核心：如何解决数据存储的问题？如何解决数据访问的问题？如何解决数据更新的问题。OLTP 倾向于行式存储；而 OLAP、MPP 基本上以列式存储为主。在 SQL 优化器引擎方面的设计也不一样，OLAP 中，我们会思考怎样解决雪花模型、怎样应对即时查询还能快速返回、怎样解决数据聚合方面的问题……这些优化思路与 OLTP 是完全不同的。

MPP 本身就很专一和聚焦，比如说，面对我们现在常提到的数据湖，它可以解决类似数据湖这些超大规模的数据量带来的分析、加工的问题。HTAP 更侧重于战术和操作类型的决策。有些东西在进入到数据湖之前，可能需要基于当天的销售额进行快速的决策：那些需要改变的货物上架了、需要做哪些调整等。

对于商业决策来说，快速把握瞬息万变的意味着掌握商机。在 HTAP 被应用之前，需要从 OLTP 的数据库中，把数据转到大数据平台上加工，再把结果或者数据模型反馈回来，加载到 OLTP 数据库中，这个流程耗费了很多时间。而 HTAP 不需要数据搬迁，也不消耗数据搬迁的成本，它只需要当天的或者短期的数据，在自己的数据库中，就可以帮助我们做短期的、操作类型的决策。

最后，举例来说，如果分店经理想要基于当天的业务数据进行操作和决策，那么 HTAP 比较合适；如果面向的是超大规模的数据，且进行战略层面的方向制定，那么 MPP 更有优势。

汪洋：以前采用 TiDB 的都是互联网企业，例如，对于电商企业而言，它们不会对同一行的账目进行更新，基本上是根据一些维度，比如卖家、卖家进行分片，基本上是比较孤立的，这样的情况下，发生冲突是一个小概率事件，而“乐观锁”的代价相对较小，也避免发生额外的成本，还能保证较好的整体性能。

现在越来越多的企业采用 PG，是由于企业的业务逻辑和以往互联网企业的简单逻辑相比更为复杂，MySQL 在复杂逻辑方面与 PG 相比有不足之处。但这两种数据库都是悲观锁模型。在越来越多的企业选择 TiDB 的情况下，也出现了一些问题：第一，在原有企业应用迁移过程中，类似于从悲观锁转变乐观锁这样的迁移，带来“水土不服”的问题。会经常发生并发任务更新同一行数据库的情况，乐观锁的代价远比悲观锁的代价要高；第二，开发人员思维转变的问题，很多开发人员已经用了很多年的包括 MySQL、PG 等都是悲观锁，那么可能下意识的设计出适用于悲观锁的模型。如果 TiDB 只有乐观锁模型，就一定会发生冲突。另外如果企业要用乐观锁，开发人员也同样需要改变一些习惯和设计的方法。

另外，像企业金融账目想要更新具体某一行数据，多并发的连接和事务需要对同一行或者同一个数据进行操作，在这样的情况下，采用乐观锁势必会在提交过程中遇到大量的冲突，造成性能下降，这种情况下，不如换悲观锁，这样就避免在提交时处理冲突。在我看来，以上的几方面原因决定了现在的 TiDB 要支持悲观锁。

汪洋：云数据库未来的发展趋势，第一，会朝着 Serverless 数据库发展。但 Serverless 和现在非 Serverless 数据库也不是谁取代谁的问题，还是要看应用场景。这是因为 Serverless 还存在需要解决的问题，比如说，节点扩展得够不够快，可能会存在短暂的暂停，我们怎样提升启动效率等，这些都会影响到性能的一致性。

第二，在云上实现存算分离。云上本身就有资源池的概念，也提供了分布式的存储，通过 NVMe/RDMA 的组网提供了很好的性能。然而在本地化部署中，我们很难做到这么大的规模，云上实现存算分离是未来的趋势，对于分布式数据库来说，存算分离也是趋势。

第三，云上大规模智能运维。云上数据规模比较大，更容易收集到诊断数据进行分析，我们甚至可以将 AI 算法引入进来，弥补人工运维的不足，提前发现隐患。此外，可以在问题发生后通过关联分析得出结果，将模型套用回去，当下次发现它相同模式的时候，就可以在问题发生前，进行一些处理，也就是自愈。

第四，提供智能化建议。云上的智能诊断自愈和建议，都是建立在可见性的基础上，因此当我们做大规模部署的同时，就要增加产品的可见性，有了足够的信息，就能够进行智能自愈和建议，这里面所说的智能建议是指，比如说，应不应该创建索引，或者发现一些对系统性能有影响的 SQL 语句并给出针对性优化建议等。

第五，解决多租户管理的问题。既然一个数据库中不只支撑一个微服务，就会有租户管理的问题，数据库里面可以入住多个租户，就会带来故障隔离、资源隔离的问题，我们需要思考如何让每个租户看似在一个集群中，又有属于自己的资源使用池。以上这些都是未来可以做的方向。

汪洋：从两个方面考虑，一方面是数据库怎样支撑微服务化，现在对微服务化的定义中有一点是说，微服务中每个服务都是一个闭环，它有自己的存储引擎、数据库引擎、中间件等，不同的技术栈都能找到一个针对于这个服务最合适的数据库，但实际运行下来，会增加很多数据库的运维成本。

微服务兴起带来了规模急速增长，虽然我们在云上有了大规模运维的能力，但是大部分情况下，我们采取了一种平衡的架构，一方面能减少故障的影响范围，另一方面，不会严格地按照每一种服务都是自己的数据库引擎，来避免在运维和资源使用上造成 overhead 增加，这就涉及到数据库怎么支撑应用微服务的问题。

对于数据库自身的微服务，在内核引擎上这种原生的分布式已经实现了一部分，这是因为它的每个组件都是解耦的，像 UbiStore、UbiServer 或者 UbiMeta 层（对应 TiDB 产品的 TiKV、TiDB 和 PD 层），都通过 gRPC 进行互相调用，这也是有微服务化的理念在支撑——专业的组件做专业的事情。在 DBaaS 产品中，我们也需要对数据库内核引擎进行包装，通过服务接口调用一些主机、操作系统和存储方面的接口，完成整体服务编排。这些都是数据库自身实现微服务化的体现。

此外，在云数据库产品中，还有一些编排系统，比如在创建 UbiSQL 时要写一些配置或者调用一些配置、账单的管理，这也是各自的微服务。由于云数据库产品本身涉及到编排系统，还需要跟账单系统、计费系统等配置系统打通、备份恢复等，都需要调用其他的组件，因此这种微服务在云上体现的更加明显。UbiSQL 的存算分离、几个组件之间的调用、应用系统的支撑以及多租户的管理等，都体现了微服务的概念。

数据库未来的发展中，开源将是一条重要的路线。近几年，在国家政策导向、自主可控要求，以及云模式和云计算的兴起等多方面因素影响下，国内开源生态的发展与之前相比开放了很多，OB、TDSQL、openGauss 等国产数据库都在开源。去年，国家也在鼓励开源社区在国际上贡献力量，提升自身的影响力。

汪洋表示，在未来，符合开源精神的彻底开源十分重要。目前，有些数据库并没有开源出所有的功能，而我们需要的是彻底开源、具有扩展性和良性开源生态的开源数据库。正如平安集团当初引入 TiDB，不仅仅是因为它是开源的数据库，更是因为它的开源精神比较彻底。