MySQL分布式管理初步设计

这是学习笔记的第 1795篇文章

MySQL里面一般提到分布式，所说的主要就是基于中间件的方案。

中间件方案对于业务的使用相对是透明的，而且扩展性相对较好，这里说较好，是基于良好的架构设计，对于弹性伸缩的支持还是有限的。

所以行业里也有说基于中间件的方案是伪分布式，至于是不是纯粹的分布式方案，其实讨论的要点不在于配置是否使用XML，而在于整个方案的设计是不是足够轻量。

当然抛开业务场景和数据定位来说分布式，是很空洞的，也是很无力的。

比如流水型数据，哪里需要那么多的事务支持，

强事务一致性的业务，拆成分布式维护代价也会很高，就好比相比关系型和NewSQL，一个是油车，一个是电车，不能说一个完全会取代另外一个，而是基于特定的时间维度和场景来考虑。

技术圈的人容易有一个毛病就是总是容易陷入自己的意识之中，可能做事情的时候忙活了一圈发现原来这个是不重要的。不要为了分布式而分布式。

至于分布式管理的部分，主要的思想是基于分片的逻辑设计，我们会基于中间件来管理整个分布式集群，对一个结构相对稳定的系统而言，分布式是很轻松的，但是如果存在一些数据变更的时候，这个变更的代价就会很高。

对一个已有的配置表增加一个字段，那么我们可能考虑多个分片，比如一个表test_log,我们把数据分成16分，那么就是16个分片，对于业务来说都是test_log,因为基于资源和扩容的考虑，我们的16个分片不是分布在16台服务器上，而是4台服务器上，也可以理解是4个物理分片节点，16个逻辑分片节点。

对整个集群做数据变更管理的时候，其实就涉及很多细节工作了。对此我设计了一个初版的demo,也是作为分布式管理的一个基本入口，接入的第一个功能就是实现变更的平台化，就是对于表test_log做表级别变更，那么维护这个的代价和维护一个单表是类似的。整个环节的工作不是在中间件基础上完成，而是在各个分片节点上完成。

在这个基础上，还有一些辅助工作要完成，这就是周期表的维护了，我们可以基于时间维度来拆分表，比如test_log_20181105,test_log_20181106

比如这些表我们创建了一个月的，但是一个月之后，可能我们就很容易忘记了，所以对于周期表的维护可以基于这些细节做深做细。

在这个基础上，我们可以做一些更有特色的服务，比如最近在接入的一个业务，处于压测阶段，对于数据的增长情况其实没有一个很清晰直观的认识，那么我们就可以基于中间件采集从库端的数据情况来生成一个趋势图，比如按照10分钟为一个维度来获得数据变化，那么在此基础上如果表数据是1000万，我们就知道这1000万数据是怎么来的，可以基于此来做一些更有针对性的维护和优化。