在使用MYSQL的过程中和其他数据库不同的地方，就是分库分表，你肯恩很少听到咋ORACLE  SQL SERVER  PG 上进行分库分表，大多听到的是分区表。

由于互联网业务的灵活性和扩展性，所以在MYSQL 中提出分库分表的操作，而由于分库分表的存在，所以在表，查询，以及底层的设计中，都会和传统数据库不同。

在分库分表中有几种方法，通过业务逻辑的方式，在程序端（通过已经决定好的方式来设计主键，将一个库的数据打散到多个物理的数据库中，查询中通过预设好的逻辑，将发送数据到指定的物理机，来返回数据），但如果通过程序端来模拟中间件或部分中间件的功能，这样的设计会比较死，（对应用也是不透明的）同时也只能针对简单的应用，复杂的多物理库的数据提取，其实会变得比较复杂。

提出了分库分表的中间件，通过脱离业务逻辑层面的，将分库分表的数据处理下移到，程序层和数据库层之前，所以叫中间件。爱可生公司，根据目前成熟使用的中间件MYCAT，（MYCAT 已经不再进行开发多年），继续开发出一个开源的中间件 DBLE。

那分布式中间件会需要考虑和解决那些问题

1  表中的主键的设计，如果将一个表拆分到多个物理的数据库中，则一个表的主键就会是一个头痛的问题，这其中又包含几个问题 多个物理库中的ID 是唯一的，2 多个中间件集群中的 ID 分发的唯一性 3 主键ID 在每个单机数据库中的表的递增性。4 数据插入的性能问题

有人可能提出，其实是可以通过UUID 的方式来处理，如果放到ORACLE ,PG这样的数据库是可以的，但在MYSQL 中是不适合作为主键的，首先不是单库递增，同时作为主键存储的长度较大，占用的空间也较大。当然也可以使用雪花算法的方式其中通过时间戳，机器的编号，以及在设定较少时间中的一个自增数三个部分来组成的，当然这也是有撞库的可能，例如时钟不准确，造成调整时钟到之前的时间。另外可以通过发号器的方式来解决，（自动生成ID ，并下发到不停的机器，机器消费完ID后，在找ID生成器来申请号码）

这里面，DBLE 推荐使用 snowflake 变种的以及 MYSQL offset-step的方式，来进行主键的设计和使用。

 分布式事务中会遇到什么问题

1 中间件下发数据中如何保证下发的数据在commit 后都能在所下发的数据库中存在响应的数据的问题。

其中会遇到以下问题，可能会导致数据不一致的可能

1 在下发过程中的网络抖动问题

2 数据库服务器的故障问题

3 中间件本身出现故障的问题

上面的一些问题需要数据的中间件来进行解决，下图是DBLE的一个图 

大致可以划分为2个接口 三层结构， 2个接口为对应应用端的接口以及对应数据库的接口，三层结构为应用访问层，数据库访问层，以及中间件的核心层

 其中关键的一点是，DBLE 中可以做到任意表在整个查询中的任意JOIN ，如果是单机在同一个库中可以和任何表进行JOIN 是简单的，但如果将一个表进行分库后，多个物理的库存在属性一致的表，在逻辑层将这个表视为一个表和其他表进行JOIN 则要考虑的问题是很多的，也是不容易的。

DBLE 中对于简单查询可以大致是走了这几个过程

（以下为学习以及个人理解，如有不对还请纠正）

1  语句发送到DBLE 的语句接受缓冲层，其中会设置相关的队列，接受语句（如果语句执行的频繁，在缓冲层可以避免无法处理时将语句丢失的可能）

2  在DBLE 中有一个语句的消费器，通过消费队列中的语句，将取到的语句发送给语句的解析器，解析后通过相关的规则将语句分发到多个MYSQL 的服务器上。

3  后端会接受到每个MYSQL 传回的结果，并且将结果打包，将相关的语句结果返回到客户端。

如果用一句话来看，发送语句到队列，队列消费，多组MYSQL处理，结果接受，结果提交。

待续....