共计 4953 个字符，预计需要花费 13 分钟才能阅读完成。
2007 年，计费平台的一帮年轻人为了实现银行级的高可用、零错账的交易系统，加班加点探讨计划，长达几个月的重复头脑风暴与论证，终于提出了“TBOSS 7*24”容灾计划，并用了一年多工夫落地推广后，斩获 09 年公司级技术冲破奖，取得了 Tony 的首肯，从此开启了计费平台打造金融级数据库的摸索之路。
一路走来，技术谋求永无止境，打造一款更好用的高统一、高可用、高性能分布式数据库产品的初心从未扭转 ，零碎架构历经三代优化，2012 年立项的第四代产品 TDSQL，通过 5 年打磨与海量业务的理论经营优化，并与腾讯金融云单干产品化，正式以腾讯云金融级数据库对外输入，目前 500+ 金融客户笼罩银行、保险、基金证券、生产金融、第三方领取、计费、物联网、政企等多个畛域，尤其在多家银行的外围交易系统落地，标记着 TDSQL 真正冲破成为一款金融级数据库产品，正是这里的冲破，使得我的项目团队往年再次斩获公司级技术冲破奖，这也是公司对团队始终专一金融级数据库底层研发耕耘的认可。
当然，道阻且长，随着硬件一直在更新，业务越来越多样且简单，数据库畛域还有许多新的挑战还需咱们去攻克。本文尝试着记录下过来十年一路摸爬滚打过程中，团队的一些思考与总结，心愿前面的路越走越宽！
从实质上来说，数据库产品要思考的问题仍然还是用户体验的问题！细化来说，数据库产品次要有两类间接用户，别离是开发人员与运维人员，外围就是他们要用得爽。
例如对开发人员来说，他们常常关怀的问题有：
1、开发接口是不是规范的？是否提供欠缺的开发指引？
2、在故障劫难呈现时，开发人员需不需要关怀数据是否会失落？需不需要写很简单的容灾切换逻辑？
3、零碎性能好不好，能不能扛住业务浪涌式压力？
4、零碎是否足够凋谢等等？
而对于运维人员 DBA 来说，他们常常关怀的问题如：
1、零碎的惯例操作是否有标准化的工具或页面间接应用？
2、零碎是否足够通明，使得在异样时，是否疾速的定位问题？
3、是否提供了欠缺的零碎经营手册？
4、配套设施是否欠缺，例如监控零碎、公布零碎、冷备零碎、审计零碎等等？
当然也还有一类间接用户，那就是这些应用数据库的业务零碎的实在用户，他们关怀的问题有：
1、他们的领取、转账等操作是不是失常的，会不会不到账，多扣钱？
2、他们是否可能随时随地发动交易等等？
通常来说，在资源和工夫无限的状况下，这几类用户的需要是要辨别不同优先级的，甚至有时候是抵触的，所以咱们一路走来，始终保持这样一个准则：在保障用户的根本诉求（数据不丢，不错账）的状况下，而后一直优化开发人员与运维人员的应用体验。例如咱们的第一代产品“TBOSS 7*24”就是优先保障高可用、高一致性，确保用户数据不错不丢，然而极大的侵害了开发人员与运维人员的体验，须要业务开发人员开发大量的容灾代码，运维人员须要保护大量的劫难模式等，也就是说很多工作交给了业务开发与运维人员。在前面的几代零碎更迭中，咱们就是一直的将性能下沉，让业务开发和运维越来越简略，必然的数据库自身会更加简单一些。尽可能的在数据库层面去解决三类用户的诉求，也就变成了 TDSQL 的外围挑战。
TDSQL 的外围挑战
TDSQL 经验大大小小有数版本，始终面对的外围挑战是：
1、数据的可靠性。在任何劫难状况下，例如主机故障、网络故障等等，都不能存在数据失落的状况。
2、零碎的可用性。基于数据多正本的状况下，零碎如何保障在一些异常情况下，疾速复原可用，把不可用时长降至最低。
3、高性能。首先，单机性能晋升，对于海量业务来说，可能极大的升高服务器等老本；其次，性能指标也是用户最能间接感触到的指标之一，所以性能优化始终是咱们优先级最高的工作之一。
4、扩展性。也就是通常说的分布式。其实在金融行业，之前对分布式这块的需要并不大，然而随着第三方领取的疾速倒退，给银行的一些零碎造成了很大的冲击，例如双 11、春节红包等流动，这类零碎应用传统的 IOE 架构很吃力，所以他们也心愿能采纳分布式架构来解决这个问题。抛开从思维层面，分布式架构对传统金融 IT 行业人员的冲击外，其实从技术上来说，这里其实挑战很多，TDSQL 也是在逐渐的优化与解决，例如最简单的两个点分布式事务与分布式 Join 操作。目前咱们曾经实现了分布式事务性能的公布，而分布式 Join 还在内测过程中。
5、配套工具。一个数据库软件要体验好，那么就不能仅仅提供几个外围的包，必须要有相应的经营管理工具、问题诊断工具、性能剖析工具等，并且是一个凋谢的、规范的接口，只有这样大家能力更好更无缝的应用。
下面的几个问题，后面 2 个是基本功能的问题，在第一个版本就曾经基本保障了，然而是不是就足够了？远远不够，路走得不够多，遇到的坎太少，碰到新的坑时，仍然可能会摔跤。咱们只有在足够丰盛的场景中，通过大量的实际经营教训，使得本人的零碎经验足够的磨难，能力使得零碎的可用性和数据可靠性保持足够多的 9。前面几个问题，自身也应该是一个继续优化的过程，TDSQL 也始终在寻找最优雅的形式去解决，所以上面就从这几个问题，看看 TDSQL 具体是如何做的。
外围架构
Set 机制：TDSQL 所有的高可用机制均是在 Set 之内实现，每个 Set 之内多个数据节点（1 主 N 备），主备之间能够是基于 Raft 协定的强同步复制机制，也能够是异步复制机制。在主机呈现故障的状况下，在调度模块的帮助下，将筛选备机依照规定流程晋升为主机，疾速复原业务，全程无需人工干预。在咱们惯例的应用过程中，通常是倡议 1 主 2 备，主备之间强同步，这样在主节点故障状况下，能确保主动切换，RTO 为 40s，RPO 为 0。
程度扩容。 分布式版本对外出现为一个残缺的逻辑实例，后端数据实际上是散布在若干 Set 上（独立的物理节点）组成。逻辑实例屏蔽了物理层理论存储规定，业务无需关怀数据层如何存储，也无需在业务代码中集成拆分计划或再购买中间件，只须要像应用集中式（单机）数据库一样应用即可。同时反对实时在线扩容，扩容过程对业务齐全通明，无需业务停机，扩容时仅局部分片存在秒级的只读（只读是理论在做数据校验），整个集群不会受影响。
分布式事务。TDSQL 基于 MySQL 的 XA 实现了分布式事务机制，对各种异样解决做了充沛的鲁棒测试，且绝对于单机事务，性能损失仅 30%。
高级个性
二级分区。第一级即咱们常说的程度拆分，原理是应用 HASH 算法，使得数据能平均的扩散到后端的所有节点；第二级分区应用 RANGE 算法，使得相干的数据可能落在一个逻辑分区，例如能够按工夫分区（相似每天每周每月一个分区等），亦能够按业务个性分区（相似每个省市一个分区等）等等。二级分片能够平衡数据分布和拜访，为疾速一键扩容提供根底撑持，也能够满足疾速删除数据等场景。
读写拆散。基于数据库拜访账号的读写拆散计划，DBA 能基于业务需要对账号设定相干参数，以确保既不会读取到过旧的数据，也不会影响写业务，且业务无需改变代码即可实现读写拆散。这能够极大的升高业务经营老本。
此外，TDSQL 还有全局惟一数字序列、对立参数治理、兼容 MySQL 函数，热点更新等泛滥高级个性，可满足各类业务需要。
内核优化
TDSQL 在数据库内核这块的优化，次要集中在数据复制、性能、安全性等方面。
强同步机制。TDSQL 针对金融场景的强同步机制，无效解决了 MySQL 原生半同步机制的问题：性能升高以及超时进化为异步。目前 TDSQL 在强同步模式下，零碎的并发量（TPS/QPS）与异步模式已无差别，根本能做到性能无损失。
性能优化。
1）咱们对 MariaDB/Percona 的线程池调度算法进行了优化，改良当零碎处于重负载时，查问和更新申请在线程组间散布不平衡等极其状况。并且可能更好地利用计算资源，缩小无谓的线程切换，缩小申请在队列中的等待时间，及时处理申请。
2）组提交（Group Commit）的异步化。工作线程在其会话状态进入组提交队列后，不再阻塞期待组提交的 Leader 线程实现提交，而是间接返回解决下一个申请。
3）InnoDB Buffer Pool 应用优化。例如全表扫描时，防止占满 InnoDBBuffer Pool，而是只取一块来应用。
4）InnoDB 在 MySQL 组提交期间防止与组提交有 mutex 抵触的流动，例如 InnoDB Purge，升高抵触，以晋升性能。
相似的性能优化的点，还有不少，可能在某些场景下，单个点成果不显著，然而集合起来看，目前性能指标整体是不错的。基于 SysbenchOLTP 测试后果，雷同的硬件及测试环境下，TDSQL 性能相比原生版本晋升 85%。
平安加强。在平安方面做了大量优化及加强，包含数据文件加密、SQL 防火墙、SSL 接入、平安审计等。
此外，咱们长期关注 MySQL 的三个分支版本：MariaDB、Percona、MySQL community，对于社区的新个性，也会定期的合入。
部署计划
TDSQL 的强同步机制，自身是能够做到全球化部署的，但其实咱们绝大部分客户无论是老本看，还是从业务场景看，都不须要做寰球部署，常见的两地多核心根本都能满足需要。客户能够基于老本、本身业务数据的容灾要求，以及数据中心散布状况，抉择不同的部署计划。TDSQL 有针对性的在数据可靠性与可用性上做出衡量，做到灵便部署。目前常见的两种部署计划包含：
两地三核心
ZK 散布在两地的三个核心内。
1、主 IDC 故障不会丢数据，主动切换到备 IDC，此时堕落成单个 IDC 的强同步，存在危险。
2、仅仅主机故障，在比照两个同城备节点及一个同城 Watcher 节点后，切换到数据最新的节点，优先选择同 IDC 的 Watcher 节点，尽可能减少跨 IDC 切换。
3、备 IDC 故障，通过另外一个城市的 ZK 能主动做出选举：
a) 备 IDC 的确故障，主动晋升主 IDC 的 Watcher 节点为 Slave, 由主提供服务
b) 主备网络不通，与 a) 一样的解决形式
两地四核心
该计划适应性最强，然而对机房数量要求也高一些。
1、同城三核心集群化部署，简化同步策略，经营简略，数据可用性、一致性高
2、单核心故障不影响数据服务
3、深圳生产集群三核心多活
4、整个城市故障能够人工切换
周边配套
对于 TDSQL 的开发者和运维 DBA 来说，其配套设施、可维护性、透明性等至关重要，因为这决定了他们是否及时发现问题，针对问题能疾速的做出变更及应答。所以 TDSQL 通过这两年的产品化工作，提供欠缺的周边配套体系，例如：
1）冷备零碎。基于 HDFS 或其余分布式文件系统，能够做到主动备份，一键复原。
2）音讯队列。基于 Kafka 定制的 Binlog 订阅服务。基于该音讯队列，TDSQL 还提供了 SQL 审计、多源同步（雷同表构造的数据合并到一张表）等服务。
3）资源管理。基于 cgroup 的对 TDSQL 实例进行编排，进步机器资源利用率。
4）OSS。对 TDSQL 的所有操作，例如扩容、备份、复原、手动切换、申请（批改/删除）实例等操作，均提供对立的 HTTP 接口，能够无效自动化，升高人肉运维的危险。
5）数据采集。TDSQL 所有的外部经营状态或数据，都能实时采集到，业务能够基于这些数据做定制剖析或者构建经营监控平台。
6）监控平台。业务能够基于数据采集模块采集到的所有数据，对接自建的监控零碎，亦可间接应用 TDSQL 自带的监控零碎（需独自部署）。
7）治理平台。基于以上模块，TDSQL 自带经营治理平台（外部平台代号赤兔），DBA 基本上能够通过该治理台进行所有惯例的经营操作，不再须要登录后盾。
8）审计模块。审计模块通过对用户拜访数据库行为的日志采集及剖析，用来帮忙客户预先生成合规报告、事变追根溯源，同时增强内外部数据库网络行为记录，进步数据资产平安。
以上这些模块能够自由组合，没有强依赖关系，运维人员也能够通过 TDSQL 的提供的接口自行对接本人现有的平台（如监控、告警、审计等）。
写在最初
TDSQL 一路走来，在可靠性、可用性、性能、扩展性、配套设施等方面获得了一些里程碑式的成绩，然而远没有到极致的用户体验。例如咱们定位是 OLTP 数据库，适宜高并发短事务的场景，但客户有时候须要在数据库上跑一些的 OLAP 操作，那这块咱们能不能做？如何做？目前的分布式还无奈真正做到一个单机数据库应用，那么在将来硬件倒退状况下，是否做到呢？相似这些挑战还很多，数据库研发这块道阻且长，与大家共勉。
