TDSQL是如何满足了金融级场景的数据库要求
2014年：基于分布式的基础架构
微众银行在2014年成立之时，就非常有前瞻性的确立了微众银行的it基础架构的方向：摒弃传统的基于商业it产品的集中架构模式，走互联网模式的分布式架构。众所周知，传统银行it架构体系非常依赖于传统的商业数据库，商业存储以及大中型服务器设备，每年也需要巨大的it费用去维护和升级，同时这种集中式的架构，也不便于进行高效的实现水平扩展。从过往经验来看，当时除了oracle等少数传统的商业数据库，能满足金融级银行场景的数据库产品并不多。当时腾讯有一款金融级的分布式数据库产品tdsql，主要承载腾讯内部的计费和支付业务，其业务场景和对数据库的可靠性要求，和银行场景非常类似，同时也经受了腾讯海量计费业务场景的验证。微众银行基础架构团队，经过多轮的评估和测试，最终确定和腾讯tdsql团队合作，共同将tdsql打造为适合银行核心场景使用的金融级分布式数据库产品，并将tdsql用于微众银行的核心系统数据库。
why tdsql？
为什么会选用tdsql，作为微众银行的核心数据库呢？本章节将会详细介绍tdsql架构、以及tdsql的核心特性，看看tdsql是如何满足了金融级场景的数据库要求。
tdsql架构介绍
tdsql是基于mysql/mariadb社区版本打造的一款金融级分布式数据库集群方案。在内核层面，tdsql针对mysql 社区版本和mariadb 社区版本的内核，在复制模块做了系统级优化，使得其具备主备副本数据强一致同步的特性，极大提升了数据安全性，同时相对原生的半同步复制机制，tdsql强一致复制的性能也有极大提升。
tdsql集成了tdsql agent、tdsql sqlenginesqlengine、tdsql scheduler等多个模块，实现了读写分离、autosharding、自动主备强一致性切换、自动故障修复、实时监控、实时冷备等一系列功能。tdsql架构模型如图1所示：
图1 tdsql架构模型与set模型
我们可以从横向和纵向两个维度来理解tdsql的架构。
横向是tdsql的请求处理路径，请过通过app发出，经过负载均衡模块，转发到tdsql sqlengine集群；tdsql sqlengine收到请求后，进行请求解析，然后转发到set单元内的数据库实例节点上（写请求到master，读请求可以到master或slave）；数据库实例处理好请求后，回包给tdsql sqlengine，tdsql sqlengine再通过负载均衡模块回包给app。
纵向是tdsql集群的管理路径：tdsql的一个管理单元称为一个set，每个set单元的每个数据库实例上，都会部署一个tdsql agent模块。agent模块会收集所在数据库实例的所有监控信息（包括节点主备角色信息/节点存活状态/请求量/tps/cpu负载/io负载/慢查询/连接数/容量使用率等等），上报到zookeeper集群；zookeeper相当于整个tdsql集群元数据存储管理中心，保存了集群所有元数据信息；tdsql scheduler模块会监控zookeeper的所存储的上报信息，并根据集群状态启动不同的调度任务，相当于tdsql集群的大脑，负责整个集群的管理和调度。
tdsql noshard与shard模式
tdsql提供了noshard与shard两种使用模式，如图2所示。
所谓noshard模式，就是单实例模式，不做自动的分库分表，在语法和功能上完全兼容于mysql，缺点是只支持垂直扩容，这会受限于单实例服务器的性能和容量上限，无法进行水平扩展。
shard模式即autosharding模式。通过tdsql sqlengine模块，实现数据库的sharding和分布式事务功能，底层的数据打散在多个数据库实例上，对应用层还是统一的单库视图。shard模式可以实现容量和性能的水平扩展，通过两阶段xa支持分布式事务和各种关联操作，但是目前还不支持存储过程，同时在建表的时候需要业务指定shard key，对部分业务开发来说觉得会有一定的侵入性 。
图2 tdsql noshard与shard模式
微众银行当时在做系统架构的时候充分考虑了是采用shard版本的纯分布式数据库还是从应用层的角度来做分布式，通过大量的调研分析，最终觉得采用应用做分布式是最可控，最安全，最灵活，最可扩展的模式，从而设计了基于dcn的分布式可扩展架构，通过在应用层做水平拆分，数据库采用tdsql noshard模式，保证了数据库架构的简洁性和业务层兼容性，这个后面会详述。
主备强一致切换与秒级恢复
tdsql通过针对mysql内核源码的定制级优化，实现真正意义上的多副本强一致性复制，通过主备部署模式，可以实现rpo=0，即数据0丢失，这对于金融场景是至关重要也是最基础的要求；同时基于tdsql agent和scheduler等模块，也实现了自动化的主备强一致切换，在30秒内可以完成整个主备切换流程，实现故障rto的秒级恢复。
watch节点模式
tdsql slave节点提供了两种角色，一种是follower节点，一种是watch节点。fllower节点与watch节点都从master节点实时同步数据，但watch节点不参与主备选举和主备切换，只作为观察者同步数据。follower节点和watch节点的角色可以在线实时调整。
自动化监控与运维
tdsql配套提供了赤兔管理平台系统，来支持整个tdsql集群的可视化、自动化的监控和运维功能。如图3所示，为tdsql赤兔管理平台的运行界面。
图3 tdsql赤兔管理平台
通过tdsql赤兔管理平台，可以实现监控数据的采集与显示，告警和策略配置，日常运维操作（主备切换，节点替换，配置更改等），数据库备份与恢复，慢查询分析，性能分析等一系列功能，极大的提升了运维效率和运维准确性。
基于以上的tdsql的架构和特性，我们认为tdsql很好了满足金融业务场景中对数据库的高可用、高可靠、可运维的要求，同时基于mysql和x86的软硬件平台，也能极大的降低数据库层面的it成本，从而极大降低户均成本，非常适用互联网时代的新一代银行架构。
基于dcn的分布式扩展架构
前文提到，微众银行为了实现业务规模的水平扩展，设计了基于dcn的分布式可扩展架构，从而即实现了扩展性，也保证了数据库层面架构以的简洁性。
dcn，即data center node(数据中心节点)，是一个逻辑区域概念，dcn是一个自包含单位，包括了完整的应用层，接入层和数据库库。可以通俗的理解为，一个dcn，即为一个微众银行的线上的虚拟分行，这个虚拟分行只承载微众银行某个业务的一部分客户。通过一定的路由规则（比如帐户号分段），将不同的客户划分到不同的dcn内。一旦某个dcn所承载的客户数达到规定的上限，那么这个dcn将不再增加新的客户。这时通过部署新的dcn，来实现容量的水平扩展，保证业务的持续快速发展。
不同的客户保存在不同的dcn，那么就需要有一个系统来保留全局的路由信息，记录某个客户到底在哪个dcn，这个系统就是gns（global name service），应用模块会先请求gns，拿到对应客户的dcn信息，然后再去请求对应的dcn。gns使用了redis缓存，以保证较高的查询qps性能，同时采用tdsql做持久化存储，以保证数据的安全性。
rmb（reliable message bug），可靠消息总线，是dcn架构的另一个核心模块，主要负责各个业务系统之间高效、准确、快速的消息通信。dcn的整体架构如图4所示
图4 dcn架构模型
微众银行idc架构
有了基于dcn的基础架构模型，下一步就是基础物理环境的建设。微众银行经过4年多的发展，目前已发展成为两地六中心的架构，如图5所示：
图5 微众银行idc架构
其中两地位于深圳和上海，深圳作为生产中心，在深圳同城有5个idc机房，上海作为跨城异地容灾，有1个idc机房。深圳5个同城idc，通过多条专线两两互联，保证极高的网络质量和带宽，同时任何两个idc之间的距离控制在10~50公里左右，以保证机房间的网络ping延迟控制在2ms左右。这一点非常重要，是实现tdsql同城跨idc部署的前提。
基于tdsql的同城应用多活
基于以上的 dcn 架构和 idc 架构，我们设计了tdsql数据库在微众银行的部署架构。如图6所示：
图6 微众银行基于tdsql的同城多活架构
我们采用同城3副本+跨城2副本的3+2 noshard部署模式。同城3副本为1主2备，分别部署同城的3个idc中，副本之间采用tdsql强一致同步，保证同城3 idc之间的rpo=0，rto秒级恢复。跨城的2副本通过同城的一个slave进行异步复制，实现跨城的数据容灾。基于以上架构，我们在同城可以做到应用多活，即联机的业务流量，可以同时从3个idc接入，任何一个idc故障不可用，都可以保证数据0丢失，同时在秒级内可以恢复数据库服务。
在同一idc内，服务器之间的ping延迟通常在0.1ms以内，而同城跨idc之间服务器的ping延迟会大大增加，那是否会影响tdsql主备强同步的性能呢？另外idc之间的网络稳定性能否保证呢？我们通过以下几个措施来消除或者规避这个问题。
首先，在基础设施层面，我们会保证同城的三个idc之间的距离控制在10~50公里左右，控制网络延迟在2ms左右；同时在idc之间建设多条专线，保证网络传输的质量和稳定性；其次，tdsql针对这种跨idc强同步的场景，作了大量的内核级优化，比如采用队列异步化，以及并发复制等技术。通过基准测试表明，跨idc强同步对联机oltp的性能影响仅在10%左右。
从我们实际生产运营情况来看，这种同城跨idc的部署模式，对于联机oltp业务的性能影响，完全是可以接受的，但对于集中批量的场景，因为累积效应，可能最终会对批量的完成时效产生较大影响。如果批量app需要跨idc访问数据库，那么整个批量期间每次访问数据库的网络延迟都会被不断累积放大，最终会严重影响跑批效率。为了解决这个问题，我们利用了tdsql的watch节点的机制，针对参与跑批的tdsql set，我们在原来一主两备的基础上，额外部署了一个与主节点同idc的watch节点，同时保证批量app与主节点部署在同一app。如图7所示：
图7 tdsql带watch节点的部署模式
watch节点与主节点同idc部署，从主节点异步同步数据。因为是watch节点是异步同步，所以主节点的binlog会确保同步到跨idc的另外两个备节点事务才算成功，这样即使主节点所在的idc整个宕掉，仍能保证数据的完整性，不会影响idc容灾特性。当主节点发生故障时，scheduler模块对对比watch节点和其他2个强同步备机的数据一致性，如果发现watch节点的数据跟另外2个idc数据一样新（这是常态，因为同idc一般都比跨idc快），则优先会将这个watch节点提升为主机。这就保证了批量app与数据库主节节点尽量处于同一个idc，避免了跨idc访问带来的时延影响。
通过以上部署架构，我们实现了同城跨idc级别的高可用，以及同城跨idc的应用多活，极大提升了微众银行基础架构的整体可用性与可靠性。
tdsql集群规模
微众银行成立4年多以来，业务迅速发展，目前有效客户数已过亿级，微粒贷，微业贷等也成为行业的明星产品。在业务规模迅速增长的过程中，我们的数据库规模也在不断的增长。当前微众银行的tdsql set个数已达350+（生产+容灾），数据库实例个数已达到1700+， 整体数据规模已达到pb级，承载了微众银行数百个核心系统。在以往的业务高峰中，最高达到日3.6亿+的金融交易量，最高的tps也达到了10万+。如图8所示：
图8 微众银行tdsql业务规模
在过去4年多的运营中，tdsql也从未出现过大的系统故障，或者数据安全问题，同时基于tdsql的x86的软硬件架构，帮助微众银行极大的降低it户均成本，极大提升了微众银行的行业竞争力。微众银行通过实践证明，tdsql作为金融级的核心数据库，是完全胜任的。
微众银行数据库现状及未来发展
目前，tdsql承载了微众银行99%以上线上数据库业务，同时我行也大量采用了redis作为缓存，以解决秒杀，抢购等热点场景，另外还有少量的mongodb满足文档类的存储需求。同时我行从去年开始，也尝试引入了newsql数据库tidb，解决少部分无法拆分dcn，但同时又对单库存储容量或吞吐量有超大需求的业务场景。整体来看，我行目前的数据库主要有tdsql，tidb以及redis/mongodb，tdsql主要承载核心系统业务 ，tidb作为补充解决单库需要超大容量或超大吞吐量的非联机业务需求，reids和mongodb则主要是提供缓存及文档型的存储。
当然我们并不会止步于此，微众银行数据库团队和腾讯云tdsql团队未来会有更加深入的合作。比如我们和腾讯云tdsql团队合作的tdsql智能运维-扁鹊项目，目前已在微众银行灰度上线，可以实时分析tdsql的运行状态和性能问题，是提升运维效率的利器。我们和也在和tdsql研发团队共同调研和评估mysql 8.0版本，以及mysql基于mgr的高可用功能，未来可能会尝试将mysql 8.0和mgr集成到tdsql系统中，并尝试在银行核心系统中试用。
Goodfellow：同行评议才是现今AI会议论文水平下降的元凶！
低噪声、高精度超低温漂精密电压基准源RS5025LV
诺基亚6对比华为荣耀6X：价格配置大比拼！谁将更胜一筹？
苹果新专利曝光，虚拟现实眼镜将采用无线基站增强性能
人工智能岗位高端人才紧缺，如何培养大量AI人才成为难题
TDSQL是如何满足了金融级场景的数据库要求
SEW-movifit变频器的VR控制应用分析
汽车后市场随着汽车保有量上涨稳健扩张，中国存在较大的发展空间
人工智能大突破，具人类学习能力的AI演算法问世
联合创始人首次全面阐述小米如何玩转“人工智能”
工业机器人结构原理图详解
巧用废高压包
TWS耳机异军突起，蓝海市场初见雏形
交流滤波器接法_交流滤波器可以用于直流电路吗
全球移动核心网市场份额数据曝光华为连续七个季度排名第一
itel与运营商深入合作，在非洲推出高性价比的智能手机A60
智慧公安警情研判分析系统解决方案,警情研判系统开发公司
基于FPGA的千兆以太网及E1信号光纤传输系统构成的详细分析和性能测试
“5G承载网”是什么，5g真的中国首上吗
USB Type-C需要了解什么问题
微众银行在2014年成立之时，就非常有前瞻性的确立了微众银行的it基础架构的方向：摒弃传统的基于商业it产品的集中架构模式，走互联网模式的分布式架构。众所周知，传统银行it架构体系非常依赖于传统的商业数据库，商业存储以及大中型服务器设备，每年也需要巨大的it费用去维护和升级，同时这种集中式的架构，也不便于进行高效的实现水平扩展。从过往经验来看，当时除了oracle等少数传统的商业数据库，能满足金融级银行场景的数据库产品并不多。当时腾讯有一款金融级的分布式数据库产品tdsql，主要承载腾讯内部的计费和支付业务，其业务场景和对数据库的可靠性要求，和银行场景非常类似，同时也经受了腾讯海量计费业务场景的验证。微众银行基础架构团队，经过多轮的评估和测试，最终确定和腾讯tdsql团队合作，共同将tdsql打造为适合银行核心场景使用的金融级分布式数据库产品，并将tdsql用于微众银行的核心系统数据库。
why tdsql？
为什么会选用tdsql，作为微众银行的核心数据库呢？本章节将会详细介绍tdsql架构、以及tdsql的核心特性，看看tdsql是如何满足了金融级场景的数据库要求。
tdsql架构介绍
tdsql是基于mysql/mariadb社区版本打造的一款金融级分布式数据库集群方案。在内核层面，tdsql针对mysql 社区版本和mariadb 社区版本的内核，在复制模块做了系统级优化，使得其具备主备副本数据强一致同步的特性，极大提升了数据安全性，同时相对原生的半同步复制机制，tdsql强一致复制的性能也有极大提升。
tdsql集成了tdsql agent、tdsql sqlenginesqlengine、tdsql scheduler等多个模块，实现了读写分离、autosharding、自动主备强一致性切换、自动故障修复、实时监控、实时冷备等一系列功能。tdsql架构模型如图1所示：
图1 tdsql架构模型与set模型
我们可以从横向和纵向两个维度来理解tdsql的架构。
横向是tdsql的请求处理路径，请过通过app发出，经过负载均衡模块，转发到tdsql sqlengine集群；tdsql sqlengine收到请求后，进行请求解析，然后转发到set单元内的数据库实例节点上（写请求到master，读请求可以到master或slave）；数据库实例处理好请求后，回包给tdsql sqlengine，tdsql sqlengine再通过负载均衡模块回包给app。
纵向是tdsql集群的管理路径：tdsql的一个管理单元称为一个set，每个set单元的每个数据库实例上，都会部署一个tdsql agent模块。agent模块会收集所在数据库实例的所有监控信息（包括节点主备角色信息/节点存活状态/请求量/tps/cpu负载/io负载/慢查询/连接数/容量使用率等等），上报到zookeeper集群；zookeeper相当于整个tdsql集群元数据存储管理中心，保存了集群所有元数据信息；tdsql scheduler模块会监控zookeeper的所存储的上报信息，并根据集群状态启动不同的调度任务，相当于tdsql集群的大脑，负责整个集群的管理和调度。
tdsql noshard与shard模式
tdsql提供了noshard与shard两种使用模式，如图2所示。
所谓noshard模式，就是单实例模式，不做自动的分库分表，在语法和功能上完全兼容于mysql，缺点是只支持垂直扩容，这会受限于单实例服务器的性能和容量上限，无法进行水平扩展。
shard模式即autosharding模式。通过tdsql sqlengine模块，实现数据库的sharding和分布式事务功能，底层的数据打散在多个数据库实例上，对应用层还是统一的单库视图。shard模式可以实现容量和性能的水平扩展，通过两阶段xa支持分布式事务和各种关联操作，但是目前还不支持存储过程，同时在建表的时候需要业务指定shard key，对部分业务开发来说觉得会有一定的侵入性 。
图2 tdsql noshard与shard模式
微众银行当时在做系统架构的时候充分考虑了是采用shard版本的纯分布式数据库还是从应用层的角度来做分布式，通过大量的调研分析，最终觉得采用应用做分布式是最可控，最安全，最灵活，最可扩展的模式，从而设计了基于dcn的分布式可扩展架构，通过在应用层做水平拆分，数据库采用tdsql noshard模式，保证了数据库架构的简洁性和业务层兼容性，这个后面会详述。
主备强一致切换与秒级恢复
tdsql通过针对mysql内核源码的定制级优化，实现真正意义上的多副本强一致性复制，通过主备部署模式，可以实现rpo=0，即数据0丢失，这对于金融场景是至关重要也是最基础的要求；同时基于tdsql agent和scheduler等模块，也实现了自动化的主备强一致切换，在30秒内可以完成整个主备切换流程，实现故障rto的秒级恢复。
watch节点模式
tdsql slave节点提供了两种角色，一种是follower节点，一种是watch节点。fllower节点与watch节点都从master节点实时同步数据，但watch节点不参与主备选举和主备切换，只作为观察者同步数据。follower节点和watch节点的角色可以在线实时调整。
自动化监控与运维
tdsql配套提供了赤兔管理平台系统，来支持整个tdsql集群的可视化、自动化的监控和运维功能。如图3所示，为tdsql赤兔管理平台的运行界面。
图3 tdsql赤兔管理平台
通过tdsql赤兔管理平台，可以实现监控数据的采集与显示，告警和策略配置，日常运维操作（主备切换，节点替换，配置更改等），数据库备份与恢复，慢查询分析，性能分析等一系列功能，极大的提升了运维效率和运维准确性。
基于以上的tdsql的架构和特性，我们认为tdsql很好了满足金融业务场景中对数据库的高可用、高可靠、可运维的要求，同时基于mysql和x86的软硬件平台，也能极大的降低数据库层面的it成本，从而极大降低户均成本，非常适用互联网时代的新一代银行架构。
基于dcn的分布式扩展架构
前文提到，微众银行为了实现业务规模的水平扩展，设计了基于dcn的分布式可扩展架构，从而即实现了扩展性，也保证了数据库层面架构以的简洁性。
dcn，即data center node(数据中心节点)，是一个逻辑区域概念，dcn是一个自包含单位，包括了完整的应用层，接入层和数据库库。可以通俗的理解为，一个dcn，即为一个微众银行的线上的虚拟分行，这个虚拟分行只承载微众银行某个业务的一部分客户。通过一定的路由规则（比如帐户号分段），将不同的客户划分到不同的dcn内。一旦某个dcn所承载的客户数达到规定的上限，那么这个dcn将不再增加新的客户。这时通过部署新的dcn，来实现容量的水平扩展，保证业务的持续快速发展。
不同的客户保存在不同的dcn，那么就需要有一个系统来保留全局的路由信息，记录某个客户到底在哪个dcn，这个系统就是gns（global name service），应用模块会先请求gns，拿到对应客户的dcn信息，然后再去请求对应的dcn。gns使用了redis缓存，以保证较高的查询qps性能，同时采用tdsql做持久化存储，以保证数据的安全性。
rmb（reliable message bug），可靠消息总线，是dcn架构的另一个核心模块，主要负责各个业务系统之间高效、准确、快速的消息通信。dcn的整体架构如图4所示
图4 dcn架构模型
微众银行idc架构
有了基于dcn的基础架构模型，下一步就是基础物理环境的建设。微众银行经过4年多的发展，目前已发展成为两地六中心的架构，如图5所示：
图5 微众银行idc架构
其中两地位于深圳和上海，深圳作为生产中心，在深圳同城有5个idc机房，上海作为跨城异地容灾，有1个idc机房。深圳5个同城idc，通过多条专线两两互联，保证极高的网络质量和带宽，同时任何两个idc之间的距离控制在10~50公里左右，以保证机房间的网络ping延迟控制在2ms左右。这一点非常重要，是实现tdsql同城跨idc部署的前提。
基于tdsql的同城应用多活
基于以上的 dcn 架构和 idc 架构，我们设计了tdsql数据库在微众银行的部署架构。如图6所示：
图6 微众银行基于tdsql的同城多活架构
我们采用同城3副本+跨城2副本的3+2 noshard部署模式。同城3副本为1主2备，分别部署同城的3个idc中，副本之间采用tdsql强一致同步，保证同城3 idc之间的rpo=0，rto秒级恢复。跨城的2副本通过同城的一个slave进行异步复制，实现跨城的数据容灾。基于以上架构，我们在同城可以做到应用多活，即联机的业务流量，可以同时从3个idc接入，任何一个idc故障不可用，都可以保证数据0丢失，同时在秒级内可以恢复数据库服务。
在同一idc内，服务器之间的ping延迟通常在0.1ms以内，而同城跨idc之间服务器的ping延迟会大大增加，那是否会影响tdsql主备强同步的性能呢？另外idc之间的网络稳定性能否保证呢？我们通过以下几个措施来消除或者规避这个问题。
首先，在基础设施层面，我们会保证同城的三个idc之间的距离控制在10~50公里左右，控制网络延迟在2ms左右；同时在idc之间建设多条专线，保证网络传输的质量和稳定性；其次，tdsql针对这种跨idc强同步的场景，作了大量的内核级优化，比如采用队列异步化，以及并发复制等技术。通过基准测试表明，跨idc强同步对联机oltp的性能影响仅在10%左右。
从我们实际生产运营情况来看，这种同城跨idc的部署模式，对于联机oltp业务的性能影响，完全是可以接受的，但对于集中批量的场景，因为累积效应，可能最终会对批量的完成时效产生较大影响。如果批量app需要跨idc访问数据库，那么整个批量期间每次访问数据库的网络延迟都会被不断累积放大，最终会严重影响跑批效率。为了解决这个问题，我们利用了tdsql的watch节点的机制，针对参与跑批的tdsql set，我们在原来一主两备的基础上，额外部署了一个与主节点同idc的watch节点，同时保证批量app与主节点部署在同一app。如图7所示：
图7 tdsql带watch节点的部署模式
watch节点与主节点同idc部署，从主节点异步同步数据。因为是watch节点是异步同步，所以主节点的binlog会确保同步到跨idc的另外两个备节点事务才算成功，这样即使主节点所在的idc整个宕掉，仍能保证数据的完整性，不会影响idc容灾特性。当主节点发生故障时，scheduler模块对对比watch节点和其他2个强同步备机的数据一致性，如果发现watch节点的数据跟另外2个idc数据一样新（这是常态，因为同idc一般都比跨idc快），则优先会将这个watch节点提升为主机。这就保证了批量app与数据库主节节点尽量处于同一个idc，避免了跨idc访问带来的时延影响。
通过以上部署架构，我们实现了同城跨idc级别的高可用，以及同城跨idc的应用多活，极大提升了微众银行基础架构的整体可用性与可靠性。
tdsql集群规模
微众银行成立4年多以来，业务迅速发展，目前有效客户数已过亿级，微粒贷，微业贷等也成为行业的明星产品。在业务规模迅速增长的过程中，我们的数据库规模也在不断的增长。当前微众银行的tdsql set个数已达350+（生产+容灾），数据库实例个数已达到1700+， 整体数据规模已达到pb级，承载了微众银行数百个核心系统。在以往的业务高峰中，最高达到日3.6亿+的金融交易量，最高的tps也达到了10万+。如图8所示：
图8 微众银行tdsql业务规模
在过去4年多的运营中，tdsql也从未出现过大的系统故障，或者数据安全问题，同时基于tdsql的x86的软硬件架构，帮助微众银行极大的降低it户均成本，极大提升了微众银行的行业竞争力。微众银行通过实践证明，tdsql作为金融级的核心数据库，是完全胜任的。
微众银行数据库现状及未来发展
目前，tdsql承载了微众银行99%以上线上数据库业务，同时我行也大量采用了redis作为缓存，以解决秒杀，抢购等热点场景，另外还有少量的mongodb满足文档类的存储需求。同时我行从去年开始，也尝试引入了newsql数据库tidb，解决少部分无法拆分dcn，但同时又对单库存储容量或吞吐量有超大需求的业务场景。整体来看，我行目前的数据库主要有tdsql，tidb以及redis/mongodb，tdsql主要承载核心系统业务 ，tidb作为补充解决单库需要超大容量或超大吞吐量的非联机业务需求，reids和mongodb则主要是提供缓存及文档型的存储。
当然我们并不会止步于此，微众银行数据库团队和腾讯云tdsql团队未来会有更加深入的合作。比如我们和腾讯云tdsql团队合作的tdsql智能运维-扁鹊项目，目前已在微众银行灰度上线，可以实时分析tdsql的运行状态和性能问题，是提升运维效率的利器。我们和也在和tdsql研发团队共同调研和评估mysql 8.0版本，以及mysql基于mgr的高可用功能，未来可能会尝试将mysql 8.0和mgr集成到tdsql系统中，并尝试在银行核心系统中试用。
Goodfellow：同行评议才是现今AI会议论文水平下降的元凶！
低噪声、高精度超低温漂精密电压基准源RS5025LV
诺基亚6对比华为荣耀6X：价格配置大比拼！谁将更胜一筹？
苹果新专利曝光，虚拟现实眼镜将采用无线基站增强性能
人工智能岗位高端人才紧缺，如何培养大量AI人才成为难题
TDSQL是如何满足了金融级场景的数据库要求
SEW-movifit变频器的VR控制应用分析
汽车后市场随着汽车保有量上涨稳健扩张，中国存在较大的发展空间
人工智能大突破，具人类学习能力的AI演算法问世
联合创始人首次全面阐述小米如何玩转“人工智能”
工业机器人结构原理图详解
巧用废高压包
TWS耳机异军突起，蓝海市场初见雏形
交流滤波器接法_交流滤波器可以用于直流电路吗
全球移动核心网市场份额数据曝光华为连续七个季度排名第一
itel与运营商深入合作，在非洲推出高性价比的智能手机A60
智慧公安警情研判分析系统解决方案,警情研判系统开发公司
基于FPGA的千兆以太网及E1信号光纤传输系统构成的详细分析和性能测试
“5G承载网”是什么，5g真的中国首上吗
USB Type-C需要了解什么问题