作者 | 陈新江 万达网络科技集团大数据中心

万达网络科技集团( http://www.wanda-tech.cn/ )是中国唯一的实业+互联网大型开放型平台公司，拥有飞凡信息、快钱支付、征信、网络信贷、大数据等公司，运用大数据、云计算、人工智能、场景应用等技术为实体产业实现数字化升级，为消费者提供生活圈的全新消费服务。

万达网络科技集团的技术团队，建设和维护着一套实时风控平台。这套实时风控平台，承担着各种关键交易的在线风控数据的写入和查询服务。实时风控平台后端的数据库系统在高性能，可靠性，可扩展性上有很高的要求，并且需要满足如下核心功能和业务要求：

1. 风控相关业务数据实时入库
2. 实时风控规则计算
3. 通过 BI 工具分析风控历史数据
4. ETL 入库到 Hadoop 数据仓库
5. 应用开发侧需要兼容 MySQL，降低应用改造门槛

为实现上述业务目标，万达网络科技集团的技术团队在实时风控数据库选型的早期阶段，首先选择了 MySQL Galera Cluster 作为数据库集群的技术架构。这套 MySQL 数据库架构通过不同于 MySQL 主流复制技术的复制机制，实现在多个 MySQL 节点间建立强同步关系，实现数据的副本和高可用。但经过业务实践，发现这套方案有诸多问题，其中比较突出的有以下几点：

• MySQL Galera Cluster 自身的强同步机制以大幅度降低集群整体性能为代价，集群整体性能比单节点 MySQL 还差。所以不能很好的满足“风控相关业务数据实时入库”的业务需求。
• 同时，MySQL Galera Cluster 的 JOIN 支持非常弱，不足以支持 BI 相关的复杂分析。
• 集群整体性能的短板加上对 JOIN 支持的薄弱，使得要在业务上实现大并发高性能的风控规则计算变的很困难。

上图：风控平台原来采用的 MySQL Galera Cluster 集群架构

万达的技术团队还考察了市场上用的比较多的 MySQL 主从复制以及通过 MySQL Proxy 中间件实现分库分表的方案。但这些方案，无论是高可用安全性，强一致性，还是对业务应用所需要的复杂事务／JOIN 操作以及横向扩展能力上，都无法满足实时风控平台的业务要求。这些问题集中反映在以下几个方面：

• 基于 MySQL 主从复制方式的高可用方案，容易出现诸如接入层脑裂和数据不一致的风险。
• 基于 MySQL Proxy 中间件的方案，缺少对分库分表后的跨库跨表的分布式事务支持以及对复杂JOIN 的良好支持，因此也无法满足业务上风控规则实时计算和复杂查询的需求以及对业务团队的 BI 需求的支持。
• 基于 MySQL Proxy 中间件的方案需要业务代码的开发妥协，需要显式设计和指定分库分表的切分规则和路由配置，开发改造和运维成本显著增高。
• 在实时风控平台的高并发高性能的对外服务过程中，在线灵活扩容的相关工作在 MySQL Proxy 中间件架构中无法高效和可靠的实施。

最终万达的技术团队，通过评估验证，选择了 TiDB 帮助他们实现一个高性能，高可靠性和高扩展能力的实时风控平台后台数据库系统。

上图：TiDB 的整体框架图

TiDB 产品和技术方案对业务需求的支持和助力效果，集中表现在：

1. 借助 TiDB 的分布式计算和存储引擎，集群对外服务的处理能力大大增强，高并发实时的风控规则计算能够轻松的处理完，相比较原来的 MySQL Galera Cluster 方案，单位处理性能提升了数倍。并且数据库集群获得了线性提升和扩展的能力。
2. 集群整体 QPS（万级起）和 Latency (毫秒级) 对风控的实时性要求做出了技术保证。
3. 无需考虑分库分表，对业务应用透明无侵入，应用开发和维护变得直观且简单。业务相关数据量规模和请求即便高速增长，也无需担心应用的复杂调整和运维的风险。
4. TiDB 针对分布式事务和强一致性的完善设计以及对各种 JOIN 模式的支持，使得实时风控类和 BI 分析类的业务应用能够高效运行。

这套实时风控平台，借助于 TiDB 的可靠性架构和高性能分布式处理能力，在业务生产环境已经稳定运行超过半年，期间经历过环境问题导致的故障，经历过诸如 “618” 高并发、大流量活动的严格考验。

万达网络科技集团大数据中心技术专家陈新江表示："TiDB 的表现让万达的技术团队有了信心，接下来将在 TiDB 的基础上，根据业务特点，拓展应用规模，增加诸如 TiSpark 复杂计算组件，整合 CDC 工具以提升 ETL 实时性以及增强 TiDB 运维管理能力等多项架构和技术演进工作，继续在万达的核心业务架构中发挥重要作用。"