余军：分布式数据库在金融行业的创新实践

分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有DBMS的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。余军讲师为你讲解分布式数据库在金融行业的创新实践。

余军

PingCAP 高级技术总监，金融行业首席架构师；开源软件的忠实爱好者，负责金融行业基于 TiDB 产品的解决方案、产品架构咨询和建设规划。主要工作经历：富麦信息科技有限公司 CTO ，中国惠普 Linux 和高性能计算集群方面的资深顾问，在 Red Hat 红帽中国负责开源解决方案和高性能计算。工作研究方向是高可用和开源分布式系数据处理领域。

数据库系统的技术演进

数据库技术发展演进（1/2）

数据库技术发展演进（2/2）

Goodle平台支撑着许多核心业务。

Google - 大规模分布式计算领域的领跑者

Google 十年前基于内部分布式处理框架发表的三篇论文奠定了大数据分析处理基石。开源社区以此为基础打造了 Hadoop。

Google 内部新一代分布式处理框架，于 12/13 年发表相关论文，奠定下一代分布式 NewSQL 的理论和工程实践基石。 PingCAP 以此为基础打造了 TiDB & TiKV。

Google Spanner F1 - 第一个真正意义上 NewSQL 数据库

全球级分布式关系型数据库，数十万机器组成一个超大的数据库集群。

Spanner - 有状态分布式 Key-Value 数据库

F1 - 无状态分布式 SQL 解析器。

支撑 Google Adwords、Wallet 等核心金融业务

根据业务压力，水平无限扩展或者伸缩，底层七副本，保证任意一个数据中心宕机，底层自动切换，上层业务不中断，无需人工介入。

2017年2月，Google 在其GCP公有云平台正式提供 Cloud Spanner 服务，并于5月GA。

TiDB 优势

TiDB：Google Spanner 和 F1 的开源实现

新一代分布式关系型 NewSQL 数据库 TiDB

基于 2013 年 Google Spanner / F1 论文，在 Google 全球核心业务系统中大规模验证。

基于 2014 年 Stanford 工业级分布式一致性协议实现 Raft 博士论文，已成为事实工业标准。

核心 NewSQL 特性概括：

水平线性扩展、强一致分布式事务、故障自恢复的高可用（非主从）、真正跨数据中心多活。

PingCAP 是全球仅有的在该领域进行技术创新的两家公司之一（对标美国 CockroachDB ）。

体系架构完全不同于传统的单机型数据库的理论，真正意义上的分布式架构。

完全从头打造，并非基于 MySQL、PG 或任何数据库中间件进行改造、封装。

TiDB 架构概览

TiDB 已成为数据库领域国际顶级开源项目（1/3）

TiDB 是全球最成熟稳定的 Google Spanner / F1 的开源实现，是基础软件领域的重大创新，具有极高的工程难度，TiDB 既不是数据库中间件，也不是 SQL-On-Hadoop，是真正意义上的 NewSQL。

TiDB 已成为数据库领域国际顶级开源项目（3/3）

TiDB 得到了国内外金融用户的高度关注

一组数据：

2016 年 7 月推出 Beta2 版本

2017 年 9 月推出 Pre-GA (准正式版)

以上 15 个月迭代发布总计 8 个大版本，约 11114 次重要代码递交和更新。

来自国内外 30+ 金融客户的测试，验证和生产使用。

他们有大型国有商业银行，股份制商业银行，大型券商和保险，第三方电子支付企业，互联网金融企业 (个贷／理财／投顾)，科技金融( Fintech )企业以及金融征信企业等。

也有美国知名的移动支付集团及亚洲某大国最大的金融支付集团企业。

典型数据量规模在 5000万+/单表至 50亿+/单表不等。

这些用户的应用 TiDB 的业务场景，主要聚焦在：在线交易，在线支付，移动支付，在线信贷，营销积分，实时风控，投资者服务，金融征信管理。

TiDB 技术精读

TiDB 架构概览

TiDB OLTP 分布式架构

TiDB - 无状态的 SQL 层（对标 F1）

TiKV - 分布式 KV 存储引擎（对标 Spanner）

PD - 元信息管理、集群管理和调度（拥有全局视角的调度模块）

TiKV - 分布式存储引擎（1/2）

TiKV 是一个分布式且支持事务的 Key-Value 存储引擎

数据存储在 RocksDB 中

节点之间通过 Raft 协议保持数据一致性

事务模型采用 Google 的 Percolator

