【编者按】本文转自博客园的夏天的森林，在看这篇之前，大家可以移步看大型网站架构改进历程：存储的瓶颈（一）、（二）、（三）、（四）。
上文里我遗留了两个问题，一个问题是数据库做了水平拆分以后，如果我们对主键的设计采取一种均匀分布的策略，那么它对于被水平拆分出的表后续的查询操作将有何种影响，第二个问题就是水平拆分的扩容问题。这两个问题在深入下去，本系列就越来越技术化了，可能最终很多朋友读完后还是没有找到解决实际问题的启迪，而且我觉得这些问题都是像BAT这样巨型互联网公司才会认真思考的，因此本篇我打算换个角度来阐述本文的后续内容。
这里我们首先要明确一个问题，到底是什么因素促使我们去做数据库的垂直拆分和水平拆分的呢？答案很简单就是业务发展的需求，前文里的水平拆分技术方案基本都是抛弃千变万化的业务规则的限制，尽量将水平拆分的问题归为一个简单的技术实现方案，而纯技术手段时常是看起来很美，但是到了面对现实问题时候，常常会变得那么苍白和无力。
水平拆分
水平拆分的难题里我还有个难题没有讲述，就是水平拆分后对查询操作的影响，特别是对单表查询的影响，这点估计也是大伙最为关心的问题，今天我不在延着水平拆分的技术手段演进是阐述上文的遗留问题，而是我要把前面提到的技术手段和一些典型场景结合起来探讨如何解决网站存储的瓶颈问题。
前文中我总结过一个解决存储瓶颈的脉络，具体如下：
单库数据库–>数据库读写分离–>缓存技术–>搜索技术–>数据的垂直拆分–>数据的水平拆分
这个脉络给一些朋友产生了误解，就是认为这个过程应该是个串行的过程，其实在实际的场景下这个过程往往是并行的，但是里面有一个元素应该是串行的或者说思考时候有个先后问题，那就是对数据库层的操作，具体如下：
单库数据库–>数据库读写分离–>数据的垂直拆分–>数据的水平拆分
而缓存技术和搜索技术在数据库的任意阶段里都可以根据实际的业务需求随时切入其中帮助数据库减轻不必要的压力。例如，当网站的后台数据库还是单库的时候，数据库渐渐出现了瓶颈问题，而这个瓶颈又没有达到需要采取大张旗鼓做读写分离方案的程度，那么我这个时候可以考虑引入缓存机制。不过要合理的使用缓存我们首先要明确缓存本身的特点，这些特点如下所示：
特点一：缓存主要是适用于读操作，并且缓存的读操作的效率要远远高于从数据库以及硬盘读取数据的效率。
特点二：缓存的数据是存储在内存当中，因此当系统重启，宕机等等异常场景下，缓存数据就会不可逆的丢失，且无法恢复，因此缓存不能作为可靠存储设备，这就导致一个问题，缓存里的数据必须首先从数据库里同步到内存中，而使用缓存的目的就是为了解决数据库的读操作效率低下的问题，数据库的数据同步到缓存的操作会因为数据库的效率低下而在性能上大打折扣，所以缓存适合的场景是那些固定不变的数据以及业务对实时性变化要求不高的数据。
根据缓存的上述两个特点，我们可以把数据库里和上述描述类似操作的相关数据迁移到缓存里，那样我们就从数据库上剥离了那些对数据库价值不高的操作，让数据库专心做有价值的操作，这样也是减轻数据库压力的一种手段。
不过这个手段局限性很强，局限性主要是一台计算机了用于存储缓存的内存的大小都是远远要低于硬盘，并且内存的价格要远贵于硬盘，如果我们将大规模的数据从硬盘往内存迁移，从资源成本和利用率角度考虑性价比还是很低的，因此缓存往往都是用于转存那些不会经常变化的数据字典，以及经常会被读，而修改较少的数据，但是这些数据的规模也是有一定限度的，因此当单库数据库出现了瓶颈时候马上就着手进行读写分离方案的设计性价比还是很高的。
前文我讲到我们之所以选择数据库读写分离是主要原因是因为数据库的读写比例严重失衡所致，但是做了读写分离必然有个问题不可避免，写库向读库同步数据一定会存在一定的时间差，如果我们想减小读库和写库数据的时间差，那么任然会导致读库因为写的粒度过细而发生部分性能的损失，但是时间差过大，或许又会无法满足实际的业务需求，因此这个时间差的设计一定要基于实际的业务需求合理的设计。
同步的时间差的问题还是个小问题，也比较好解决，但是如何根据实际的业务需求做读写分离这其实还是非常有挑战性的，这里我举个很常见的例子来说明读写分离的难度问题，我们这里以淘宝为例，淘宝是个C2C的电商网站，它是互联网公司提供一个平台，商家自助接入这个平台，在这个平台上卖东西，这个和线下很多大卖场的模式类似。
淘宝是个大平台，它的交易表里一定是要记下所有商户的交易数据，但是针对单个商家他们只会关心自己的网店的销售数据，这就有一个问题了，如果某一个商家要查询自己的交易信息，淘宝就要从成千上万的交易信息里检索出该商家的交易信息，那么如果我们把所有交易信息放在一个交易表里，肯定有商家会有这样的疑问，我的网店每天交易额不大，为什么我查询交易数据的速度和那些大商家一样慢了？那么我们到底该如何是解决这样的场景了？
碰到这样的情况，当网站的交易规模变大后就算我们把交易表做了读写分离估计也是没法解决实际的问题，就算我们做的彻底点把交易表垂直拆分出来估计还是解决不了问题，因为一个业务数据库拥有很多张表，但是真正压力大的表毕竟是少数，这个符合28原则，而数据库大部分的关键问题又都是在那些数据压力大的表里，就算我们把这些表单独做读写分离甚至做垂直拆分，其实只是把数据库最大的问题迁移出原来数据库，而不是在解决该表的实际问题。
如果我们要解决交易表的问题我们首先要对交易表做业务级的拆分，那么我们要为交易表增加一个业务维度：实时交易和历史交易，一般而言实时交易以当天及当天24小时为界，历史交易则是除去当天交易外的所有历史交易数据。实时交易数据和历史交易数据有着很大不同，实时交易数据读与写是比较均衡的，很多时候估计写的频率会远高于读的频率，但是历史交易表这点上和实时交易就完全不同了，历史交易表的读操作频率会远大于写操作频率，如果我们将交易表做了实时交易和历史交易的拆分后，那么读写分离方案适合的场景是历史交易查询而非实时交易查询，不过历史交易表的数据是从实时交易表里同步过来的，根据这两张表的业务特性，我们可以按如下方案设计，具体如下：
只有在前进中不断学会选择，学会体会，学会欣赏。
