谈数据切分后的一些解决思路

当我们在谈去IOE时候，一定会带来的一个问题就是单节点本身的计算或存储能力不足而导致的数据水平或垂直切分，那在数据切分后如何解决这些问题就成为一个好的DaaS层能否真正发挥作用的重点。

对于分布式事务的问题，前面已经谈了很多，对于一个DaaS下针对逻辑库（一个逻辑库下面存在多个物理库节点）是可以通过标准的XA两阶段提交协议来实现分布式事务的，但是本身不仅仅是可靠性的问题，更加关键的是性能问题，特别是在高并发下的性能问题。因此在应用实现的过程中还是需要尽量避免使用分布式事务，仅仅在需要使用分布式事务的少数特殊场景通过显性声明的方式使用分布式事务。对于能够采用事务最终一致性BASE的场景，尽量是结合消息中间件的能力，采用最终一致性的方式；对于不能接受最终一致性的场景尽量采用事务补偿的方式来弥补事务失败造成的影响。

在数据拆分有原有的一个单库多表关联查询操作，往往会转变为一个跨库的join查询操作，而现在的针对mysql的daas方案很难真正的支撑到这种类型的操作，即使能够支持估计也很难真正达到一个高性能。在我们原来的设想中这些问题都简单的转化为应用层去解决，这务必是增加了一个应用层开发的复杂度和难度。而针对这种情况最好的方法是构建一个统一的领域服务层来解决，即最终的上层或顶层是关注的领域服务能力，虽然跨库的问题在DaaS层很难解决，但是在领域服务层却比较容易定制开发相应的服务来解决。

举例来说，一个采购订单查询，采购订单头和明细信息在一个逻辑库，而对于物料和供应商主数据在另外一个物理库，但是对于应用来说关注的是一个完整的采购订单信息。因此完全是可以在领域服务层提供一个采购订单查询的服务，在服务内部进行多次的DaaS层服务调用和组装来完成内部的复杂性。这也是我们常说的，但进行数据库拆分后，务必需要引入更加强壮的领域服务层的原因。

在数据拆分后还有一个比较难以解决的问题，即是对于业务系统的大量查询分析和统计功能的处理，由于我们的数据库进行了切分，导致这些功能已经类似于传统BI里面的OLAP层的功能特性。对于这种业务场景和需求，往往并没有完全的实时性需求，我们能够满足准实时性就可以了。因此对于这类功能推荐的方法仍然是需要将当前的各个分库里面的数据整合到NewSql数据库里面进行处理（Hive，infobright，impala)等，这些数据库需要满足的特性就是MPP+Share nothing架构特性，在这种架构下可以看到对于海量数据的分析和统计可以保证业务需要的准实时性要求，唯一需要考虑的是当前很多的NewSQL数据库都是一个读库，很难进行CUD等各种操作，因此转化后需要解决的问题就是对于业务库中的增量数据如何实时的更新到NewSQL数据库里面，注意是增量更新而不是类似当前很多方案里面的全库重新导入和生成，这也是在解决查询统计功能的一个难点。

对于MySQL的读写分离集群我们看到，随着slave节点的增加，为了保证master和slave节点之间的一致性，将会出现明细的延迟，也直接影响到应用CUD操作的性能。对于这个问题，当前可以考虑的解决方案就是要拆分为两级的读写分离集群，对于第一级的读节点保证高一致性和性能，对于第二级允许有较大的延迟，仅仅用于查询分析等。

在最近的一年过程中，我们对基于Mysql的DaaS层产品逐步的改进和完善，包括分布式事务，DDL操作，函数和存储过程支持，多租户和资源隔离，子查询，底层多种数据库适配和支持等做了大量的改进和性能测试。已经基本形成一个可以在实际业务中应用的产品，同时该产品也开始应用到我们自研的ESB服务总线中。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密