数据存储服务器集群的伸缩性对数据的持久性和可用性提出了更高的要求。

缓存的目的是加快数据读取速度并减轻数据存储服务器的负载压力，因此部分缓存的丢失不影响业务的正常处理，因为数据还可以从数据库等存储服务器上获取。

而数据存储服务器必须保证数据的可靠性存储，任何情况下都必须保证数据的可用性和正确性。

6.4.1 关系数据库集群的伸缩性设计

关系数据库集群的伸缩性设计也是要基于关系数据库提供的基本的数据复制功能，才能保证数据的正确性。

在上面这种架构中，虽然多台服务器部署MySQL实例，但是它们的角色有主从之分，数据写操作都在主服务器上，由主服务器将数据同步到集群中其他从服务器，数据读操作及数据分析等离线操作在从服务器上进行。

数据分库：根据业务分割，不同业务数据表部署在不同的数据库集群上。这种方式制约条件是跨库的表不能进行Join操作。

对于单表数据仍然很大的表，还需要进行分片，将一张表拆分开分别存储在多个数据库中。

目前成熟的支持数据分片的分布式关系数据库产品主要有开源的Amoeba和Cobar。这两个产品有相似的架构设计，以Cobar为例，其部署模型如下图所示：

 可以看到部署图上，其介于应用服务器和数据库服务器之间（Cobar也支持非独立部署，以lib的方式和应用程序部署在一起）。

应用程序通过JDBC驱动访问Cobar集群，Cobar服务器根据SQL和分库规则分解SQL，分发到MySQL集群不同的数据库实例上执行（每个MySQL实例都部署为主从结构，保证数据高可用）。

Cobar系统组件模型如下图：

Cobar的执行流程是什么？一条SQL经过Cobar，Cobar怎么处理？

前端通信模块负责和应用程序通信，接收到SQL请求(select * from user where userid in (12,22,23))后转交给SQL解析模块，SQL解析模块解析获得SQL中的路由规则查询条件(userid in (12,22,23))再转交给SQL路由模块，SQL路由模块根据路有规则配置(userid为偶数路由至数据库A，userid为奇数路由至数据库B)将应用程序提交的SQL分解成两条SQL(select * from users where userid in(12,22);select * from users where userid in (23);)转交给SQL执行代理模块，发送至数据库A和数据库B分别执行。

数据库A和数据库B的执行结果返回至SQL执行模块，通过结果合并模块将两个返回结果集合并成一个结果集，最终返回给应用程序，完成在分布式数据库中的一次访问请求。

Cobar如何做集群伸缩？

Cobar的伸缩有两种：Cobar服务器集群的伸缩和MySQL服务器集群的伸缩。

Cobar服务器可以看作是无状态的应用服务器，其伸缩可以简单的使用负载均衡的手段实现。

MySQL中存储着数据，要想保证集群扩容后数据一致负载均衡，必须要做数据迁移，将集群中原来机器中的数据迁移到新添加的机器中。如下图所示：

 具体迁移哪些数据可以利用一致性hash算法，尽可能使需要迁移的数据量最少。

但是迁移数据需要遍历数据库中每条记录(的索引)，重新进行路由计算确定其是否需要迁移，会对数据库访问造成一定压力。

实践中，Cobar利用了MySQL的数据同步功能进行数据迁移。数据迁移不是以数据为单位，而是以Schema为单位。

在Cobar集群初始化时，在每个MySQL实例创建多个Schema(根据业务远景规划未来集群规模，如集群最大规模为1000台数据库服务器，那么总的初始Schema数>=1000)。

集群扩容时，从每个服务器中迁移部分Schema到新的机器中，由于迁移以Schema为单位，迁移过程可以使用MySQL的同步机制，如下图所示：

 同步完成时，即新机器中Schema数据和原机器中Schema数据一致的时候，修改Cobar服务器的路由配置，将这些Schema的IP修改为新机器的IP，然后删除原机器的相关Schema，完成MySQL集群扩容。

在整个分布式关系数据库的访问请求过程中，Cobar服务器处理消耗的时间是很少的，时间花费主要在MySQL数据库端。由于Cobar代替应用程序连接数据库，数据库只需要维护更少的连接，减少不必要的资源消耗，改善性能。

由于Cobar路由后只能在单一库实例上处理查询请求，因此无法执行跨库的JOIN操作，当然更不能执行跨库的事务处理。

