大型网站之存储瓶颈（综合篇）

原文：http://blog.jobbole.com/83475/

http://blog.jobbole.com/83473/

一、什么是大型网站

首先我们要思考一个问题，什么样的网站才是大型网站，从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标，懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标，如果按这些标准那么像hao123这样的网站就是大型网站了。

其实这种网站访问量非常大，并发数也非常高，但是它却能用最为简单的web技术来实现：我们只要保持网站的充分的静态化，多部署几台服务器，那么就算地球上所有人都用它，网站也能正常运行。

我觉得大型网站是技术和业务的结合，一个满足某些用户需求的网站只要技术和业务二者有一方难度很大，必然会让企业投入更多的、更优秀的人力成本实现它，那么这样的网站就是所谓的大型网站了。

某些网站在高并发下会报出503错误，503错误的含义是指网站服务端暂时无法提供服务的含义，503还表达了网站服务端现在有问题但是以后可能会提供正常的服务，对http协议熟悉的人都知道，5开头的响应码表达了服务端出现了问题，在我们开发测试时候最为常见的是500错误，500代表的含义是服务端程序出现了错误导致网站无法正常提供服务，500通常是服务端异常和错误所致，如果生产系统里发现了500错误，那么只能说明网站存在逻辑性的错误，这往往是系统上线前的测试做的不到位所致。

  503错误其实更加准确的回答应该是服务不可用，503错误在高并发的情况下90%的原因是数据库所致的。高并发的情况整个网站系统首先暴露出问题的是数据库，如果我们把整个网站系统比作一个盛水的木桶，那么木桶最短的那个板就是数据库了，一般而言网站的服务应用出问题都会是解决存储问题之后才会出现。
  数据库出现了瓶颈并不是程序存在逻辑性错误，数据库瓶颈的表现就是数据库因为承受了太多的访问后，数据库无法迅速的做出响应，严重时候数据库会拒绝进一步操作死锁在哪里不能做出任何反应。数据库犹如一把巨型的大锁，很多人争抢这个锁时候会导致这个大锁完全被锁死，最终请求的处理就停留在这个大锁上最终导致网站提示出503错误，503错误最终会传递到所有的客户端上，最终的现象就是全站不可用了。

在网站遇到存储瓶颈时，主要有以下的优化方向：

1、单库数据库

2、数据库读写分离

3、缓存技术

4、搜索技术

5、数据库的垂直拆分

6、数据库的水平拆分

7、业务级拆分

但是这些优化方向并不完全是个串行的过程，其实在实际的场景下这个过程往往是并行的，但是里面有一个元素应该是串行的或者说思考时候有个先后问题，那就是对数据库层的操作，具体如下：
单库数据库–>数据库读写分离–>数据的垂直拆分–>数据的水平拆分

而缓存技术和搜索技术在数据库的任意阶段里都可以根据实际的业务需求随时切入其中帮助数据库减轻不必要的压力。

二、慎用数据库的计算功能

我是以java工程师应聘进了我现在的公司，所以在我转到专职前端前，我也做过不少java的应用开发，当时我在公司的前辈告诉我，我们公司的数据库建模很简单，怎么个简单法了，数据库的表之间都没有外键，数据库不准写触发器，可以写写存储过程，但是存储过程决不能用于处理生产业务逻辑，而只能是一些辅助工作，例如导入导出写数据啊，后面听说就算是数据库做到了读写分离，数据之间同步也最好是用java程序做，也不要使用存储过程，除非迫不得已。开始我还不太理解这些做法，这种不理解不是指我质疑了公司的做法，而是我在想如果一个数据库我们就用了这么一点功能，那还不如让数据库公司为咋们定制个阉割版算了，不过在我学习了hadoop之后我有点理解这个背后的深意了，其实作为存储数据的数据库，它和我们开发出的程序的本质是一样的那就是：存储和计算，那么当数据库作为一个业务系统的存储介质时候，那么它的存储对业务系统的重要性要远远大于它所能承担的计算功能，当数据库作为互联网系统的存储介质时候，如果这个互联网系统成长迅速，那么这个时候我们对数据库存储的要求就会越来越高，最后估计我们都想把数据库的计算特性给阉割掉，当然数据库基本的增删改查我们是不能舍弃的，因为它们是数据库和外界沟通的入口，我们如果接触过具有海量数据的数据库，我们会发现让数据库运行的单个sql语句都会变得异常简洁和简单，因为这个时候我们知道数据库已经在存储这块承担了太多的负担，那么我们能帮助数据库的手段只能是尽量降低它运算的压力。

