应用服务化了，采用了分布式架构被部署在X86服务器上了。可数据呢？前面说过三层架构的应用展现层和业务逻辑层都可以做云化改造，唯独后端的数据层还因为数据一致性的问题停留在小型机上，成为了瓶颈（访问量大、扩展性差）。企业的核心数据库系统一般都采用“小型机＋高端商用数据库＋高端存储阵列”的集中式架构，也就是我们常说的IOE（IBM的小机、Oracle的数据库、EMC的存储）。这些设备价格昂贵不说，主要问题还是在于它只允许纵向（Scale-in)而不是横向扩展（Scale-out)。纵向扩展的意思就是在机器内加配置，加CPU，加内存，加硬盘，加到最后就加不了了；而横向扩展则能让您加机器，加节点；一台不够，两台，两台不够十台、百台、千台，形成了集群，形成了我们所说的分布式架构。这后种形式的扩展优越性不言而喻。那您肯定会说应用都划小了，怎么不把数据库也分了得了？

 

　　和应用切分一样，我们也可以对数据库通过一系列垂直和水平切分将数据分布到不同的DB服务器上，然后通过路由中间件访问特定的数据库。然而我们面临的困难首先是网络延时问题。因为原来依靠单机内部的通信现在要搬到外面来，成了机器与机器之间的通信，系统的开销一下子因为网络通信而增大。这种通信的代价会使系统单次提交的时间延迟。延迟提高会导致数据库锁定时间变长，使得性能比单机数据库具有明显差距。

 

　　分布式数据库面临的另一个问题是数据一致性问题。一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。而一致性又可以分为强一致性与弱一致性。强一致性就是在任意时刻，所有节点中的数据是一样的。弱一致性又有很多种类型，目前分布式系统中广泛实现的是最终一致性。所谓最终一致性，就是不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。也可以简单的理解为在一段时间后，节点间的数据会最终达到一致状态。

 

　　这些问题恰恰是分布式数据库的短板，就像它的可扩展性和可用性优点一样明显。鱼和熊掌不可兼得。根据著名的CAP理论，在分布式数据库应用中，任何分布式系统只可同时满足CAP其中两点，无法三者兼顾。

 

　　- Consistency(一致性), 数据一致更新，所有数据变动都是同步的；

 

　　- Availability(可用性), 好的响应性能，集群中某些节点宕掉了系统照用；

 

　　- Partition tolerance(分区容错性) ，可靠性。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

 

　　CA 系统是要求高可用并且实时一致性。单点数据库是符合这种架构的。

 

　　AP 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

 

　　CP 系统是要求满足一致性，分区容忍性，通常性能不是特别高。

 

　　我们不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。所以分布式的数据库也应该设计成多样的。比如将分析类型应用所需要的数据迁移至以Hadoop为主的分布式NoSQL数据库，将对实时一致性要求不是很高的一些应用迁移至分布式MySQL数据库等。这里有必要提一下分布式关系型数据库中的路由中间件。

 

　　数据库中间件对数据库云化改造或对整个IT架构的分布式改造起着非常重要的作用，它能提供的典型功能有分库分表、读写分离、负载均衡、Failover 等。

 

　　跟阿里数据库产品打过交道的人都知道它里面有个叫“头都大了”（TDDL，Taobao Distributed Data Layer）的路由代理，用它可以大大简化前端应用与后端数据库的连接，特别是当应用和数据库都成了分布式的时候，这是种N对N的连接。其实TDDL还并没有全部开源，近两年来有个在开源社区十分火爆的牛X产品叫“我的猫”（MyCat）。MyCat技术原理是它拦截了应用发送过来的SQL语句做特定分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此SQL发往后端的数据库节点，并将返回的结果做适当的处理，最终再返回给应用。MyCat发展到目前已经不再是一个单纯的MySQL代理了，它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，未来还会支持更多类型的数据库。