一、分布式数据库系统概述

1、概述一

分布式数据库（Distributed Database，DDB）是指数据分散存储在计算机网络中的各台计算机上的数据库。
分布式数据库系统（Distributed Database System，DDBS）通常使用较小的计算机系统，每台计算机可单独放在一个地方；每台计算机中都可能有DBMS（数据库管理系统）的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库；位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的、逻辑上集中、物理上分布的大型数据库系统。

2、概述二

分布式数据库，是指利用高速计算机网络，将物理上分散的多个数据存储单元连接起来组成一个逻辑上统一的数据库。
分布式数据库的基本思想，是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。
近年来，随着数据量的高速增长，分布式数据库技术也得到了快速的发展。传统的关系型数据库开始从集中式模型向分布式架构发展。基于关系型的分布式数据库，在保留传统数据库的数据模型和基本特征前提下，从集中式存储走向分布式存储，从集中式计算走向分布式计算。

3、分布式数据库系统主要特点

在大数据时代，面对海量数据量的井喷式增长和不断增长的用户需求，分布式数据库系统必须具有如下特征，才能应对不断增长的海量数据。
1、高可扩展性
分布式数据库系统必须具有高可扩展性，能够动态地增添存储节点以实现存储容量的线性扩展。
2、高并发性
分布式数据库系统必须及时响应大规模用户的读/写请求，能对海量数据进行随机读/写。
3、高可用性
分布式数据库系统必须提供容错机制，能够实现对数据的冗余备份，保证数据和服务的高度可靠性。

4、分布式数据库系统优点

在大数据时代，面对日益增长的海量数据，传统的集中式数据库系统的弊端日益显现，分布式数据库系统相对传统的集中式数据库系统具有如下优点：
1、更高的数据访问速度
分布式数据库系统为了保证数据的高可靠性，往往采用备份的策略实现容错机制。所以，在读取数据的时候，客户端可以并发地从多个备份服务器同时读取，从而提高了数据访问速度。
2、更强的可扩展性
分布式数据库系统可以通过增添存储节点来实现存储容量的线性扩展，而集中式数据库系统的可扩展性十分有限。
3、更高的并发访问量
分布式数据库系统由于采用多台主机组成存储集群，所以相对集中式数据库系统，它可以提供更高的用户并发访问量。

5、典型应用

以最典型应用的银行领域为例：
1、可以大大提高数据的管理效率
将分散的数据库从逻辑上联系在一起，可以大大提高数据的管理效率。这就是总行和支行之间的关系：总行与全国各地的支行之间，既有各自需要处理的数据，又有需要交换的数据。
2、可以提高故障发生时的数据安全性
将数据分散存储在各地的数据库中，可提高故障发生时的数据安全性。一旦上海支行的数据库出现故障，比如停机、损坏，也是仅仅限于上海支行，总行、广州等其他地区的支行数据库的数据都不会受到影响。
3、分布式架构具备良好的扩展性
例如，在建立一个新的海外支行时，只要将新建的数据库加入到原有的分布式数据库架构中就可以了，以最小的代价在不影响原有支行、总行的情况下完成数据库系统的扩展。
4、以冗余方式进行数据的备份
以备在系统崩溃、数据丢失的情况下，仍有备份数据可以进行恢复。

6、集中式数据库和分布式数据库的区别：

二、集中式数据库

集中式数据库基本上是一种存储，定位以及仅在单个位置维护的数据库。此类数据库是从该位置本身修改和管理的。因此，该位置主要是任何数据库系统或中央计算机系统。可以通过Internet连接（LAN，WAN等）访问集中位置。该集中式数据库主要由机构或组织使用。

image.png

优点 ：
由于所有数据仅存储在单个位置，因此更易于访问和协调数据。
集中式数据库的数据冗余非常小，因为所有数据都存储在单个位置。
与所有其他可用数据库相比，它更便宜。
缺点：
在集中式数据库的情况下，数据流量更多。
如果集中式系统发生任何类型的系统故障，那么整个数据将被破坏。

三、分布式数据库：

分布式数据库基本上是一种数据库，它由多个相互连接并分布在不同物理位置的数据库组成。因此，可以独立于其他物理位置来管理存储在各个物理位置上的数据。因此，在不同物理位置的数据库之间的通信是由计算机网络完成的。

image.png

优点：
由于数据已经分散在不同的物理位置，因此可以轻松扩展该数据库。
可以从不同的网络轻松访问分布式数据库。
与集中式数据库相比，该数据库更安全。
缺点：
该数据库非常昂贵，并且由于其复杂性而难以维护。
在此数据库中，由于它分布在不同的物理位置，因此很难为用户提供统一的视图。

四、集中式和分布式业务场景解析：

4.1、集中式

由于集中式数据库已经是非常成熟且应用范围极为广泛，从目前银行的众多系统来看，适用的业务场景超过了95%以上。