三、单库数据库

一个初建的网站往往用户群都是很小的，最简单的网站架构就能解决实际的用户需求，当然为了保证网站的稳定性和安全性，我们会把网站的应用部署到至少两台机器上，后台的存储使用数据库，如果经济实力允许，数据库使用单台服务器部署，由于数据是网站的生命线，因此我们常常会把部署数据库的服务器使用的好点，这个网站结构如下所示：



这个结构非常简单，其实大部分初建网站开发里往往业务逻辑没有企业级系统那么复杂，所以只要有个好的idea，建设一个新网站的成本是非常低的，所使用的技术手段也是非常的基本和简单，不过该图我们要准备三台服务器，而且还要租个机房放置我们的服务器，这些成本对于草根和屌丝还是非常高的，幸运的是当下很多大公司和机构提供了云平台，我们可以花费很少的钱将自己的应用部署到云平台上，这种做法我们甚至不用去考虑把应用、数据库分开部署的问题，更加进一步的降低了网站开发和运维的成本，但是这种做法也有一个问题，就是网站的小命被这个云平台捏住了，如果云平台挂了，俺们的网站服务也就跟着挂了。

通常我们要把网站服务应用部署到多台服务器，这么做的目的一般有两个：
保证网站的可用性，多台服务器部署应用，那么其中一些服务器挂掉了，只要网站还有服务器能正常运转，那么网站对外任然可以正常提供服务。
提高网站的并发量，服务器越多那么网站能够服务的用户，单位时间内能承载的请求数也就越大。

不过要做到以上两点，并不是我们简单将网站分开部署就可以满足的.其中一点就是Session同步的问题，关于此请参考《session同步问题》

四、数据库读写分离

写到这里一个婴儿般的网站就这样被我们创造出来了，我们希望网站能健康快速的成长，如果网站真的按我们预期成长了，那么一定会有一天我们制造的宝宝屋已经满足不了现实的需求，这个时候我们应该如何抉择了？换掉，全部换掉，使用新的架构例如我们以前长提的SOA架构，分布式技术，这个方法不错，但是SOA和分布式技术是很难的，成本是很高的，如果这时候我们通过添加几台服务器就能解决问题的话，我们绝对不要去选择什么分布式技术，因为这个成本太高了。上面我讲到几种session共享的方案，这个方案解决了应用的水平扩展问题，那么当我们网站出现瓶颈时候就多加几台服务器不就行了吗？那么这里就有个问题了，当网站成长很快，网站首先碰到的瓶颈到底是哪个方面的问题？

本人是做金融网站的，我们所做的网站有个特点就是当用户访问到我们所做的网站时候，目的都很明确就是为了付钱，用户到了我们所做的网站时候都希望能快点，再快点完成本网站的操作，很多用户在使用我们做的网站时候不太去关心网站的其他内容，因此我们所做的网站相对于数据库而言就是读写比例其实非常的均匀，甚至很多场景写比读要高，这个特点是很多专业服务网站的特点，其实这样的网站和企业开发的特点很类似：业务操作的重要度超过了业务展示的重要度，因此专业性网站吸纳企业系统开发的特点比较多。但是大部分我们日常常用的网站，我们逗留时间很长的网站按数据库角度而言往往是读远远大于写，例如大众点评网站它的读写比率往往是9比1。

