分布式数据库TiDB在商业银行的设计与实践

关系型数据库的发展经历了漫长岁月，这些数据库大家都非常熟悉，包括交易型、分析型的很多数据库产品和技术。TiDB 分布式数据库是新一代开源分布式 NewSQL 数据库，整个产品的结构非常清晰，计算跟数据存储层分离，这是现代大部分分布式数据处理系统通常都会倾向和考虑采用的架构：

最底层“TiKV” 层，是分布式数据库的存储引擎层，不只是用来存取和管理数据，同时也负责执行对数据的并行运算。在TiKV之上即是“TiDB”层，为分布式数据库的SQL引擎层，处理关系型数据库诸如连接会话管理、权限控制、SQL解析、优化器优化、执行器等核心功能。此外，还有一个承担集群大脑角色的集中调度器，叫做“PD”，同时整体架构中还会融合一些运维管理工具，包括部署、调度、监控、备份等。

TiDB可实现自动水平伸缩，强一致性的分布式事务，基于 Raft 算法的多副本复制等重要 NewSQL 特性，并且也满足我行对于高可用、高性能、高可扩展性的要求。TiDB部署简单，在线弹性扩容不影响业务，异地多活及自动故障恢复保障数据安全，同时兼容 MySQL 协议，使迁移使用成本降到极低。这篇文章中，我们将详细介绍TiDB在我行的设计与实践。

一、设计目标

我们在设计TiDB分布式数据库集群时，需要考虑多方面的需求，因此，制定了以下内容，作为项目的设计目标。

二、业务要求

1、业务数据估算

我们设计的TiDB分布式数据库集群在一期计划承载一套业务系统，该系统为我行核心支付交易系统。在采购设备之前，我们根据业务的发展规模进行了合理估算，得出了预期日交易量、数据规模、数据增长率等信息。

2、设备需求估算

设备需求按照第一年的数据量和日交易量进行规划，并综合考虑了数据副本数和磁盘空间可用率，因此需要规划足够的冗余存储容量。此外，TiDB集群还需要中控机对集群进行统一管理、需要监控机进行集群监控、需要服务器进行数据备份，因此，还要考虑这些服务器的规划。

除了生产集群，我们还设计了从集群，作为异地灾备使用。生产集群和灾备集群之间通过binlog同步数据，我们选用了Kafka作为binlog同步工具，因此，需要考虑Kafka服务器的配置规划。

至此，我行的TiDB集群所需的设备均已规划完毕，详情如下：

三、整体架构设计

我们的TiDB集群为两地三中心多活架构，并且设计了主从集群的灾备部署，本章节我们将详细介绍架构设计。

1、逻辑架构设计

架构说明：

(1)整个集群采用主从结构，主集群作为生产集群，承担日常生产服务，从集群通过 binlog 异步同步主集群数据，作为灾备集群使用。

(2) 主集群(生产集群)采用两地三中心架构，分别为同城IDC1、同城IDC2、异地 IDC3。

(3)从集群与主集群通过binlog完成数据同步。

2、物理位置规划

(1)IDC1、IDC2各配置两个机柜，均用于部署生产主集群，IDC3一个机柜用于部署生产主集群，另一个机柜用于部署灾备从集群。

(2)每个IDC配置两台万兆交换机(以主备模式部署)，主集群各台机器内部通信、从集群各台机器内部通信、主从集群之间都是使用万兆网络。

(3)全局DNS下挂载三个IDC的负载均衡，各IDC种负载均衡挂载各自中心内部的TiDB服务器，以千兆网环境对外提供业务服务。

四、运维方案设计

1、高可用方案

高可用是 TiDB 数据库的特性之一，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。我行的TiDB生产集群，由生产中心、同城灾备中心、异地灾备中心共同实现两地三中心多活高可用部署方案。下面，我们将从不同的维度来分析集群的高可用性。

(1)从服务器角色的角度

集群中的服务器有三个角色：TiDB、TiKV、PD，我们从这三个角色来分析集群的高可用性。

TiDB 是无状态的，以实例为单位通过前端的负载均衡设备对外提供服务。当单个TiDB实例失效时，仅仅会影响当前实例上进行的会话，应用服务出现单次请求失败的情况，应用重新连接至其他TiDB实例后即可继续获得服务，此时可以先摘除这个实例进行故障解决或者重新部署一个新的实例。

TiKV 以集群方式部署，通过 Raft 协议保持多副本情况下的数据一致性，并通过 PD 进行数据层面的负载均衡调度。单个TiKV节点失效时，会影响这个节点上存储的所有Region。对于 Region 中的Leader 结点，会中断服务，等待其他TiKV上的Region重新选举Leader，待Leader选出了可继续对外提供服务;对于Region 中的Follower节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内(默认 30 分钟)无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。

PD 同样以集群方式部署，通过 Raft 协议保持数据的一致性。单个实例失效时，如果不是leader，那么服务完全不受影响;如果是leader，那么PD集群会重新选出新的leader，自动恢复服务。

(2)从宕机规模的角度

我行的TiDB数据库集群可容忍单机级、Rack级、数据中心级的故障，从而实现高可用。

单机服务器故障，分为TiDB、TiKV、PD三个角色，参考上一小节的阐述。

我们将集群所有服务器分散放置在各个Rack里，根据Raft协议大多数原则，单个Rack出现故障，不会影响集群对外提供服务。我行的架构允许集群中两个Rack同时出现故障。

任何一个数据中心发生故障，根据Raft协议大多数原则，剩余的两个数据中心仍可对外提供服务。

2、存储方案

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!