基于数据库中间件配置的几类问题

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

读完需要

9

分钟

速读仅需3分钟

截止今天，算是把年前遗留的中间件自动化配置的工作完成了大部分。很多人诟病数据库中间件使用中的一些问题，从设计实现到回归的过程中也感悟到了蛮多的思想。

首先，基于中间件的配置管理有什么问题。如下是一个引入了中间件的分片设计图，在数据库中，会有中间件来作为代理，通过代理层来联动多台数据库分片节点，分片的设计也是相对轻量而且灵活的。

当然要了解更详细的信息，我们还是需要看下分片的配置关系图，我们以MyCAT这个中间件为例，下图左侧是数据库中的逻辑结构，有库有表，在右侧是相应的数据库分片设计，会有不同层面的映射。

我们的问题是基于中间件的配置有什么问题，那么引入了中间件，就自然而然的引入了中间件的配置，这个配置信息如何联动，如何更有优雅的扩展，这是对于DBA来说很重要的问题，我们在这个方面有一些相关的经验和痛点。

1）引入了中间件层面的负载均衡，导致中间件配置没有同步，使得业务部分访问失败

2）周期表的类型相对比较丰富，使用较多的是基于日期维度的周期表，比如test_20200218,test_20200219这样形式的日表，如何扩展日表是一件很繁琐的事情。

3）新需求的迭代速度是很快的，通常业务侧经过验证感受到了明显的优势之后，就更愿意使用分片的模式，这样会导致新增表的需求也会增加，而满足业务同学美意的同时势必会有大量的碎片化工作。

4）创建日表的过程，一旦有了人的参与，那么就需要一些审核机制，我们碰到一些人为创建的配置，导致日期表不连续，直到业务同学找过来，已经产生了严重的影响：丢数据。

5）通常集群环境的权限配置不够统一，操作方式也有较大的差异，有的可以通过中间件新增配置，然后通过中间件执行create table语句来创建，有的环境需要在分片节点上执行create table语句，一旦分片节点多或者分片逻辑复杂，就很容易混乱，基本上把一套完整的配置捋清楚需要半小时到一个小时，而且最头疼的是如何一个节点的配置失败，全局状态也是失败，排查的过程很是费神。

6）基于时间维度（比如日期）的表，一旦保留周期过长，势必就需要做下数据清理，如何更加优雅的情能力数据也是一个难题。

7）略有难度的一个需求，是业务真实场景所需，比如一个核心业务的字典表，配置了一个表名比如是test_data,但是线上环境不允许业务同学直接创建表，那么这个工作就需要下移到运维侧来衔接起来，可以通过反向扫描配置信息（通常配置变更的操作是异步的，即增加了一个新表的配置不要求是秒级生效）得到新增表，然后后端实现。

接下来的内容我们会来对上面的问题做一些细致的设计和改进。