12306或许是中国最著名的网站之一，我记得12306早期经常出现一个问题就是用户登录老是登不上，甚至在高峰期整个网站挂掉，页面显示503网站拒绝访问的问题，这个现象很好理解就是网站并发高了，大量人去登录网站，购票，系统挂掉了，最后所有的人都不能使用网站了。当网站出现503拒绝访问时候，那么这个网站就出现了最致命的问题，解决大用户访问的确是个超级难题，但是当高并发无法避免时候，整个网站都不能使用这个只能说网站设计上发生了致命错误，一个好的网站设计在应对超出自己能力的并发时候我们首先应该是不让他挂掉，因为这种结果是谁都不能使用，我们希望那些在可接受的请求下，让在可接受请求范围内的请求还是可以正常使用，超出的请求可以被拒绝，但是它们绝对不能影响到全网站的稳定性，现在我们看到了12306网站的峰值从未减少过，而且是越变越多，但是12306出现全站挂掉的问题是越来越少了。通过12036网站改变我们更进一步思考下网站的瓶颈问题。

排除一些不可控的因素，网站在高并发下挂掉的原因90%都是因为数据库不堪重负所致，而应用的瓶颈往往只有在解决了存储瓶颈后才会暴露，那么我们要升级网站能力的第一步工作就是提升数据库的承载能力，对于读远大于写的网站我们采取的方式就是将数据库从读写这个角度拆分，具体操作就是将数据库读写分离，如下图所示：



我们这时要设计两个数据库，一个数据库主要负责写操作我们称之为主库，一个数据库专门负责读操作我们称之为副库，副库的数据都是从主库导入的，数据库的读写分离可以有效的保证关键数据的安全性，但是有个缺点就是当用户浏览数据时候，读的数据都会有点延时，这种延时比起全站不可用那肯定是可以接受的。不过针对12306的场景，仅仅读写分离还是远远不够的，特别是负责读操作的副库，在高访问下也是很容易达到性能的瓶颈的，那么我们就得使用新的解决方案：使用分布式缓存，不过缓存的缺点就是不能有效的实时更新，因此我们使用缓存前首先要对读操作的数据进行分类，对于那些经常不发生变化的数据可以事先存放到缓存里，缓存的访问效率很高，这样会让读更加高效，同时也减轻了数据库的访问压力。至于用于写操作的主库，因为大部分网站读写的比例是严重失衡，所以让主库达到瓶颈还是比较难的，不过主库也有一个读的压力就是主库和副库的数据同步问题，不过同步时候数据都是批量操作，而不是像请求那样进行少量数据读取操作，读取操作特别多，因此想达到瓶颈还是有一定的难度的。听人说，美国牛逼的facebook对数据的任何操作都是事先合并为批量操作，从而达到减轻数据库压力的目的。

  读写分离方案主要是应用于网站读写比例严重失衡的网站，而互联网上绝大部分网站都是读操作的比例远远大于写操作，这是网站的主流，如果一个网站读写比例比较均衡，那么这个网站一般都是提供专业服务的网站，这种网站对于个人而言是一个提供生活便利的工具，它们和企业软件类似。大部分关注大型网站架构技术关心的重点应该是那种对于读写比例失衡的网站，因为它们做起来更加有挑战性。

将数据库进行读写分离是网站解决存储瓶颈的第一步，为什么说是第一步呢？因为读写分离从业务角度而言它是一种粗粒度的数据拆分，因此它所包含的业务复杂度比较低，容易操作和被掌控，从技术而言，实现手段也相对简单，因此读写分离是一种低成本解决存储瓶颈的一种手段，这种方案是一种改良方案而不是革命性的的方案，不管是从难度，还是影响范围或者是经济成本角度考虑都是很容易让相关方接受的。

 那么我们仅仅将数据库做读写分离为何能产生好的效率了？回答这个问题我们首先要了解下硬盘的机制，硬盘的物理机制就有一个大圆盘飞速旋转，然后有个磁头不断扫描这个大圆盘，这样的物理机制就会导致硬盘数据的顺序操作比随机操作效率更高，这点对于硬盘的读和写还算公平，但是写操作在高并发情况下会有点复杂，写操作有个特性就是我们要保证写操作的准确性，但是高并发下可能会出现多个用户同时修改某一条数据，为了保证数据能被准确的修改，那么我们通常要把并行的操作转变为串行操作，这个时候就会出现一个锁机制，锁机制的实现是很复杂的，它会消耗很多系统性能，如果写操作掺杂了读操作情况就更复杂，效率会更加低效，相对于写操作读操作就单纯多了，如果我们的数据只有读操作，那么读的性能也就是硬盘顺序读能力和随机读能力的体现，即使掺杂了并发也不会对其有很大的影响，因此如果把读操作和写操作分离，效率自然会得到很大提高。

