分布式数据库预研

目前流行的分布式数据库解决方案

目前在互联网公司中分布式数据库是使用最广泛的 — 当然，我们局限于大的互联网公司。例如 iteye.com，它也是互联网公司，但是没有必要使用分布式数据库。而BAT的许多应用，因为有上亿级的用户，就必须使用了。

当需要使用成千上百台服务器的时候，大家普遍选择的是免费的数据库，例如MySQL。所以网上的文章大多是MySQL的解决方案。

对于MySQL的解决方案，一般主要分为两类。
第一类：多库冗余的方案
代表产品：Gelera。http://galeracluster.com/
这类产品的主要特性是可以提供多个主库，主库之间的同步是实时的，不会有延迟。但是每个数据库都保存了全部的数据，所以
是冗余的。这类产品没有水平切分表的功能，所以和上面说的企业级的cluster差不多。最大特点是省钱。

第二类：水平切分表的方案
当数据的量很大，cluster已经解决不了的时候，一般会首先采用垂直切分，也就是分库。把不同的功能分配到不同的数据库里。
也有一种观点认为垂直切分是把一个表的字段切分，分配到不同的表里。
垂直切分虽然可以按照业务需求，把数据库的负载分开，但是对于每一个数据库，如果表的数据超大，就需要采用另一种方案，
也就是水平切分，把一个表的数据按照某个规则分配到不同的数据库的不同的表里，一般把这个叫做sharding。
MySQL提供了sharding的解决方案：MySQL Cluster (别看名字叫cluster，其实它也提供了sharding的功能)。
http://www.mysql.com/products/cluster/features.html
看介绍功能非常强大，但是也有一些限制，比如数据库引擎不能使用innoDB，必须使用NDB等。

第三类：各个公司自定制的分库，分表方案
使用自己定制的方案，各个公司都遵循了差不多同一个思路：垂直切分（分库），水平切分（分表）。网上的资料有很多，各个
公司分享的资料也有很多。但是因为这确实是有价值的技术，所以大家的分享也就都是“浅尝辄止”，总体思路分享了，细节是绝对不会分享的。所以资料看多了，也就发现思路都差不多，就看你怎么做了。
云栖社区这篇分享不错：https://yq.aliyun.com/edu/lesson/44?spm=5176.100242.lessonh1.36.loWn19，算是讲了很多的细节。

第四类：使用云服务
很多大型的云服务提供商基本都提供了分布式数据库的服务，如果想节省成本，降低风险，这绝对是好的选择。

自己的一点想法：
如果有一天自己会面对分布式数据库的场景，并且MySQL提供的方案无法使用的时候，自己会如何设计其中的架构呢？
大概的架构应该是下面这个样子：

对于蓝色的“分布式管理器”来说，它应该是一个数据库连接的模拟，或者说是代理。与具体的编程语言无关，总之它就好像是一个数据库。而客户端（无论是Java，C#，PHP），连接它的时候，就和连接一个普通的数据库没什么区别。之后，蓝色的“分布式管理器”会把请求发送给绿色的“分布式管理器”，绿色的“分布式管理器”负责连接数据库，负责具体的数据处理。

▶ACID的满足
A：原子性。因为数据的存储依赖于现成的数据库产品，所以原子性不成问题。
C：一致性和I：隔离性。因为数据分布在不同的数据库上，所以无法使用数据库的事物功能。而数据库的数量很多，即使是2阶段提交也会造成负载的增加和不稳定。所以，分布式管理器中必须要控制事物，也就是每条数据记录，都必须有一些控制事物信息的字段，如事物ID，事物状态等。而我们读取数据的时候，也必须参照这些事物的信息才可以。
如果一个事物更新3个数据库，在数据准备阶段都没有问题，但是提交阶段出错了（如，死锁，网络故障，机器故障），那么怎么保证事物的完整性？
个人觉得上面的云栖社区分享的分布式数据库中的方法不错：也就是上面绿色的“分布式管理器”，当它提交数据操作到数据库的时候，如果发现提交失败，那么就再次提交，直到成功为止。
D：存储性。因为数据的存储依赖于现成的数据库产品，所以存储性也不成问题。

▶蓝色和绿色的“分布式管理器”有什么区别？
按照个人的设想，他们应该是同一个东西，只不过在不同的配置下，发挥了不同的作用。
蓝色的“分布式管理器”，具有事物信息控制，连接数控制等功能。
绿色的“分布式管理器”，具有连接数据库，发送SQL，返回结果的功能。
所以，理论上，绿色的也可以换成蓝色的，这个层级可以一直延伸下去（当然层级过多没什么意义）。

▶如何实现sharding的功能？
最好是要求每个表固定一个名称的字段，然后蓝色的“分布式管理器”，会根据一定的规则（如取模，或者按数字区间分段），把数据分配到不同的数据库上。或者这个字段是可以配置的也可以。

▶分布到不同数据库上的数据，如何进行查询？
这应该是把数据sharding后最有挑战的工作。可以要求具有相关业务的表的数据，它们的sharding字段的值都相同，这样即使是多个表，相关联的部分就总是会分配到相同的数据库上。
比如表A和表B，前10000条数据，两个表的sharding字段的值都是A001，后10000条数据，两个表的sharding字段的值都是A002。这样至少可以保证前10000条数据都分配到一个数据库，后10000条数据也分配到一个数据库。

在查询的时候，如果查询条件指定了sharding字段，那就可以直接定位到数据库。如果不指定sharding字段，那么就每个数据库都进行查询，各个查询结果汇总到查询结果最大的那个绿色的“分布式管理器”。如果有order by, group 等对结果集进行合并的操作，就再创建一个临时表，把所有的结果放入这个临时表，然后进行 order by, group 等等处理。当然，这样会影响速度。

所以，如果可以的话，尽量避免联合查询，客户端分别查询出结果，由客户端来控制是最好的。这也要求事先对业务数据进行好的设计。

总之，上面是个人的一些设想，实现起来还是很复杂的，例如事物管理，连接管理，多个“分布式管理器”的协调，SQL语句的解析等等。