{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/building-a-new-generation-data-service-platform-for-fintech",
    "result": {"pageContext":{"blog":{"id":"Blogs_474","title":"方案精讲丨TiDB 助力 Fintech 构建新一代数据服务平台","tags":["TiDB","Fintech"],"category":{"name":"产品技术解读"},"summary":"本文讨论了金融科技（Fintech）行业在数据基础设施建设上所面临的挑战，以及 TiDB 数据库在解决这些挑战方面的天然优势。","body":"本文讨论了金融科技（Fintech）行业在数据基础设施建设上所面临的挑战，以及 TiDB 数据库在解决这些挑战方面的天然优势。TiDB 的 HTAP 架构和强大的水平扩展能力，为 Fintech 甚至是 Web3 的企业提供了重要的业务价值。本文将探讨 TiDB 如何应对 Fintech 行业的痛点，以及它为这些企业带来的实际价值。\n\n## 背景\n\nFintech 是金融（Finance）和技术（Technology）两个词的结合，主要指能够撕裂传统金融服务方式的高新技术。Fintech 涵盖了大量的细分行业，除了日常生活中经常接触到的移动支付和互联网银行，还包括像区块链、Web3 和 NFT 等新兴细分行业。\n\n![Fintech 行业范畴.png](https://img1.www.pingcap.com/prod/Fintech_81fce05d82.png)\n\nFintech 行业的快速发展提出了一些业务需求。首先，Fintech 是全球经济中规模最大、增长最快的业务之一。其次，新冠疫情加速了整个金融科技的发展趋势，例如非接触支付、在线支付、保险和数字金融等服务的需求急剧增加。此外，由于其行业特性，Fintech 对数据的一致性和服务的可靠性、数据的安全合规以及监管等都有严格要求。因此，在选择相关解决方案时，通常会保持非常谨慎的态度。\n\n除此之外，Fintech 以客户为中心，需要对客户行为进行实时数据洞察，以更好地了解客户行为，量身定制转型、实现个性化营销和为用户提供增值服务。\n\n最后，在 Fintech 这样高度创新的技术背景下，通常在策略调整和产品方向选择上非常灵活、快速。因此，相较于传统金融企业，Fintech 更加敏捷，相关产品推向市场的时间更短。\n\n## Fintech 行业面临的技术挑战\n\n随着金融科技行业持续发展，对技术领域也提出了更多挑战，落在数据库方面，当相关数据量或整个业务请求量达到单机限制时，整个数据基础设施建设就会变得非常复杂。基础设施复杂化会带来以下问题：\n\n- 首先，很难在关键核心 OLTP 联机交易场景下，同时保证数据一致性及可靠性；\n- 数据架构复杂化会导致数据处理链路和时效性出现相对较差的情况，从而使大规模实时洞察变得非常困难；\n- 再者，为了适应基础设施的复杂性，前端业务开发需要不断使用更多的技术栈，并让应用程序依托于多种技术栈来支撑业务访问，这会拉长业务开发时间并使应用程序开发更为复杂，从而导致上市时间变慢；\n- 最后，为管理财务数据，还需要满足严格的监管和合规要求。\n\nTiDB 作为企业级分布式数据库，其拥有的天然优势，可以很好地解决 Fintech 行业所面临的痛点。它的 HTAP 架构设计和出色的水平扩展能力，对于 Fintech 甚至是 Web3 的企业来说，都具有非常重要的业务价值。\n\nTiDB 的架构设计非常简洁，在一套架构中同时提供了行存和列存两种存储引擎，并统一了 SQL 入口，简化了整个数据处理链路。这种设计进一步提高了 Fintech 业务的开发敏捷性，无需了解底层数据分布或数据管理这样复杂的工作，只需要通过标准的 SQL 完成业务代码的开发，加速了整个产品的持续迭代能力和速度。\n\n此外，面对越来越大的数据量，TiDB 拥有良好的水平扩展能力，可以自动实现各个集群节点之间的均衡，针对 Fintech 行业的数据业务增量提供了很好的支持，可以促进整个 Fintech 行业的业务发展。同时，它核心的事务特性、高可用性和可靠性也为 Fintech 业务的发展提供了很好的保障。除此之外，TiFlash 这种列存、MPP 并行处理加速的框架设计，也能够帮助 Fintech 相关场景基于实时数据为其用户提供及时的业务决策或增值服务。\n\n## TiDB 在 Fintech 行业的应用和实践\n\n![Fintech 场景.png](https://img1.www.pingcap.com/prod/Fintech_b7e9d0e4de.png)\n\nTiDB 作为一款高效稳定的开源数据库，在国内外的银行、证券、保险，以及在线支付、金融科技等行业中都得到了非常普遍的应用。它的应用场景非常丰富，包括核心的交易支付、交易支付相关的查询、在线数据服务，以及实时风控、反洗钱、反欺诈、财务对账、清结算等。下面通过四个典型场景案例，来进一步介绍 TiDB 对 Fintech 场景提供的业务价值。\n\n### 在线数据服务\n\n在线数据服务是 Web3 行业中的典型业务场景。以 Web3 在线数据服务为例，相关业务发展带来了对应的业务挑战。首先是这个行业存在大量的数据倾斜，这与其本身的数据特征相关，这使得水平和垂直分片变得非常困难。此外，像 NFT 这样的在线数据服务场景下，需要高实时、高并发和高吞吐的业务请求响应。同时，它对延时的敏感性也很高，且非常注重用户体验。\n\n以以太坊为例，其数据量已经超过 10TB，每天还以 100 万笔交易的速度在不断增加。因此，对整个 Scale 的要求也非常高。在整个查询行为上，查询类型非常多样且复杂，包括简单的数据过滤、索引查询，以及聚合类查询和多表场景。同时，因为是一个在线的数据服务，其对实时数据分析也有一定的需求，要求系统提供 7×24 小时在线服务。\n\n针对在线数据服务的业务需求，需要数据库具备实时获取数据的能力，满足低延时的诉求，同时要求数据库具有高可用性。在传统解决方案中，数据处理的链路非常长，数据需要经过前端业务存储到关系型数据库，再进行 ETL 存储，最终放到数据服务层，向业务方提供查询。这种传统解决方案架构非常复杂，损失了数据时效性，并且在高并发访问、表关联等方面也存在缺陷。\n\nTiDB 的特性可以很好地解决在线数据服务所面临的这些挑战。一方面，TiDB 的扩展能力非常强大，计算节点和存储节点都可以进行动态扩缩容，能够应对高吞吐、高并发场景。另一方面，TiDB 高可用的架构设计能够最大程度保证前端业务访问的连续性。此外，HTAP 的能力可以在简化技术栈的同时保证数据的新鲜度，使得前端业务在使用 TiDB 时，整个业务数据的新鲜度非常高。\n\n![NFTScan TiDB 场景示意.png](https://img1.www.pingcap.com/prod/NFT_Scan_Ti_DB_0948ad8e96.png)\n\nNFTScan 是一家多链 NFT 数据基础设施服务商，为 Web3 用户提供高效简洁的 NFT 资产搜索查询服务，为 Web3 开发者和新一代金融科技公司提供专业的 NFT API 数据服务。NFTScan 使用了全托管 TiDB Cloud ，满足其 Web3 行业的场景需求。在使用 TiDB Cloud 前，NFTScan 的 NFT 数据链路是从链上获取数据，然后对数据进行过滤，并将 NFT 相关的数据分别存储到 RDS 和 ES 中。这两种数据存储产品分别用于提供 C 端、B 端以及内部运营分析等三类业务查询。使用 TiDB Cloud 后，在数据存储这一侧只存储了一份数据，即全部数据都存储在 TiDB 集群中。这意味着，NFTScan 通过 TiDB Cloud 简化了整个技术栈。在进行业务开发迭代时，不需要同时适配 RDS 和 ES，也不需要了解这两种数据存储产品。相应的业务开发只需要通过一种标准的 SQL 语句就可以完成业务迭代。因此，用户在业务的敏捷性和迭代速度上得到了进一步提高。\n\n另外， TiDB Cloud 在高可用方面，天然支持跨 AZ 部署，能够提供跨 AZ 高可用的能力。在云上的场景下，计算和存储节点可以按需扩容，这能够进一步支持客户的业务增长。目前，NFTScan  使用 TiDB 存储了大约 6TB 的业务数据，QPS 达到 5000，平均查询时长 40ms，各种应用在 TiDB 上运行稳定。\n\n### 多源汇聚+实时对账\n\n目前整个金融科技行业正在向单元化和服务化方向发展。因此，业务数据会根据不同的业务属性进行拆分，这意味着数据是分散且成熟的。为了实时查询和分析这些数据，可以使用 TiDB 作为多源汇聚层，支持对账、收益分配、损益展示等业务。\n\n![TiDB 多源汇聚示意.png](https://img1.www.pingcap.com/prod/Ti_DB_4e54bd20b0.png)\n\nTiDB 高度兼容 MySQL 生态，官方提供了数据库管理工具 DM，用户可以使用它完成整个上游到下游 TiDB 数据的实时同步。除此之外，TiDB 也提供了多种数据接入方式，可以将上游业务数据（如客户中心、产品中心等）以统一全局维度 1：1 进行入库。同时，如果上游已进行分库分表，TiDB 也可以使用 DM 完成合库合表的操作，将分散的数据在 TiDB 汇聚成一个全局的汇聚库。\n\n在多源汇聚的场景中，TiDB 对汇聚查询也有着天然的优势，用户不需要接入新的技术栈，只需要保持 SQL 技术栈就可以完成复杂的任意维度的分析查询 。这意味着 TiDB 可以在汇聚库上完成跨服务单元的后台数据批量操作，包括复杂的查询和报表类查询。同时，在整个业务中，原来共享的库仍然是以逻辑单独库的形式存在于 TiDB 的大集群中，提供服务。由于存储规模天花板相对较高，TiDB 的存储和计算能够通过不断加入节点进行横向扩容。\n\n在实时数据汇聚场景下，TiDB 有一个 Web3 用户案例。该用户在使用 TiDB 前，由于其业务特性要求，数据分散存储在 RDS 上。随着需求增长，用户需要提供 toC 类的损益分析、查询和内部运营分析。因此，客户使用 TiDB 的 DM 产品通过解析 Binlog，实时将上游业务库的数据汇聚到一套 TiDB 集群中。随着业务规模的不断增长，该集群最终规划的集群大小达 100TB。此外，TiDB 还能够同时支持 C 端和运营分析类查询，保证了数据服务的全面性。整个数据的时效性和新鲜度也非常高，无论是 C 端用户还是内部运营分析人员，看到的数据都是实时展示的。\n\n### 核心支付\n\n在第三个场景中，TiDB 主要涉及支付领域，例如商业银行的联机交易和第三方支付公司的移动支付等核心业务系统。通过使用 TiDB，可以为用户提供大规模吞吐量、高并发联机交易、多中心、多数据容灾以及弹性扩展机制。此场景的特点在于对安全性、稳定性和可靠性的高要求，需要提供分布式计算、分布式数据库管理和在线扩展的能力，并具备高并发、低延迟和大吞吐量的数据处理能力。由于它是一种类似于联机交易的支付场景，因此对整个事务的要求和数据一致性要求也非常高。\n\n传统方案中，为了解决业务需求，通常会采用分库分表架构。然而，传统 MySQL 分库分表架构也存在一些问题。分布式中间件对应用程序的侵入度较高，这意味着整个应用需要进行较大的改造和调整，相对来说比较复杂。一旦采用分库分表架构，应用模型和数据模型都会变得相对固定，从而牺牲了灵活性。由于支付场景对事务的要求很高，而引入分片这样的中间件解决方案在分布式事务方面的能力相对较低，需要在应用开发方面进行调整和适配。此外，采用分库分表后系统的弹性扩展和在线扩展能力也必然会受到限制，主从模式的高可用架构存在风险。在业务高峰期，无法完全避免主从之间数据同步的延迟。一旦数据库出现延迟，整个高可用架构和容灾能力都会下降。\n\n![TiDB 与分库分表对比.png](https://img1.www.pingcap.com/prod/Ti_DB_5eee6a96ee.png)\n\n面对这些问题，通过 HTAP 数据库 TiDB 可以迎刃而解：\n\n首先，TiDB 的使用方式近似于传统单机数据库的访问方式，对整个应用的访问是透明的，无论是应用模型、数据模型还是整个事务的交易模型，无需人为切割。在整个核心交易支付场景中，也无需指定 Sharding key，不会限制后续数据查询的灵活度。\n\n同时，TiDB 的多中心多活容灾机制能简化整个部署的复杂性，无需管理十几套甚至数十套主从模式的集群。它完整地支持了整个分布式联机交易的事务，无需应用提前规避和处理。\n\n此外，TiDB 还提供了一个动态调度机制，使在线扩容节点时完全不会影响业务，后台会自动进行数据均衡。\n\n在该场景中，有一个日本顶尖的支付应用公司将 TiDB 应用在核心支付场景的案例。该客户在 2019 年 10 月上线了第一个 TiDB 集群。截至目前，客户的 TiDB 集群主要应用于支付和钱包等核心业务，涵盖支付查询、支付流水管理、钱包余额和钱包返现等功能。\n\n在使用 TiDB 之前，该用户的架构基本上是使用主从模式的 RDS。这使得其无法随着业务增长在容量和吞吐量方面得到很好的支持。此外，该移动支付客户还需要应对一些大促销带来的动态扩展需求。在这样的核心场景下，不希望出现主从同步延迟和高可用性降级问题。为解决这些问题，客户考虑到 TiDB 首先是兼容 MySQL 的，因此相对于业务改造和迁移，工作量较低。此外，随着数据量的大幅增长，不需要采用分库分表方案，应用逻辑相对简单，且读写均能水平扩展。\n\n在同类业务场景中，TiDB 有许多成功案例。考虑到这一点，该用户决定将支付核心业务迁移到 TiDB 集群。结果显示，在迁移后，整个系统的吞吐量提升了三倍。\n\n### 实时风控\n\n最后一个场景是实时风控，它在金融科技行业中扮演着重要的角色。实时风控需要整合各种业务提供的能力，包括征信、额度和反欺诈等，以提供企业级的统一风控入口。随着业务的发展，实时风控的要求也不断提高。例如，针对关键应用数据，需要同时具备实时数据分析的能力，以对交易流水、反欺诈和决策分析等实时数据进行批量处理。\n\n在过去，实时风控在数据链路处理这一侧的链路相对较长，涉及到的数据库品类也非常多，限制了其扩展能力。此外，无论是在数据链路还是数据服务这一侧，都存在限制。在数据链路这一侧，由于链路较长，数据处理变得复杂。在数据服务这一侧，数据被存放在多个地方，因此在灵活性和扩展性方面做出了一定的牺牲。在实时风控的场景下，通过将 TiDB 与传统的大数据生态技术栈（如 Flink 和 Kafka）结合使用，可以显著提高数据价值获取的能力，不管是作为单独的实时数据分析处理引擎，还是传统的大数据技术栈，这也意味着整个数据链路处理侧相对简单。通过流式的方式实时接入客户行为和反欺诈等数据，然后利用 TiDB 的 HTAP 能力进行实时的数据分析聚合。最终提供统一的 API 支持高并发查询的能力。\n\n![TiDB 实时风控场景示意.png](https://img1.www.pingcap.com/prod/Ti_DB_b85da2d0ca.png)\n\n在这个场景中，典型的客户案例是互联网银行。在使用 TiDB 之前，互联网银行客户面临了许多问题。他们的数据分散在不同的数据库中。为了处理风控指标，需要查询不同的数据源，然后进行汇总处理。但随着业务增长和需求变化，原先的技术栈 MySQL 出现了性能瓶颈。此外，MySQL 在实时分析场景的性能相对较差。基于这些考虑，客户在在线风控场景下使用 TiDB 替换原有技术栈。使用 TiDB 后，整个技术架构发生了变化。业务前端的数据，包括交易、用户行为、征信和身份认证等数据，通过 CDC 实时同步到 TiDB 集群中，大数据相关的风控指标则通过 ETL 进行抽取。最终，通过实时获取和分析，使用统一的 TiDB 数据库完成了在线风控和反欺诈业务流程。\n\n## 总结\n\n本文主要介绍了 TiDB 在在线事务处理（OLTP）场景、实时数据聚合和分析场景下的解决方案。除了在 Fintech 行业得到广泛应用外，TiDB 所具备的能力和价值也在许多互联网客户中也得到了应用。目前，全球已经有近 3000 家企业客户使用 TiDB，覆盖了电商、智能制造、物流和游戏等领域。\n\n![TiDB 用户示意.png](https://img1.www.pingcap.com/prod/Ti_DB_c779e1447a.png)\n\n\n","date":"2023-03-30","author":"高振娇","fillInMethod":"writeDirectly","customUrl":"building-a-new-generation-data-service-platform-for-fintech","file":null,"relatedBlogs":[{"relatedBlog":{"body":"> 本文转载自公众号：韩锋频道（hanfeng_channel）  \n> **作者简介**：韩锋，CCIA（中国计算机协会）常务理事，有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验；曾担任多家公司首席 DBA、数据库架构师等职，在云、电商、金融、互联网等行业均有涉猎；精通多种关系型数据库，对 NoSQL 及大数据相关技术也有涉足，实践经验丰富；曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。\n\n作为数据基础设施的重要组成部分，数据库在其中扮演着重要的角色。近些年来，数据库整体发展也呈现出较之以往很大的不同。 \n  \n其一是开源数据库受到更为广泛的关注，从多家机构的最新报告来看，开源数据库无论从产品数量还是受关注程度都超过商业数据库。开源这一新模式，正成为未来数据库发展的主流。  \n\n其二是云计算成为未来主要资源供给方式得到普遍共识。已经有越来越多的企业选择在云上构建基础环境，包括云上数据库的发展速度也远高于非云环境。据乐观估计，在未来 5~10 年云数据库将占据整体数据库市场的七成以上。此外，对迁移到公有云、使用多云环境等问题，也普遍被企业所接受。  \n\n其三是数据融合趋势，针对数据多场景应用，使用融合技术简化访问，提升效率。作为数据使用高地，金融行业一方面对数据库有着极高的要求，一方面又面临很多来自数据新的挑战，诸如海量规模、高并发、数据安全、实时分析等诉求亟待解决。分布式数据库的出现，迎合这一发展趋势，对于金融企业解决上述问题带来新的解决思路。  \n\n本文从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行阐述。\n\n ## 金融业数据库选型背景\n\n随着企业数字化转型深入，对于数据使用场景也呈现多元化趋势，正有越来越多数据被企业利用起来。金融行业作为数据库应用“高地”，这一趋势表现更为明显。同时我们也看到，近些年来数据库领域也发展迅速，有分布式数据库、多模数据库、云数据库为代表的产品不断涌现。这些新兴数据库在特定场景有很好的使用前景。基于上面两种趋势，金融行业很多企业都在面临选择数据库的问题。\n\n### 选型技术层面要素分析\n\n从技术角度来看，在数据库选型中有哪些要素需要考虑呢？下面以近期比较关注的分布式数据库的选型为例，说明下重点考量的技术要素。\n\n**分布式事务**\n\n分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。\n\n**性能**\n\n由于分布式数据库通常使用的二阶段提交和各节点之间的网络交互会有性能损耗，分布式数据库优势不是单个简单 SQL 的性能，而是大数据量的 SQL 查询，每个节点会将过滤之后的数据集进行返回，会提升性能，并且分布式数据库的优势是并发，大量的 SQL 并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的 SQL 语句的事务，OLTP 类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。建议尽量改造存在跨节点数据流动的 SQL 语句（主要是多表关联）的事务。\n\n**数据备份**\n\n分布式数据库的一致性保证通过内部时钟机制所提供的全局时间戳，所有节点都会遵循该机制，所以备份恢复的增量也是基于全局时间戳，但是分布式数据库的备份解决方案最重要的标志为是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐大很多，还有就是是否支持一些分布式备份方案，比如 S3 协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候指定节点进行恢复到指定时间点，整个过程可配置自动任务、自动执行。\n\n**高可用**\n\n分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署。如果同城主备可以采用集群级的异步复制，异地建议采用集群级的 binlog 异步复制，建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件 T+1 恢复到异地灾备。\n\n**数据一致性**\n\n分布式数据库大多都是通过获取全局时钟时间戳，采用二阶段提交，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。部分分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。\n\n**数据分析**\n\n分布式数据库，多采用存算分离架构。针对数据分析场景，需要对数据从下层存储节点上移到计算节点，这对分布式数据库提出了更高的要求。一方面可通过算子下推等技术，减少需传输到计算节点的数量；一方面针对汇聚后的结果需要通过流式处理等方式，规避诸如 OOM 的问题；此外也可采用如 MPP 等并行处理技术，加速数据分析过程。\n\n### 选型过程问题痛点分析\n\n在选型过程中，会遇到来自以下几方面的痛点。  \n\n- 由于分布式数据库整体架构还比较新，也是近十年来逐步发展完善的。针对新型架构的诸多特点，包括厂商和用户还都在不断摸索积累之中，还需要有个长期实践的过程。此外，新架构也需要有个逐步成熟完善的过程。\n- 大量产品来自国内数据库厂商，其发展周期相对较短，还需要在产品成熟度、稳定性、周边生态等方面不断完善。对于用户来说，一方面需面临产品多、技术栈多的现状；另一方面还需面对成熟度不足等问题，存在较多痛点。\n- 近些年金融行业发展迅速，各种新的业态产品不断涌现，这些对作为底层数据基础的数据库也提出了更高的要求。\n\n## 数据库选型技术架构\n\n### 分布式路线分析\n\n针对分布式数据库的发展路线，大体可分为两种：\n\n**分布式中间件**\n\n这种架构是从中间件路线演进而来。其采用存储与计算分离架构，底层采用标准单机数据库，副本间基于数据库主从复制机制。上层承担计算，并可将部分计算下推到存储节点执行。这种架构在分布式事务、全局 MVCC 等方面，往往存在一定难点，各厂商也有各自解决之道。\n\n**原生分布式**\n\n这种架构正是受到 Google 论文影响演进而来。其采用存储与计算分离架构，底层采用单机库(不一定是关系型)，副本间采用分布式一致性协议完成复制，支持多数派提交。上层承担计算，并可将部分计算下推到存储节点执行。\n\n### 重点需求满足情况\n\n针对上述遇到的痛点，两类产品实现逻辑也所有不同：\n\n![001.png](https://img1.www.pingcap.com/prod/001_ce42a10ada.png)\n\n\n### 路线场景分析\n\n从数据使用场景来讲，可大致按下面进行划分：\n\n![002.png](https://img1.www.pingcap.com/prod/002_1f9a938e7e.png)\n\n针对不同的场景，不同分布式数据库路线产品各有所长。\n- 针对事务类场景下，强调高并发联机交易、对分析能力要求不高的场景比较适合分布式中间件路线产品。\n- 针对事务类及事务/分析混合类场景，既要满足常规联机交易场景的同时，还需满足分析类的一部分能力，这种情况比较适合原生分布式产品。基于原生分布式的 HTAP 数据库，用一个数据平台应对规模化交易和实时分析，提升业务决策的时效性，降低数据技术栈的复杂性，越来越多的混合负载需求推动了 HTAP 在金融场景的落地。\n\n## 金融业 HTAP 应用场景实践\n\n### 金融场景下 HTAP 的分析\n\n在金融企业数字化转型的过程中，各类业务对“海量、实时、在线”的数据需求变得愈发迫切。在金融企业运营场景中，实时推荐、精准营销是企业提升竞争力的一大因素。在企业风险控制场景中，实时风控、反欺诈等业务开展可以更早地识别和阻断风险可以让企业减少损失，HTAP 正是基于上述背景诞生出的需求，为各类实时数据处理需求提供了解决方案。\n\n### 某金融用户 HTAP 的架构设计和实践\n\n随着金融市场同业业务的蓬勃发展，业务部门对于交易数据的实时统计分析和展现有了急切的需求。基于大数据技术栈的 T+1 报表模式，已无法满足业务部门通过实时分析交易发生情况来防范风险以及提供决策的需求，迫切的需要找到一种能让数据实时变现的解决方案。结合金融行业特点，在技术选型过程中，重点考察待选产品如下能力：包括承载业务复杂查询处理、海量数据容量存储、应用透明无侵入、开发协议可适配及混合负载下的表现等。经过测试，选择 TiDB 作为基础数据库平台。基于其 HTAP 的特性，打造金融市场实时数据平台，目前已投产了灵活报表和交易对手分析等应用场景。整个处理流程包括：  \n\n- Flink 消费交易系统产生的实时增量数据，对部分事实表进行拉宽处理并写入 TiDB\n- 维表和其他明细表直接写入 TiDB\n- BI 工具直接连接 TiDB，提供秒级的实时计算和分析能力\n\n![003.jpg](https://img1.www.pingcap.com/prod/003_a89e399f30.jpg)\n\n这一案例中，构建千万及以上数据规模、超过五张表的复杂关联实时查询能力，让业务人员在极短的时间内（大部分报表执行时间为几十到几百毫秒、个别报表秒级别）获得实时交易的详情。\n\n### 未来 HTAP 的场景发展\n\n实时数据处理技术还以某些具体的应用场景为主，从现状来看以事件驱动类、流式管道数据计算类为代表的场景，已经开始使用 HTAP 场景的。未来随着 HTAP 计算能力进一步的提升，实时全量数据的计算将带来更多场景。\n\n## 面向未来的架构趋势\n\n### 云原生\n\n从未来的发展趋势来看，云方向是一个大的趋势。\n\n![004.png](https://img1.www.pingcap.com/prod/004_be9d5cac08.png)\n\n从上图可见，云数据库的发展经历了几个阶段，从云托管、云服务、云原生之路。  \n\n- **云托管**，是最接近传统数据库系统的部署模式。本质是将原本部署于 IDC 机房内物理服务器上的传统数据库软件部署在了云主机上。这种模式下，云平台提供诸如高可用、异地灾备、备份恢复、数据安全、SQL 审计、性能优化和状态监测等企业级数据库管理能力，用户可减少运维投入即可享受之前同等的服务水平。\n- **云服务**，之前的托管架构中，受限于传统数据库架构的局限，未能完全发挥云计算的优势。在诸如弹性扩展、高性能、高可用等方面，均有不足。到了云服务时代，充分利用云基础设施的底层能力，提供定制化的数据库产品。\n- **云原生**，与之前的云服务架构不同，这一阶段产品将更为充分地利用云基础设施的能力，通过多层资源解耦，可享受云带来的弹性扩展、按需供给、超大规模能力。真正做到了数据库与云的深度结合。从长期来看，金融机构逐渐把业务和技术向云原生演进，实现传统应用迁移上云和云原生改造是重要的方向。在这个过程中需要考虑分布式数据库对 K8s、微服务应用的支持，提供高效、弹性调度能力，同时需要兼顾开发运维和敏捷度。\n\n### 多云方向\n\n云作为未来主流的资源供给方式，多云必然是企业不得不考虑的问题。多云通常指金融机构同时采用多种不同的云环境组合来满足业务需求的多样性和金融业监管的要求。如何围绕数据打造面向未来的多云 IT 架构，满足在多云之间提供数据服务能力，摆脱单一供应商的弊端，是必须考虑的问题。多云架构对分布式数据库的考察重点聚焦于跨地域、跨公有私有云、跨本地 IDC 和 K8S 的部署、服务提供与统一运维能力等。","author":"韩锋","category":5,"customUrl":"distributed-database-selection-and-htap-practice-in-financial-industry","fillInMethod":"writeDirectly","id":388,"summary":"本文转载自公众号：韩锋频道（hanfeng_channel）。文章从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行了阐述。","tags":["分布式数据库","HTAP","TiDB"],"title":"金融业分布式数据库选型及 HTAP 场景实践"}},{"relatedBlog":{"body":">作者简介：余军，PingCAP 解决方案事业部总经理。\n\n对于金融企业来说，尤其是银行、证券、保险这些行业，在一个 IT 系统运行支撑业务的过程当中，考虑到硬件的故障、网络的故障，等一切可能会对业务产生影响的突发故障。那么，在过去漫长的 IT 发展的过程当中，大量的技术被应用在关于如何解决组件级的高可用，整个服务的容灾和灾备，包括如何保证整体业务的连续性。\n\n在金融行业来说，数据库作为最核心的基础组件之一，要求它能够安全运行和保障数据安全，这是一个刚需。另外，数据库服务本身的高可用，是我们实现整个对外数据服务连续性的最重要的基石。在这些基础上，光有高可用还是不够的，我们需要考虑到机房级的、数据中心级的、站点级的灾难导致的对业务的影响。配套的容灾技术，以及对应事件的方案，应运而生。在过去的二、三十年里面，关于容灾和技术的技术手段、软件工具，包括各种各样的方案、管理方法，在不断的展现。\n\n## 传统数据库支撑关键计算的高可用/容灾方案短板\n\n回到传统的数据库领域，在过去至少三四十年的时间里，我们都是在使用集中式的数据库，比如大家非常熟悉的 Oracle、DB2 包括曾经很辉煌的 Sybase、Informix 等等。这些数据库都是以大家所熟知的“ IOE”的架构来实现数据服务的。\n\n在这些技术体系下，在长期的技术发展过程当中，也有产生对应的高可用和容灾的方案，比如说大家非常熟悉的 Oracle RAC，比如说我们在 DB2 上，经常会用到的 HACMP，还有曾经大名鼎鼎的 Veritas VCS，MC/SG，以及红帽的 RHCS , Pacemaker/Corosync 等实现单机数据库高可用的。\n\n这些技术都是通过数据库，建主从的实例，然后共享数据库的数据文件，放在高端的数据的存储上。这种集中架构的话，它总体是比较稳定的，但是随着 IT 应用场景的不断发展，到今天为止，我们在考虑数据库的时候，除了要考虑它的可靠性之外，还需要考虑它如何应对海量的数据处理，海量的并发请求。**那么我们需要必须寻求扩展，而集中式的结构，它没有办法做横向扩散。此外的话，这种传统的数据库的高可用方式，非常依赖于外部的组件，就是前面说的这些独立的厂商提供的相关的高可用和容灾组件。**\n\n进入到开源数据库的阶段，大家所熟知的 MySQL 和  PostgreSQL，它们也会有对应的高可用的解决方案，比如 MySQL 它最常见的就是通过它的 Binlog 复制建立起来主从队，然后在数据库之外，我们采取类似像 MHA 这样的一个 SwitchManager 的工具，包括 PG 的话，它有 PAF、RepMgr、Ptroni 这样的技术。\n\n**在这样的技术场景中，其实在可用性和容灾方面，还是有很多的问题**，比如说复制的时候的采用的异步复制，增强的半同步复制以及国内好多互联网公司定制的 MySQL，PG 的同步方案，在多节点，跨地域容灾灾备场景中的一致性的问题，始终是一个很大的挑战。特别是在容灾的场景当中，超过 1000 公里以上的站点距离间隔，用上述复制的方式，用独立的 SwitchManager 的故障切换机制，是不是能够保证在千公里以上的容灾的可靠性是很大一个疑问。\n\n**此外，主从复制的模式资源利用率比较低**。到现在为止，我们还有在主从复制基础上，再往前走一步，提高高可用性的一些保障机制，比如说大家都熟知的组同步，像 Codership 之前做的 Galera，像包括 MariaDB Galera Cluster 和 Percona XtraDB Cluster，都把 Galera 组件放在产品当中。包括现在 MySQL 新版本中的复制技术实现了组同步 MGR。但是这些方向又有它的问题，比如说它的性能损耗非常显著，然后在多写场景的冲突的处理复杂性，以及整个集群的扩展规模，受到这样的限制。\n\n## 分布式数据库备份容灾的挑战\n\n所以，从单机数据库进入到分布式数据库的领域，问题的挑战就更加大了。集中来看的话，就是比如说我们最常见的两个传统的分布式的数据库的架构：MySQL、PG 加上主从复制核心组件，再加一个高可用的外部组件实现 Failover/Switchover，然后再加分库分表中间件。那么这样的方案，在传统的分布式架构当中，它的核心的可用性的技术限制和天花板没有变化。它还是如前文所说的：主从复制加上一个数据库外部组件实现 Failover/Switchover 。\n\n**然后，在分布式数据库架构里，我们需要非常认真的去考虑，分布式数据库的伸缩能力和它怎么样去跟高可用及容灾的要求达到平衡。甚至还要想怎么样再去做进一步的优化，这是比较困难和有挑战的。**\n\n另外，在互联网应用场景中， 访问量和数据量非常的大，业务逻辑相对简单。**但是在银行、保险、证券等这样的传统关键金融场景当中，业务的逻辑是非常复杂的。针对于这样的传统高可用及灾备容灾方案，它与应用进行适配，往往要做一些面向应用的反向适配，应用还需要为此进行调整与妥协**。比如说两地三中心的场景当中，应用适配的难度更加大，所以改造过程当中的适配过程和反向适配的风险，也是一个经常让金融行业的 IT 从业人员非常头痛的一件事情。\n\n最严峻的一个事情，当在这样的传统灾备容灾方案为基底的一套系统在运行的过程当中，真的发生了非预期的重大故障和灾难突发的时候，怎么样保证数据的严格安全，以及如何保证在故障发生以后，对于部分组件，对于机房级的灾难，对于中心级的灾难，在灾难发生的时候，要保证对业务的最小影响，也就是我们经常听到的，RPO 和 RTO 这样的要求。那么在这个过程当中，怎么样最大程度减少人工的干预？因为，**在灾难发生的时候，人的干预是必须的，但是人的反应也是比较迟钝的。所以，怎么样通过一个技术手段，在整个方案的能力上，能够去高效执行灾难恢复的处理工作？**\n\n## TiDB 的金融级备份及容灾之道\n\nTiDB 经常这么多年的积累和逐渐完善，在整个分布式数据库的容灾和灾备的领域，我们达到了金融生产级的要求。那么在整个 TiDB 的备份与灾备、容灾的体系里，我们主要是由以下几个方面来组成的。\n\n![1-TiDB-金融级备份及容灾之道](https://img1.www.pingcap.com/prod/1_Ti_DB_6ddab9cf1a.png)\n\n**第一个是我们默认的，也是我们推荐的，多中心的容灾方案，同城的两中心，异地的一中心，或者扩展到三地五中心模式**。这个方案也是 TiDB 最早原生的核心方案。通过多级标签的感知，能够实现服务器级、机架级、机房级、站点级的故障转移。能达到 RPO 等于 0，以及我们的故障影响时间小于 30 秒，也就是 RTO 小于 30 秒的一个刚性指标。\n\n这一套方案，目前我们在国内和国外，已经有了不少用户，尤其是金融行业的用户，在关键场景投产使用了。这其中也是经受过了很多的考验，比如说，同城光纤的抖动，同城到异地之间的通讯线路出现问题，以及机房里面多个节点同时出现了故障，随着在生产环境上持续运行时间的变长，这些问题都暴露出来了。通过 TiDB 的多中心的容灾方案，非常可靠地避免了这些故障对业务的影响，保障了业务连续性及数据安全。\n\n除此之外，在国内的话，从北到南，我们的运营商的线路也是非常的复杂。对于有些用户来说，从投资成本、业务的重要性、客户网络的物理条件来说，没有办法去构成同城多中心加异地的的容灾架构，他可能只能选择两中心的方案，那么在这个过程当中的话，TiDB 经过这几年对这个方面的积累，我们现在已经有了**两中心的容灾方案**，并且，在这个方案里面，我们有多种配置来适应不同的网络条件。即便是在两中心方案当中，我们也能达到 RPO 等于 0 的保护模式。当然也有一些用户的场景，他的网络线路可能延迟非常高，且用户要求有一个托底的容灾方案，同时对于数据的一致性可以有略微的放松和让步，在这个过程当中，**我们也会通过配置来为其提供异步同步的模式，来帮助其实现托底的容灾方案，最大程度保障服务的连续性和数据安全。**\n\n以上是我们交付给用户的多种金融生产级的灾备容灾的方案，它背后的支撑是由核心的 **TiDB 的 Multi Raft 的高可用机制**，以及一系列针对跨中心的调度、数据的调度管理、故障的自动转移判断等这一整套后台的保障技术机制来实现的。\n\n另外，对于数据业务来说，除了在线的热的故障转移、切换等。我们对于数据库的数据本身，也提供了完善的数据备份方案，除了全量的备份、增量、恢复时间点 (PITR ) 之外，**我们在数据的备份模式上面，也提供了包括基于日志的传统逻辑备份。并且，在去年我们也推出了 TiDB BR 工具和备份方案，直接从数据库的 TiDB 存储引擎 TiKV 层上，直接实现备份和恢复，备份与恢复非常高的效率。**\n\n但光有上述方案是不不够的，PingCAP 对于自身产品的要求是非常严格的，既然是要达到金融生产级的要求，除了要有对应的技术方案、对应的技术实现之外，必须为产品本身提供专业的分布式测试的体系和手段。每一个 TiDB 的版本，在我们的内部，都会通过极其严格及复杂的分布式数据库测试。为此，我们也专门根据混沌工程，设计开发了自己的一套测试平台，并且在最近把它开源了，这套工具叫做 [Chaos Mesh](https://pingcap.com/blog-cn/chaos-mesh/)，可以帮助用户更好的检测分布式系统的可用性和鲁棒性。\n\n在 TiDB 内部测试的整条链路上，我们有非常完善的对于可靠性和一致性和安全方面的测试保障。包括自动化故障注入，包括我们引入的 Jepsen 的一致性验证，包括我们对于一些最核心的算法，引入了 TLA+ 的验证。还有我们每天在数据中心，在我们测试环境，不停跑的自动化模拟的业务负载以及各种各样的集成测试。我们相信只要是人写出来的软件，一定是会有问题的，一定会有 Bug，不可能做到完全没有问题。**所以，在这个过程当中，需要的保障手段，除了高可用和软件架构本身设计的机制之外，先进的、完善的、强大的产品测试体系和可靠性 验证能力，也是最重要的保障手段之一。**\n\n## TiDB 灾备与容灾的核心机制\n\nTiDB 容灾的核心机制是我们的 Raft ，相信各位关注 TiDB 的朋友也通过我们的公众号、官网，包括社区里面，听到过小伙伴们提供的分享。Raft 是基于日志与状态机的一种一致性的算法。我们基于它，在 TiDB 里实现了 Multi Raft 的机制。它能够非常可靠的管理我们的数据与数据的副本，在 TiDB 里面，整个数据对我们的业务来说是自动的透明打散的，然后它会以一个一个 Region 的数据组织方式，在不同的存储节点上面进行自动存储和建立 Raft 副本。\n\n通过 Multi Raft 这样的一个机制，我们可以在不同的主机，不同的机房，不同的园区，一套数据库不同的节点上，产生它的第二、第三副本，甚至更多的副本。这个副本是动态可调的，并且我们可以保证，TiDB 上执行的所有的联机交易事务，在数据变更发生时都可以达到多数的一致，**也就是说在一个实施规划和部署正确的 TiDB 集群里面，在一个多中心的灾备容灾 TiDB 集群中，任何的主机，所在的机架、机房，乃至数据中心的失效，包括数据中心间的网络故障，通过 Multi Raft 机制以及 TiDB 的高可用调度机制，都可以完善的去保障，对我们的业务影响最小，同时，非常严格的保证了数据的绝对安全。**\n\n在 Raft 这个机制上，TiDB 的研发团队也做了大量的优化工作。比如说跨数据中心，包括跨区域的运维方式。另外，我们在 Raft 机制上面，也提供了很多的比如说新的一些增强化，像 Lazy Peer、像 Learner、像 Joint consensus 等机制的研发。\n\n## TiDB 高性能分布式备份机制\n\n刚刚我还提到一个叫 [TiDB BR](https://pingcap.com/blog-cn/cluster-data-security-backup/) 的工具，它是一个在存储层实现高性能分布式数据备份恢复的工具。所以，大家由下图可以看到，我们的测试中的备份速度、恢复速度，都是非常惊人的。而且随着节点数量的增加，在数据量一定的前提下，备份/恢复的性能都会有接近线性的增长：\n\n![2-TiDB高性能分布式备份机制](https://img1.www.pingcap.com/prod/2_Ti_DB_875ad97021.png)\n\n\n## 最强的多中心：TiDB 多中心多活容灾方案\n\n在多中心里面，前面提到，我们通过 Multi Raft 的机制，以及相关的工程优化，实现了跨中心的容灾方案。比如说，对于长距离的异地中心，我们在同城设了两个中心，通过光纤连接，异地的话，通常租用比如运营商的 MSTP 类型的线路，构成一个三中心的结构，通过 TiDB 内置的容灾和灾备的相关的一系列的机制与手段，可以构建出非常强健的容灾的架构。**任何中心级失效，都会由另外两个中心来立刻进行故障的转移，以及对外继续提供正常的数据库服务。**\n\n\n![3-TiDB多中心多活容灾方案](https://img1.www.pingcap.com/prod/3_Ti_DB_36dac4fe16.png)\n\n\n## 安全的两中心：TiDB 两中心容灾方案\n\n前面也提到，有些用户的网络，比如说一个中心在上海，一个在北京，延迟是非常大。因为高等级、低延迟线路的租用使用成本非常高。综合考虑成本及所需要保护的业务的关键性等级，不少用户会做一个权衡。部分用户最终希望核心数据库，只需要完成一个主从站点的容灾和灾备就可以了。\n\n通过 TiDB Binlog 模式能够去适配和满足对多中心网络通信成本敏感且对服务/数据防护能力略低的容灾需求的用户，我们会用两中心的 **TiDB Binlog based 方案**，它是异步同步模式，能够适配两个中心长距离间隔其网络延迟较大，比如延迟大于 30~40 毫秒的。采纳这样方案的用户对于 RPO 的要求就比较宽松了，该模式是一个异步同步，当灾难发生的时候，我们已经在 TiDB 的工程优化上尽可能通过多种机制来减少数据丢失的可能，但是从根本上来说，还是会存在一定数据丢失的情况。**该方案提供给用户低成本的保障能力，同时还提供了比较灵活的可选拓扑，比如双向的环形复制等。**\n\n也有用户希望在两中心的方案里，需要有一个强一致保障的方案。所以我们研发了两中心的 **Raft based 容灾方案**，它可以在同城或者接近同城距离的两中心环境中，且中心间网络条件比较好的情况下，实现严格的强一致同步。**这个方案可以达到 RPO 等于 0 的保障要求，也就是数据不丢失前提下的一个高等级的容灾要求。**\n\n\n![4-TiDB两中心容灾方案](https://img1.www.pingcap.com/prod/4_Ti_DB_fdf9238a38.png)\n\n## 结语\n\n最后，我们一直持续在花非常多的精力和投入，研究如何让 TiDB 变得更强，更安全，更可靠。能够达到更好的金融级的数据服务的支撑能力水平，依托于我们整个工程研发团队、 QA 测试团队，以及我们所打造和拥有的强大的测试体系、TiDB 产品的容灾灾备一系列高可用及灾备容灾机制，我们能够为银行、保险、证券等金融客户提供完善的、可靠的、放心的、金融级的分布式数据库服务。\n\n\n>本文整理自余军在 [TiDB DevCon 2020](https://pingcap.com/community-cn/devcon2020/) 上的演讲，大会相关视频回顾可以关注官方 Bilibli 账号 [TiDB_Robot](https://space.bilibili.com/86485707) 。","author":"余军","category":1,"customUrl":"tidb-financial-grade-backup-and-multi-center-disaster-recovery","fillInMethod":"writeDirectly","id":5,"summary":"依托于整个工程研发团队、QA 测试团队，以及所打造和拥有的强大的测试体系、TiDB 产品的容灾灾备一系列高可用及灾备容灾机制，我们能够为银行、保险、证券等金融客户提供完善的、可靠的、放心的、金融级的分布式数据库服务。","tags":["TiDB DevCon 2020","备份恢复","容灾机制"],"title":"TiDB 金融级备份及多中心容灾"}},{"relatedBlog":{"body":"TiDB 作为一款高效稳定的开源分布式数据库，在国内外的银行、证券、保险、在线支付和金融科技行业得到了普遍应用，并在约 20 多种不同的金融业务场景中支撑着用户的关键计算。本篇文章将为大家介绍分布式关系型数据库 TiDB 在金融行业关键应用领域的实践。\n\n## 金融关键业务场景\n\n银行的业务系统非常复杂，包括从核心上的账户、账务、结算等业务到外围的各种存、贷、票、汇以及面向互联网场景的各类金融业务。\n\n![1-传统到分布式](https://img1.www.pingcap.com/prod/1_8f8b1a32df.png)\n\n随着科技的发展，整个银行的核心交易系统走在自己的一个演进道路上，从传统的集中式应用结构逐步向服务化、分布式这样的体系在演进。在国内，已经有若干家在科技方面比较领先的银行机构启动了对于核心的改造工作，在他们整个核心交易应用以及背后的数据处理层引入了非常多分布式的技术来支撑他们业务的发展。在未来，整个发展方向会更多的向单元化、服务化发展，并且一些应用支撑的框架，例如云、微服务、未来的 serverless 等，都会逐渐的向核心交易引入。\n\n**分布式核心系统架构对整个数据库有以下几点比较明确的要求：**\n\n- 安全，稳定，可靠；\n\n- 提供分布式计算与分布式数据管理及在线弹性扩展能力；\n\n- 提供高并发，低延迟，大吞吐的数据库处理能力；\n\n- 支持联机交易及批量(日间/终) 批量混合负载；\n\n- 支持核心上的报表和数据报送业务负载；\n\n- 提供可靠和高性能的分布式联机交易事务； \n\n- 需要支持至少达到 “两地三中心” 的双中心多活及多中心容灾保障能力；\n\n- RPO = 0,  RTO 要达到监管及银行科技部门对核心系统的高可用要求；\n\n- 核心业务应用开发/改造难度低；\n\n- 完善与便捷的运维管理能力。\n\n## 现有架构痛点\n\n目前，很多银行采用的核心系统数据库方案主要为传统的集中式数据库架构和基于 MySQL 的分库分表方案，但无论是集中式数据库架构，还是基于 MySQL 的分布式数据库架构，都会存在一些问题。集中式数据库架构主要有以下几点问题：\n\n- 严重依赖专有高端硬件；\n\n- 无法弹性横向扩展；\n\n- 与新一代分布式服务化核心应用架构匹配度低；\n\n- 建设及维护成本高昂；\n\n- DB2 / Oracle 数据库技术锁定；\n\n- 无法利用云计算体系发展成果。\n\n基于 MySQL 的分布式数据库架构也存在以下几点问题：\n\n- 数据库分布式中间件成熟度与可靠性仍需要考验；\n\n- 应用侵入程度高，改造复杂度大；\n\n- 应用模型和数据模型的锁定，牺牲灵活性；\n\n- 批量负载处理能力限制；\n\n- 分布式事务能力低下，需要人为应用开发侧和规划侧深度规避；\n\n- 强一致性保障的风险；\n\n- 缺乏弹性扩展能力和在线扩展自动平衡的能力；\n\n- MySQL 高可用技术的风险；\n\n- 两地三中心同城多活复杂度。\n\n## 基于 TiDB  HTAP 架构的银行核心数据库解决方案\n\n### 方案一：TiDB 核心交易系统支撑架构\n\n第一个是比较直截了当的方案，以 TiDB 作为核心交易库的主库。\n\n![2-多中心批量处理](https://img1.www.pingcap.com/prod/2_3d9356af8b.png)\n\n在这种方式下，整个 TiDB 近似传统单机集中式数据库的访问模式与业务应用开发模式，对应用的访问是透明的。同时，无论是应用模型、数据模型还是整个事务交易模型，不需要做人为的切分。因为在核心交易应用的发展过程中，除了以账户为角度，我们还会以用户视图为角度，因此简单的通过找到用户的账户分片去做切分的话，实际上是牺牲了整个核心交易的灵活性。\n\n另外以 TiDB 作为主库，内置的多中心、多活容灾的机制也简化了部署的复杂性、管理复杂性和成本；并且完全的分布式联机交易事务支持，不需要应用干预和提前锁定事务处理规划，用户基本上在 TiDB 上做联机交易的过程当中，跟单机数据库的使用是一样的；另外 TiDB 在后台提供了一个动态的调度机制，所以在线的进行节点的扩容，完全不会影响业务，无论是后台数据平衡，还是内部引擎之间的负载均衡的自动分配，都是在引擎内部自己做的，不需要用户在应用侧有特别多的关注。\n\n**以 TiDB 作为核心交易库的主库，主要有以下几点价值：**\n\n- 在核心系统数据库侧分布式改造大幅度降低改造难度与风险；\n\n- 业务模型和数据模型无需反向适配数据库架构；\n\n- 透明的计算和数据管理分布式，降低维护复杂度与成本；\n\n- 吞吐量及性能可以随在线横向透明扩展；\n\n- 标准 SQL, 分布式事务，多表复杂关联计算，联机与批量混合负载处理能力，保障业务灵活性及适配分布式核心应用；\n\n- 内核支持强一致数据部分机制及高可用机制 (RPO=0,RTO <30s）；\n\n- 内核支持多中心多活容灾机制。\n\n#### 长亮核心交易系统测试\n\n我们与城商行一级的系统做了比较完整的对接，包括长亮科技，我们在他的核心交易系统上，包括账户、账务、贷款、发卡、现金管理、资产负载等这些核心模块做了充分的适配。\n\n![3-长亮核心交易系统关键交易压测成绩](https://img1.www.pingcap.com/prod/3_f4f453a206.png)\n\n从功能、正确性、交易的性能等方面做了充分的适配和优化，完成了 2000 多个核心交易的功能测试，包括全量的近 200 个批处理测试。接下来，我们正在跟长亮科技计划进行 V8 版本对接测试和基于 ARM 国产化平台的测试。\n\n### 方案二：核心交易 MySQL + TiDB 后置库方案\n\n第二种方案是以 TiDB 作为整个核心交易的后置库方案。\n\n![4-后置库方案](https://img1.www.pingcap.com/prod/4_16bf288ec6.png)\n\n架构如上图所示，整个核心交易的应用侧根据应用逻辑做一个拆分，这也是现在新一代核心应用结构的演进趋势。\n\n用户在核心联机交易库使用 MySQL + 中间件的方式来承担联机交易的前置库，在这上面完成最基本的联机交易，然后通过 TiDB 提供的 CDC 同步工具做准实时的同步，解析 MySQL 分片对的 binlog，并通过自动合库的方式汇聚到 TiDB 的分布式集群上面。\n\n在 TiDB 分布式集群上可以克服原来由单一的 MySQL Sharding 方案带来的一些限制，比如前面提到的复杂计算、复杂的实时查询业务，这些业务负载就可以从联机交易主库下线到 TiDB 后置库上进行完成。这样可以说是扬长避短，在整个方案当中能够将整个交易的联机部分、批量部分、实时查询部分和复杂的报表部分做一个区分。\n\n### 方案三：核心交易 MySQL(业务单元化) + TiDB 后置库方案\n\n第三种方案和第二种方案类似，但随着核心交易技术以及架构路线的发展，有不少的解决方案会在核心交易的应用侧进行应用维度的微服务化或者单元化的改造。\n\n![5-分库合并入库](https://img1.www.pingcap.com/prod/5_6553094fdd.png)\n\n在整个核心交易当中，把交易链路上都会用到的客户中心、产品中心、核算中心与整个交易分离，将这部分单独拎出来；对于联机交易和账户这部分，例如存款系统与贷款系统，通过业务逻辑上的切分，把他们切分成独立的单元，可以理解为虚拟的分行系统，通过这种方式在应用的业务层实现横向的扩展；同时在整个交易链路上，例如公共服务中心，可以通过微服务方式抽取出来，在不同模块之间通过标准接口来作为调用的公共服务区。\n\n这样的结构产生后，一定会产生多个数据库对应联机交易库。作为业务单元化架构下核心交易联机库背后的后置库，TiDB 同样可以通过 CDC，将诸如客户中心、产品中心、核算中心等统一全局维度的库进行一比一的入库。同时，对于在应用层已经不是依靠 MySQL 分库分表，而是靠应用层切割的垂直分库，能够通过 CDC 工具直接在 TiDB 层汇聚成一个全局的汇总库，在这个汇总库上我们可以完成跨服务单元数据后台的批量操作，包括复杂查询以及报表类的业务；同时，又可以保证在整个业务当中，原来共享服务的库仍旧是以逻辑单独库的形态在 TiDB 的大集群当中存在，对业务提供服务。\n\n#### 微众银行新一代核心系统架构\n\n微众银行就采用了这种方案作为核心系统架构。微众银行在国内的核心交易业务单元化方面有自己的创新之处，在过去三四年的发展过程中，他们整体的核心交易采用了 DCN 的分布式可扩展框架，在应用层实现了扩展性，同时在数据库层的数据处理界面上又保证了非常好的简洁性。\n\n![6-cdc同步入库](https://img1.www.pingcap.com/prod/6_cdc_f1abceeca2.png)\n\nDCN 是一个逻辑区域概念，可以等效认为是一个独立的分支机构，例如一个银行的分行或者网点，通过 DCN 的横向扩展来解决业务的扩张问题。他们同样也采用了以 MySQL 分库分表为后台的联机库，并将交易和核算分离，通过分布式数据库 NewSQL 的技术，将批量和核算通过后置库的方式移到分布式集群当中。\n\n### TiDB 作为核心交易后置库的价值\n\n**TiDB 作为核心交易后置库的价值主要有以下几点：**\n\n- 解决 MySQL 分布式方案中数据汇总计算处理的挑战。\n\n- 标准 SQL，分布式事务，多表复杂关联计算能力提供了跨节点海量数据的高性能批量处理能力。\n\n- HTAP 架构提供行列混合计算能力，海量数据的高性能实时计算。\n\n- 提供完整工具，实现全量同步联机库集群数据，随时成为联机库集群的备选切换保障。\n\n- 吞吐量及性能可以随在线横向透明扩展。\n\n- 内核支持强一致数据部分机制及高可用机制 (RPO=0,RTO <30s）。\n\n- 内核支持多中心多活容灾机制。\n\n### TiDB 对核心交易场景的潜在价值\n\nTiDB 为核心交易场景也带来了一些潜在价值。\n\n首先我们坚信云一定是未来，TiDB 云原生架构及产品能力(K8s 容器集群)就绪，为上云(私有云)提供了技术基础。同时，我们在最近已经完成了对商业云基础平台 ( 开源 OpenShift、开源 Rancher ）的对接适配，加上 TiDB 基于云资源调度和数据库本身的调度机制，能够比较好的实现云中数据库多租户的支持能力。\n\n在内核上，TiDB HTAP 行列混合架构能够支撑未来更多的在线新业务场景，拓宽业务适用面；同时，我们的产品团队也在跟包括 Flink 的团队合作，完成了包括流处理的方案适配，为实时处理类业务提供动力。\n\n另外，我们也初步完成了跨数据中心的调度能力，实现多中心间数据感知调度。在多中心的架构下，通过 TiDB 的分布式调度机制与行级数据调度能力，将数据与中心站点进行动态关联，以地理位置为依据关联数据表(行集合)，减少跨地域访问，降低查询延迟，提高应用的整体性能。同时，利用这样的核心手段，我们可以对冷热数据进行比较灵活的调度，对冷热数据进行分离。\n\n### 解决方案的优势分析\n\n![7-方案对比](https://img1.www.pingcap.com/prod/7_92a85675b0.png)\n\n对于核心联机交易，从传统方案到 MySQL 的分布式方案，再到以 TiDB 为主库的方案或者是作为后置库的方案，TiDB 无论从交易的性能、吞吐、汇总、扩展各方面都有比较显著的优势。并且，相比传统的结构，引入 TiDB 以后在整体硬件、软件，包括整个运维部署的成本方面都有明显的优势。\n\n*未完待续......*","author":"余军","category":4,"customUrl":"tidb-practices-in-key-business-scenarios-in-the-financial-industry-part-1-","fillInMethod":"writeDirectly","id":122,"summary":"本篇文章将为大家介绍分布式关系型数据库 TiDB 在金融行业关键应用领域的实践。","tags":["TiDB","金融"],"title":"TiDB 在金融行业关键业务场景的实践（上篇）"}}]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}