五、使用缓存

虽然读写分离可以提升存储系统的效率，但是内存效率是硬盘的几万倍，因此我们也要使用内存缓存来提示效率。

缓存技术和搜索技术在数据库的任意阶段里都可以根据实际的业务需求随时切入其中帮助数据库减轻不必要的压力。例如，当网站的后台数据库还是单库的时候，数据库渐渐出现了瓶颈问题，而这个瓶颈又没有达到需要采取大张旗鼓做读写分离方案的程度，那么我这个时候可以考虑引入缓存机制。不过要合理的使用缓存我们首先要明确缓存本身的特点，这些特点如下所示：

特点一：缓存主要是适用于读操作，并且缓存的读操作的效率要远远高于从数据库以及硬盘读取数据的效率。

特点二：缓存的数据是存储在内存当中，因此当系统重启，宕机等等异常场景下，缓存数据就会不可逆的丢失，且无法恢复，因此缓存不能作为可靠存储设备，这就导致一个问题，缓存里的数据必须首先从数据库里同步到内存中，而使用缓存的目的就是为了解决数据库的读操作效率低下的问题，数据库的数据同步到缓存的操作会因为数据库的效率低下而在性能上大打折扣，所以缓存适合的场景是那些固定不变的数据以及业务对实时性变化要求不高的数据。

根据缓存的上述两个特点，我们可以把数据库里和上述描述类似操作的相关数据迁移到缓存里，那样我们就从数据库上剥离了那些对数据库价值不高的操作，让数据库专心做有价值的操作，这样也是减轻数据库压力的一种手段。

不过这个手段局限性很强，局限性主要是一台计算机了用于存储缓存的内存的大小都是远远要低于硬盘，并且内存的价格要远贵于硬盘，如果我们将大规模的数据从硬盘往内存迁移，从资源成本和利用率角度考虑性价比还是很低的，因此缓存往往都是用于转存那些不会经常变化的数据字典，以及经常会被读，而修改较少的数据，但是这些数据的规模也是有一定限度的，因此当单库数据库出现了瓶颈时候马上就着手进行读写分离方案的设计性价比还是很高的。

以下是一个大型网站的缓存系统示例：



关于缓存的更多内容请参考《memcache的一致性hash算法使用》

六、使用搜索技术

上面的方案我们可以保证在高并发下网站的稳定性，但是针对于读，如果数据量太大了，就算网站不挂掉了，用户能很快的在海量数据里检索到所需要的信息又成为了网站的一个瓶颈，如果用户需要很长时间才能获得自己想要的数据，很多用户会失去耐心从而放弃对网站的使用，那么这个问题又该如何解决了？

解决方案就是我们经常使用的百度，谷歌哪里得来，对于海量数据的读我们可以采用搜索技术，我们可以将数据库的数据导出到文件里，对文件建立索引，使用倒排索引技术来检索信息，我们看到了百度，谷歌有整个互联网的信息我们任然能很快的检索到数据，搜索技术是解决快速读取数据的一个有效方案，不过这个读取还是和数据库的读取有所区别的，如果用户查询的数据是通过数据库的主键字段，或者是通过很明确的建立了索引的字段来检索，那么数据库的查询效率是很高的，但是使用网站的人跟喜欢使用一些模糊查询来查找自己的信息，那么这个操作在数据库里就是个like操作，like操作在数据库里效率是很低的，这个时候使用搜索技术的优势就非常明显了，搜索技术非常适合于模糊查询操作。
六、数据库垂直拆分

