数据切分与整合方案.docxVIP

14.5?数据切分及整合方案 通 过前面的章节，已经清楚了通过数据库的数据切分可以极大地提高系统的扩展性。但是，数据库中的数据经过垂直和（或）水平切分被存放在不同的数据库主机之 后，应用系统面临的最大问题就是如何让这些数据源得到较好的整合，可能这也是很多读者非常关心的一个问题。本节主要的内容就是分析各种可以帮助我们实现数 据切分及数据整合的整体解决方案。 数据的整合很难依靠数据库本身来达到，虽然 MySQL 存在 Federated 存储引擎，可以解决部分类似的问题，但是在实际应用场景中却很难较好地运用。那该如何来整合这些分散在各个 MySQL 主机上的数据源呢？ 总的来说，存在两种解决思路： （1）在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，在模块内完成数据的整合； （2）通过中间代理层来统一管理所有的数据源，后端数据库集群对前端???用程序透明。 可能90%以上的人在面对这两种解决思路时都会倾向于选择第二种，尤其是系统不断庞大复杂的时候。确实，这是一个非常正确的选择，虽然短期内须要付出的成本可能会相对大一些，但对整个系统的扩展性来说，是非常有帮助的。 所以，对于第一种解决思路就不过多分析了，下面重点分析第二种思路中的一些解决方案。 1. 自行开发中间代理层 在决定选择通过数据库的中间代理层来解决数据源整合的架构方向之后，有不少公司（或者企业）自行开发了符合自身应用特定场景的代理层应用程序。 自行开发中间代理层可以最大程度地应对自身应用的特点，最大化定制个性化需求，在面对变化的时候也可以灵活应对。这应该是自行开发代理层最大的优势了。 当然，选择自行开发，享受个性化定制最大化乐趣的同时，自然也需要投入更多的成本来进行前期研发及后期的持续升级改进工作，而且本身的技术门槛可能也比简单的 Web 应用更高。所以，在决定选择自行开发之前，仍须要进行比较全面的评估。 由于自行开发更多时候考虑的是如何更好地适应自身应用系统，应对自身的业务场景，所以这里也不好分析太多。下面将主要分析当前比较流行的几种数据源整合解决方案。 2. 利用 MySQL Proxy 实现数据切分及整合 MySQL Proxy 是 MySQL 官方提供的一个数据库代理层产品，和 MySQL Server 一样，它也是一个基于 GPL 开源协议的开源产品。可用来监视、分析或传输它们之间的通讯信息。它的灵活性允许最大限度地使用它，目前具备的功能主要有连接路由、Query分析、Query过滤和修改、负载均衡，以及基本的 HA 机制等。 实际上，MySQL Proxy 本身并不具有上述所有的功能，而是提供了实现上述功能的基础。要实现这些功能，还须要我们自行编写 LUA 脚本。 MySQL Proxy 实际上是在客户端请求与 MySQL Server 之间建立了一个连接池。所有客户端请求都发向 MySQL Proxy，然后经由 MySQL Proxy进行相应的分析，判断出是读操作还是写操作，分发至对应的 MySQL Server 上。对于多节点 Slave 集群，也可以起到负载均衡的效果。如MySQL Proxy 基本架构图（图14-4）： 图14-4?MySQL Proxy 架构 通过上面的架构简图，可以清晰地看到 MySQL Proxy 在实际应用中所处的位置，以及能做的基本事情。MySQL Proxy 详细的实施细则在 MySQL 官方文档中有非常详细的介绍和示例，感兴趣的读者朋友可以直接从 MySQL 官方网站免费下载或者在线阅读，这里就不赘述。 3. 利用 Amoeba 实现数据切分及整合 Amoeba 是一个基于 Java 开发的，专注??解决分布式数据库数据源整合 Proxy 程序的开源框架，基于 GPL3 开源协议。目前，Amoeba 已经具有 Query 路由、Query 过滤、读写分离、负载均衡及 HA 机制等相关内容，如图14-5所示。 Amoeba 主要解决以下几个问题： （1）数据切分后复杂数据源整合； （2）提供数据切分规则并降低数据切分规则给数据库带来的影响； （3）降低数据库与客户端的连接数； （4）读写分离路由。 图14-5?Amoeba For MySQL架构 可以看出，Amoeba 所做的事情，正好就是通过数据切分来提升数据库的扩展性所需要的。 Amoeba 并不是一个代理层的 Proxy 程序，而是一个开发数据库代理层 Proxy 程序的框架，目前基于 Amoeba 所开发的 Proxy 程序有 Amoeba For MySQL 和 Amoeba For Aladin 两个。 Amoeba For MySQL是专门针对 MySQL 数据库的解决方案，前端应用程序请求的协议及后端连接的数据源数据库都必须