横向复制(X轴原则)

发布：2018-07-13 16:39:13 浏览：3882

横向扩展，即复制服务或数据库来分散事务负载。具有非常高读写比例(5:1或更高，越高越好)的数据库；口事务増长大于数据增长的系统。只需克隆服务并实施负载均衡；

对于数据库，要确保访问代码能够区分读写操作应用理由:复制数据和功能可以使事务更快地扩展。X轴拆分方法能够快速实现，但是只能提高事务的扩展性，不能提高数据的扩展性。

系统最难扩展的部分通常是数据库或者持久存储层。该问题可以追溯到EdgarF.Codd于1970年发表的论文4RelationalModelofDateforLargeSharedDataBanksl，该论文被认为首次引人了关系数据库管理系统(RDBMS)的概念。当今最流行的RDBMS，如Oracle、MYSQL和SQLServer等，如其名字所示，都用于管理数据元素之间的关系。这些关系可以存在于表内，也可以存在于表之间。大多数联机事务处理(OLTP)系统中的表都被规范化为第三范式?，即表中的所有记录都有相同的字段，所有非关键字段都不能只依赖于组合关键字的一部分，所有非关键字段都必须依赖于关键字。表中的每一列数据与其他列数据是有关系的。表之间的关系，通常称为外键。大多数使用数据库的应用都有赖于数据库基于其ACID属性支持并实施这些关系。维护和实施这些关系使得拆分数据库需要很多工作。

扩展数据库的技术之一是利用大多数应用和数据库执行的读操作比写操作多这一事实。我们的一个客户负责为顾客预定酒店，每次预定平均需要检索400次。每个预定都是1次写操作，而每次检索则是1次读操作，这样就导致了读写比例为400:1。创建数据的只读副本就可以轻松地扩展这种类型的系统。

根据数据的时间敏感度，有两种方法可以分布数据的只读副本。所谓时间敏感度，指的是相对于数据的写副本来说，只读副本有多么新，或者是否完全正确。在你坚持要求整个系统的数据是即时、同步且完全正确之前，仔细考虑一下这种系统的成本有多高吧。虽然完全同步数据是理想状态，但它的成本真的很高。况且，这种情况的性价比可能也并不是你想要的。

让我们再看看那个每写1次就需要400次读操作的预定系统吧。它处理的是顾客的预定，所以你可能认为他们要显示给顾客的是完全同步的数据。首先，要给顾客提供的一条预定数据必须保持400个数据集同步。其次，数据与主事务数据库之间有3秒、30秒或者90秒的不同步并不意味着该数据一定是错的，只是存在这种几率。该客户的系统中可能一直保存着10万条数据，每天预定的有10%。如果这些预定平均分布在一天中，那么大约一秒(0.86秒)完成一次预定。在机会均等的情况下，一位顾客想预定另一位顾客刚定的房间的可能性是0.1049%(假设数据每90秒同步一次)。当然，顾客还有0.19%的可能性选择已经预定过的房间，虽然这不太理想，但在顾客把预定的房间加入购物车之前再做次最后检査就可以避免这种情况。当然，每个应用的数据需求都不同，但从我们的讨论中，希望你能明白应该如何抵制所有数据必须实时同步的想法。

讨论过时间敏感度了，那么让我们来看看分布数据的方法。一种方法是在数据库前端使用缓存层。每次查询可以读取对象缓存，而不是每次都读数据库。只有当数据被标示为过期时，才需要查询主事务数据库，获取数据，更新缓存。考虑到有那么多优秀开源的键一值存储系统可以作为对象缓存，所以首先强烈推荐这种方法。

除了在应用层和数据库层之间增设对象缓存之外，还可以通过复制数据库来拆分数据。大多数主要的关系数据库系统都有某种类型的复制功能。MYSQL是通过主从数据库的概念来实现复制功能的。所谓主数据库就是执行写操作的主要数据库，从数据库是主数据库的只读副本。主数据库会把更新、插人、删除等操作记录在二进制的日志中。每个从数据库则是从主数据库请求二进制的日志，在自身重现这些操作。虽然这些操作是异步的，但是主数据库和从数据库中数据更新的延迟是非常小的。通常，这种实现都由几个从数据库或者只读副本构成，它们都配置在负载均衡器之后。应用向负载均衡器发起读请求，负载均衡器以循环計成者南连方式押该请求传递给只读副本。

我们把这种类型的拆分称为X轴拆分，AKF扩展立方中，它被表示为“X轴一横向复制'”。熟悉Web应用托管的开发者都会认同这样一个例子:在系统的Web层或应用层上，负载均衡器后的多个服务器上都运行着相同的代码。一旦负载均衡器收到请求后，它就把该请求分发到其中一个Web或应用服务器上进行处理。在应用层进行这种分发的好处是可以在负载均衡器后面放置成百上千的服务器，都运行同样的代码，处理类似的请求。

X轴原则不仅适用于数据库。Web服务器和应用服务器通常也能被轻松克隆，这样就能够把事务平均分配到多个系统上进行横向扩展。这种应用或Web服务的克隆实施起来相对比较容易，可以扩展能够处理的事务数量。遗憾的是，对于我们执行某些事务而必须操作的数据而言，该方法并不能帮助我们提高扩展性。在内存中缓存客户的专有数据或者不同功能特有的数据可能会造成扩展服务的瓶颈，很难在不影响客户响应时间的前提下扩展网站建设这些服务。要解决这种内存限制，需要利用扩展立方体的Y轴和Z轴。