业务再接着的增长下去，数据量也会随之越来越大了，这样发展下去总有一天主库也会产生瓶颈了，那么接下来我们又该如何解决主库的瓶颈了？方法很简单就是我们要拆分主库的数据了，那么我该以什么维度拆分数据了？一个数据库里有很多张表，不同的表都针对不同的业务，网站的不同业务所带来的数据量也不是不同的，这个时候系统的短板就是那些数据量最大的表，所以我们要把那些会让数据库产生瓶颈的表拆出来，例如电商系统里商品表和交易表往往数据量非常大，那么我们可以把这两种表建立在单独的两个数据库里，这样就拆分了数据库的压力，这种做法叫做数据垂直拆分，不过垂直拆分会给原有的数据库查询，特别是有事务的相关操作产生影响。关于此的更多内容请参考《大型网站之存储瓶颈（数据库的垂直拆分）》

最基本的读写分离的目的是为了解决数据库的某张表读写比率严重失衡的问题。

我们要分析下数据库的写操作，单独的写操作效率都是很高的，不管我们的写是单条记录的写操作，还是批量的写操作，这些写操作的数据量就是我们要去写的数据的大小，因此控制写的数据量的大小是一件很容易很天然的操作，所以这些操作不会造成数据库太大负担，详细点的话，对于数据库而言，新增操作无非是在原来数据后面追加些记录，而修改操作或者删除操作一般都是通过建立了高效索引的字段来定位数据后再进行的操作，因此它的性能也是非常高的。但是如果有大量的并发写操作，而产生锁竞争的话，就会变得低效了。而读操作看起来比写操作简单（例如：读操作不存在像事务这些乌七八糟因素的干扰），但是当读操作面对海量数据时候就严重挑战着数据库和硬盘的极限能力，因此读操作很容易产生瓶颈问题，而且这个瓶颈不管问题表是否读写失衡都会面临的。

另外，像oracle和mysql这样鼎鼎大名的关系数据库默认的最大连接数是100，一般上了生产环境我们可能会设置为150或者200，这些连接数已经到了这些关系数据库的最大极限了，如果再加以提升，数据库性能会严重下降，最终很有可能导致数据库由于压力过大而变成了一个巨锁，最终导致系统发生503的错误，如是我们就会想到采用读写分离方案，将数据库的读操作迁移到专门的读库里，如果系统的负载指标和我列举的例子相仿，那么迁移的读库甚至不用做什么垂直拆分就能满足实际的业务需求，因为我们的目的只是为了减轻数据库的连接压力。

七、数据库的水平拆分
当我们的系统做完了读写分离，数据垂直拆分后，我们的网站还在迅猛发展，最终一定又会达到新的数据库瓶颈，当然这些瓶颈首先还是出现在那些数据量大的表里，这些表数据的处理已经超出了单台服务器的能力，这个时候我们就得对这个单库单表的数据进行更进一步的拆分，也就是将一张表分布到两台不同的数据库里，这个做法就是叫做数据的水平拆分了。关于此的更多内容请参考《大型网站之存储瓶颈（数据库的水平拆分）》

八、业务级的拆分

到底是什么因素促使我们去做数据库的垂直拆分和水平拆分的呢？答案很简单就是业务发展的需求，前文里的水平拆分技术方案基本都是抛弃千变万化的业务规则的限制，尽量将水平拆分的问题归为一个简单的技术实现方案，而纯技术手段时常是看起来很美，但是到了面对现实问题时候，常常会变得那么苍白和无力。因此对于存储瓶颈，我们应该更多的考虑业务的优化。关于此的更多内容请参考《大型网站存储瓶颈（业务级的拆分）》

九、总结

启迪一：数据库的读写分离不是简单的把主库数据导入到读库里就能解决问题，读数据库和写数据的分离的目的是为了让读和写操作不能相互影响效率。