当网站业务面临不停增长的海量业务数据存储压力时，又不得不利用分布式关系数据库的集群伸缩能力，这时就必须从业务上回避分布式关系数据库的各种缺点：避免事务或利用事务补偿机制代替数据库事务；分解数据访问逻辑避免JOIN操作等。

对于跨库JOIN，只能通过调用另一模块的接口访问，不能直接访问其数据库，接口访问后，数据在应用程序内部处理合并、映射。

除了上面提到的分布式数据库，还有一类分布式数据库可以支持JOIN操作执行复杂的SQL查询，如GreenPlum。但是这类数据库的访问延迟比较大（可以想象，JOIN操作需要在服务器间传输大量的数据），因此一般使用在数据仓库等非实时业务中。

6.4.2 NoSQL数据库的伸缩性设计

HBase为可伸缩海量数据存储而设计，实现面向在线业务的实时数据访问。

HBase的伸缩性主要依赖其可分裂的HRegion及可伸缩的分布式文件系统HDFS实现。

HBase整体架构如下图所示：

 HBase中，数据以HRegion为单位进行管理，也就是说应用程序如果想要访问一个数据，必须先找到HRegion，然后将数据读写操作提交给HRegion，由HRegion完成存储层面的数据操作。

每个HRegion中存储一段Key值区间[key1,key2)的数据，HRegionServer是物理服务器，每个HRegionServer上可以启动多个HRegion实例。当一个HRegion中写入的数据太多，达到配置的阈值时，HRegion会分裂成两个HRegion，并将HRegion在整个集群中进行迁移，以使HRegionServer的负载均衡。

所有HRegion的信息(存储的Key值区间、所在HRegionServer地址、访问端口号等)都记录在HMaster服务器上，为了保证高可用，HBase启动多个HMater，并通过Zookeeper(一个支持分布式一致性的数据管理服务)选举出一个主服务器，应用程序通过Zookeeper获得主HMaster的地址，输入Key值获得这个Key所在的HRegionServer地址，然后请求HRegionServer上的HRegion，获得需要的数据。调用时序图如下：

数据写入过程也是一样，需要先得到HRegion才能继续操作，HRegion会把数据存储在若干个叫作HFile格式的文件中，这些文件使用HDFS分布式文件系统存储，在整个集群内分布并高可用。当一个HRegion中数据量太多时，HRegion(连同HFile)会分裂成两个HRegion，并根据集群中服务器负载进行迁移，如果集群中有新加入的服务器，也就是说有了新的HRegionServer，由于其负载较低，也会把HRegion迁移过去并记录到HMaster，从而实现HBase的线下伸缩。

6.5 小结

稍有规模的网站都必须是可伸缩的，伸缩性设计使复杂的，没有通用的、完美的解决方案和产品

网站伸缩性往往和可用性、正确性、性能等耦合在一起，改善伸缩性可能会影响一些网站的其他特性，网站架构师必须对网站的商业目标、历史演化、技术路线了然于胸，甚至还需要综合考虑技术团队的知识储备和结构、管理层的战略愿景和规划，才能最终做出对网站伸缩性架构最合适的决策。

一个具有良好伸缩性架构设计的网站，其设计总是走在业务发展的前面，在业务需要处理更多访问和服务之前，就可以做好充足准备，当业务需要时，只需要购买或者租用服务器简单部署实施就行了，技术团队亦可高枕无忧。反之，设计和技术走在业务的后面，采购来的机器根本就没办法加入集群，勉强加了进去，却发现瓶颈不在这里，系统整体处理能力依然上不去。技术团队每天加班，却总时拖公司发展的后腿。架构师对网站伸缩性的把握，一线之间，天堂和地狱。

高手定律：这个世界只有遇不到的问题，没有解决不了的问题，高手之所以成为高手，是因为他们遇到了常人很难遇到的问题，并解决了。

百度有很多搜索高手，淘宝有很多海量数据高手，QQ有很多高并发业务的高手。

一个100万用户的网站，不会遇到1亿用户同时在线的问题。

一个拥有100万件商品网站的工程师，可能无法理解一个拥有10亿件商品网站的架构。

救世主定律：遇到问题，分析问题，最后总能解决问题。如果遇到问题就挖高手，最后怕是只有彼此抱怨和伤害。