分布式数据库动态扩缩容操作的实际操作性如何？

针对OB数据库来讲，扩容是非常简单的。一般扩容分集群级别扩缩容，和租户级别扩缩容。
集群级别的扩缩容稍微复杂点，需要先把相关server上的资源迁移走，然后在通过下线server方式缩容。都是在线操作，大部分操作都是OCP这个工具上实现，十分简单。
租户级别的扩缩容就更加简单了，可以说是秒级别就可以实现。就是通过修改租户的资源规格来达到动态扩缩容的。十分简单方便。

资源动态扩缩容是金融行业、特别是银行业普遍的需求，常见如下:
一方面，不同业务的高峰时段不一样，举个例子，日终清算和贷款批量扣款还款是不同时间段的业务。
另一方面，热点库、热点分区、热点账户的问题客观存在
综上，因此数据库必然有动态扩容需求、动态分割资源的需求，这时候，租户隔离和动态加减服务器就提上日程了。

租户隔离，不仅是线上数据库稳定的基本保证，应用通过容器实现微服务的拆分，实现有效隔离，数据库层怎么隔离呢？ 就是要通过租户资源隔离，实现数据库层的有效隔离。从业务价值来看，租户隔离是实现资源动态、分时段分割的有效手段。一段时间给到日终清算，跑批完成后，给到贷款批量扣款还款。

动态加减服务器方面，选择支持一致性协议的数据库，那些基于开源魔改的数据库，用什么一致性Hash算法实现所谓的打散，能够扩容，缩容缩不了 或者缩容不平滑。
从实践方面，加减服务器就看蚂蚁和阿里的OceanBase，多年大促的打磨，从电子商务的高并发，到三方支付，这方面久经考验。数据库的成熟是业务场景磨出来的，不是研发写出来的。

数据库分两部分，一部分是提供业务服务的进程，一部分是需要持久化的数据。我们说扩缩容的时候，一般也要讨论这两部分。

一般而言扩容缩容是应对业务峰谷的。所以真正需要扩缩的其实是服务进程部分，这部分最好是需要时就拉起，不需要就关闭。

但这有两个问题要解决，首先如果服务进程不是无状态的，那么必然涉及到数据的搬迁重布局，也就是服务的扩容缩容实际上要带动数据一起。第二个问题是扩容缩容的前提是扩出来的服务能和主节点实时同步，而且能读能写。这样扩容出来的服务才能对业务增加吞吐，但是开源主从数据库要做这点并不容易。如果基于中间件切片，可能要重新切。

所以我的看法是，要能灵活扩容缩容，一定要把数据持久化部分独立出来，让数据库服务变成无状态。

然后无状态化的数据库要能实现一致性多读多写（对于MySQL可以参考我分享的文章《怎样才是分布式数据库存算分离的正确姿势》里面介绍的方法）。

接下来独立出来的持久化部分，涉及到的是容量扩容（容量缩容比较少见，除非把库删了）。因此只要选择可以平滑扩容的外置独立存储就行，这种企业级存储一般都能做到，选择面也是比较宽的。

分布式数据库的扩容肯定会涉及到数据的重分布，这个过程比较耗费资源，当然可能会影响正在运行的业务，就我接触的扩容来说，基本原理就是建立中间表将数据重新插入到新表，之后再做rename的操作，这个过程最好还是停止业务去做，如果同时做扩容和业务并行运行，可能会有很多不可预知的意外出现，尤其是数据的一致性。

感觉是个梦。一开始得规划好数据库分布和容量估算，千万别把希望放在这个事儿上。否则难度巨大，风险也高。

在线扩缩容都有产品功能，但实际操作性不好说。比如一个小银行的数据量不会有爆发性增长，一个单库可能就会撑很久，根本没有这些需求呀。
再者，扩缩容时要不要停机对产品实现难度也不一样。如果中小银行，在产品不成熟时建议停机操作，这毕竟是偶发操作

在线扩容和在线缩容在原理上都很好实现，主要是看对业务的影响降低到什么程度

在线扩缩容肯定对业务都多多少少会有一些影响
一般建议是尽量申请停机窗口来做扩缩容
也有一些特殊业务很难申请停机窗口、或者申请的停机窗口时间很短的，那么这样的场景就是对数据库产品功能的考验了

在线扩缩容一般都会带来存储节点的IO冲击，进而影响到业务系统的SQL响应时间，在数据重均衡期间，如何平滑的使用存储节点的IOPS资源和其保护，尤其重要

分布式数据库均宣称支持动态节点扩容和缩容，大家在主流分布式数据库是否进行过动态扩容和缩容操作，实施过程是否有什么问题，尤其是动态缩容操作，个人感觉相对难度较大点。

解读要求：

１、支持动态的扩容缩容：要求做到动态实现，也即数据分片的数量是可以动态调整的。

２、无服务影响的扩容缩容：动态扩容缩容时，不能中断业务系统的数据服务。

实现技术：

１、思路之一：不改变数据分片的数量，且只腾挪数据分片的存储位置，支持动态扩容缩容服务器节点，例如：腾讯TDSQL、热璞数据库HotDB等支持此模式，可以有效规避软件出现Bug缺陷的数据错乱风险。
　
２、思路之二：改变数据分片的数量，且按数据分片颗粒度腾挪数据分片的存储位置，支持动态扩容缩容服务器节点，例如： 阿里云PolarDB-X、华为云GaussDB、腾讯TDSQL、热璞数据库HotDB等支持此模式，无法做到规避软件出现Bug缺陷的数据错乱风险。
  
3、思路之三：改变数据分片的数量，且按数据存储块颗粒度 数据分片的存储位置，支持动态扩容缩容服务器节点，例如： TiDB、OceanBase等支持此模式，无法做到规避软件出现Bug缺陷的数据错乱风险。

4、小结：

4.1 思路之一的颗粒度是最大的、思路之二的颗粒度是中等的、思路之三的颗粒度是最小的；
 
4.2 思路之一功能实现是无风险的、思路之二功能实现是有风险的的、思路之三功能实现是风险最大的；
 
4.3 思路之三有存储介质依赖，思路之一、思路之二无硬件设备依赖。