TiKV - 分布式存储引擎（2/2）

存储空间被划分为 Region

Region：连续的 Key-Value 段

数据以 Region 为单位进行存储、计算、复制

TiDB SQL - 分布式SQL引擎

PD - 分布式集群调度和管理

和 Google Spanner 类似的设计

为整个集群的管理提供 - “上帝视角”

存储集群元数据 meta data

维护复制副本的约束

集群数据的迁移，自动平衡和调度

全局时间戳分配

Leader region 的高性能调度

自身也是无单点故障的集群

TiDB OLAP 分布式架构

TiDB 生态工具

TiDB 生态工具：Syncer （数据实时同步）

从 MySQL 实时同步数据到 TiDB

使 TiDB 作为 MySQL 的一个从库

支持正则表达式，可以合并分库分表后 MySQL 集群

TiDB 生态工具：TiDB-Binlog（数据实时备份）

订阅 TiDB 的增量数据

输出格式可以是 protobuf 或者是 MySQL binlog (WIP)

TiDB-Operator 整体架构

TiDB 金融业务场景实践

目前已有许多客户使用TiDB。TiDB适用的十大场景。

1. OLTP - 直销金融：营销活动平台

TiDB 的解决之道：

面向业务应用侧，完全采用了兼容 MySQL 的协议，应用迁移低成本，低风险，且迁移周期极短，满足了用户的周活动间隔的变更窗口要求。

完全透明的分布式架构，用户不用在架设中间件，也无需考虑分库分表/数据路由问题，数据库端容量和性能完全实现线性扩展。

一键式的在线扩容和缩容，活动高峰前／中／后阶段，均可以灵活的高度自动化的调配资源进行适配。

强壮的高可用设计，没有单点故障的架构保证营销活动的顺利开展。

2. OLTP - 支付业务：在线/移动支付

TiDB 的解决之道：

TiDB 的核心设计就是一个完整的强一致性关系数据库，支持完整的分布式事务。事务问题在在 TiDB 架构上完全不存在问题。用户可以像面对一个单机数据库那样执行和管理自己的事务操作，解放了业务开发团队。

由于不需要数据库中间件层，因此没有额外的延迟指标损耗，TiDB 表现出了良好的对移动端支付交易的性能支持。

TiDB 有一个完善的分布式 SQL 层，业务通过负载均衡器，可以并行访问多个 SQL 节点，彻底解决了接入层高可用和性能横向扩展的问题。

3. OLTP - 登记结算：高性能分布式结算处理

TiDB 的解决之道：

TiDB 的分布式架构设计，无论是数据存储层还是 SQL 引擎层都可以横向扩展，实现了并行的结算处理要求。结算批处理作业程序直接和多个 SQL节点交互，通过增加 SQL 节点实现作业的完全并行化。

TiDB 是一个完整的强一致性关系数据库，支持完整的分布式事务，完全能够满足结算过程中对一致性的强要求。结算应用无需进行妥协。

TiDB 支持在线的 DDL 操作，新业务对结算库的核心表变更可以在线完成，极大的缩小了变更窗口，确保了结算作业在规定的时间窗口内完成。

4. OLAP - 交易监控：实时交易监察与监控平台

TiDB 的解决之道：

利用消息中间件，将交易系统的交易记录和撮合日志，流式写入 TiDB，利用 TiDB 的分布式存储，高性能数据写入和弹性存储。

TiDB 分布式 SQL 引擎，提供了高性能的即席查询计算能力。包括对多类型JOIN 的支持 (Hash/Index lookup, Sort merge)，基于成本的CBO优化器框架，过滤和谓词计算下推到分布式存储引擎等一系列特性。

TiSpark OLAP 分布式引擎，结合了 TiKV 分布式存储引擎和 Spark 分布式计算的强大能力，对于极复杂的 SQL 查询，可以通过 Spark SQL, 直接从监察监控库中获得数据，并利用Spark 集群进行高性能计算。

5. OLAP - 风控：实时风控

TiDB 的解决之道：

风控数据通过信息中间件双写Hive/Hadoop（历史库/历史分析）

TiDB的分布式存储引擎架构，非常轻松地应对海量风控数据的导入，存储和查询处理。风控内主要的核心表数据量规模在50亿以上。

TiDB 的分布式SQL引擎层，可以高性能的为前端各类消费端提供低延迟的精准查询。

TiDB 完整的标准的SQL关系模型支持，为了风控业务开发团队建模和业务侧的应用开发。