4.2、交易型分布式

分布式数据库由于将大量的数据，如账户信息分散到了多个数据节点上。当系统出现各种资金流转的事务，就极有可能导致一个事务跨越多个数据节点的问题。这就导致了分布式事务的问题。
最初的交易型分布式数据库的出现，其应用场景主要是互联网型的业务场景，比如说电商交易，用户下单买东西、支付等等操作，根本不是完整的交易，因为存在发货和收货的过程，这些交易被拆散成了多个极为简单的过程，整体数据完全不需要强一致性的要求，所以在数据库层面的交易基本可以避免出现分布式事务的出现，即使有分布式事务也没有那么高的一致性要求。
而银行的交易绝大多数对事务和数据有强一致性的要求，且有严格的校验规则，这就导致了银行的交易中涉及到了诸多账户和数据的关联性。这种特点对于分布式来说尤其难以处理，数据库领域里较为成熟的技术是通过两阶段提交技术解决分布式事务的强一致性问题，但是该种技术存在多次网络通讯，会造成较大的资源开销和交易延迟。对常规的银行交易并不太合适。
所以交易型分布式数据库，就目前的行业技术而言，比较适合用在互联网型的简单交易的业务场景。所以若要在银行业中应用，必须将传统的业务系统中的不同业务进行分离和改造。这其实也是一种业务拆分，跟微服务是类似的思路。

五、应用改造解析

5.1、集中式

从业务角度来说，业务逻辑基本不需要改造。只需要关注数据库语法、驱动等的差异上，应用开发的工作量比较小。
但是如果本身系统的负载量很重，超过了单台服务器的算力极限，就需要进行微服务改造。也就是将一个大型的应用进行业务拆分。跟过去银行的胖核心向瘦核心转变的发展历程类似，所以微服务化的发展方向也在银行业的这个发展历程中被证实是行之有效的。
一个大型应用的负载量进行微服务化以后，实际上是一种业务层面的分布式改造方式，称为垂直分片。这种分片的好处就是系统之间相对比较独立，不会出现交易跨节点的问题，不存在数据一致性的困难。
况且微服务化也是各行业，包括银行业，未来业务系统发展的一种方向。

5.2、分布式

从业务适用场景来看，在前述章节中也描述过了，交易型分布式数据库主要适用于互联网型的简单交易场景。必须在特定的业务系统中，找到合适的业务模块才能适用。而且在传统数据库中的诸多全局的特性，都需要在应用层进行考虑和改造，例如：
●数据一致性，需要考虑强一致性、最终一致性和柔性事务对事务数据的影响；
●备份恢复的一致性问题，为了满足一致性对生产可能会造成影响；
●数据分片的算法，尽可能保证交易不跨节点；
●外键关联，由于不同表的关联字段和分布式的分片键可能不一样，所以该功能无法实现；
●全局索引，由于数据跨多节点，索引没办法做到跨物理节点检索，所以count(*)等操作无法优化；
●全局唯一性，有的产品在主键、唯一键的全局唯一性很难保证，即使能支持也会严重影响性能；
●全局序列，大多产品每个节点只能维持自己的序列，但对于业务来说这没有意义。有的产品支持全局序列，但又会出现严重的瓶颈，性能还不如集中式数据库；
●聚合运算受限，可能出现众多聚合函数不支持；
●在存储过程、自定义函数功能有极大限制，以至于众多数据处理必须靠应用层解决；
●临时表和模式功能使用受限，需要应用层处理；
●事务隔离级别，无法做到集中式数据库支持得丰富，可能会导致某些应用需要重新设计；
●扩展性，分布式数据库的扩展性较好，但是要联机动态扩展对生产仍然存在明显的影响；
即使我们找到一个合适的业务场景可用于分布式数据库，但是应用也不可能做到不改造，从上述列举的内容来看，改造量非常大。从应用的拆分，到业务逻辑的修改，甚至到很多细节代码层面都需要考虑，基本上应用得完全重写。

六、基础架构层面解析

6.1、集中式

初期投入：在负载量许可的范围内，资源利用率较高，集中式架构的硬件投入比较低；
研发投入：中小型业务系统研发投入成本极小，即使是大型应用进行微服务化的改造量也相对较低；
长期投入：集中式架构简单、组件少、更为成熟，运维成本更低。且用电量更低。

6.2、分布式

初期投入：由于分布式存在大量分布式交互，负载能力上是分布式架构需要多台机器等效于集中式1台服务器。尤其是小型集群，起步可能是5~8台节点才能等效于1台集中式的能力。性价比很低；
研发投入：首先要进行业务拆分，找到合适的交易业务进行分布式改造，还得考虑兼容差异问题，研发投入无论如何都比较大；
长期投入：架构复杂，一般都是几十节点，大型系统几百节点，运维成本和用电成本都很高，与国家双碳规划相悖。