启迪二：解决读的瓶颈问题的本质是减少数据的检索范围，数据检索的范围越小，读的效率也就越高；

启迪三：数据库的垂直拆分和水平拆分首先不应该从技术角度进行，而是通过业务角度进行，如果数据库进行业务角度的水平拆分，那么拆分的维度往往是要根据该表的某个字段进行的，这个字段选择要有一定原则，这个原则主要是该字段的维度的粒度不能过细，该字段的维度范围不能经常的动态发生变化，最后就是该维度不能让数据分布严重失衡。

回到现实的开发里，对于一个数据库做拆表，分表的工作其实是一件很让人恼火的工作，这主要是有以下原因所造成的，具体如下所述：

原因一：一个数据库其实容纳多少张表是有一定限制的，就算没有超过这个限制，如果原库本来有30张表，我们拆分后变成了60张，接着是120张，那么数据库本身管理这么多表也会消耗很多性能，因此公司的DBA往往会控制那些过多分表的行为。

原因二：每次拆表后，都会牵涉到历史数据的迁移问题，这个迁移风险很大，迁移方案如果设计的不完善可能会导致数据丢失或者损坏，如果关键数据发生了丢失和损坏，结果可能非常致命。因此在设计数据库分表分库方案时候我们要尽量让受影响的数据范围变得最小。

原因三：每次拆表和分表都会让系统的相关方绷紧神经，方案执行后，会有很长时间的监控和观察期，所以拆数据库时常是一件令人讨厌的事情。

原因四：为了保证新方案执行后确保系统没有问题，我们常常会让新旧系统并行运行一段时间，这样可以保证如果新方案出现问题，问题的影响面最低，但是这种做法也有一个恶果就是会导致数据迁移方案要进行动态调整，从而增加迁移数据的风险

因此当公司不得不做这件事情时候，公司都会很自然去考虑第三种解决方案，第三种解决方案是指尽量不改变原数据库的功能，而是另起炉灶，使用新技术来解决我们的问题，例如前文所说的搜索技术解决数据库like的低效问题就是其中方案之一，该方案只要我们将数据库的表按一定时间导入到文件系统，然后对文件建立倒排索引，让like查询效率更好，这样就不用改变原数据库的功能，又能减轻数据库的压力。

现在常用的第三种解决方案就是使用NoSql数据库，NoSql数据库大多都是针对文件进行的，因此我们可以和使用搜索引擎那样把数据导入到文件里就行了，NoSql基本都采用Key/Value这种简单的数据结构，这种数据结构和关系数据库比起来更加的灵活，对原始数据的约束最少，所以在NoSql数据库里建表我们可以很灵活的把列和行的特性交叉起来用，这句话可能很多人不太理解，下面我举个例子解释下，例如hadoop技术体系里的hbase，hbase是一个基于列族的数据库，使用hbase时候我们就可以通过列来灵活的拆分数据，比如我们可以把中国的省份作为一个列，将该省份的数据都放入到这个列下面，在省这个维度下我们可以接着在定义一个列的维度，例如软件行业，属于软件行业的数据放在这个列下面，最终提供用户查询时候我们就可以减少数据检索的范围，最终达到提升查询效率的目的。由此可见当我们用惯了关系数据库后，学习像hbase这样的Nosql数据库我们会非常的不适应，因为关系数据库的表有固定模式，也就是我们常说的结构化数据，当表的定义好了后，就算里面没有数据，那么这个结构也就固定了，我们使用表的时候都是按这个模型下面，我们几乎感觉不到它，但是到了hbase的使用就不同了，hbase使用时候我们都在不停的为数据增加结构化模型，而且这个维度是以列为维度的，而关系数据库里列确定后我们使用时候是无法改变的，这就是学习hbase的最大困难之一。Hbase之所以这么麻烦的设计这样的计算模型，终极目的就是为了让海量数据按不同维度存储起来，使用时候尽全力检索数据检索的数量，从而达到海量数据快速读取的目的。