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

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

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

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

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

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

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