大型网站架构技术演进：从访问量到并发量的深度思考

hwyzw

    来源：//p/.html

    1. 铭文

    不久前，该公司邀请了一位互联网行业的技术专家与我们一起进行了大规模的网站架构培训。两天十二个小时的信息量非常大，知识的广度和难度也很大。训练结束后，我很难完成它。整理完所听到的所有知识后，今天我改变了想法，对这次培训进行了反思。这个想法是通过我现在的经验和技术水平来思考大型网站的技术演变。

    2、什么网站是大型网站？

    首先我们要思考一个问题，什么样的网站才是大型网站？从网站的技术指标角度考虑这个问题，人们很容易犯错误，认为网站的访问量是一个衡量指标。稍微了解一点的人可能会认为，是以单位时间内网站并发量的大小作为指标。如果按照这些标准，这样的网站就是一个大型网站，如下图所示：

    其实这种网站的访问量非常大，并发量非常高，但是用最简单的Web技术就可以实现：只要我们保持网站完全静态，多部署几台服务器，甚至如果地球上的每个人都使用它，网站就会正常运行。

    我认为大型网站是技术和商业的结合。对于一个满足一定用户需求的网站，只要其中一个技术和业务方面难度很大，公司就必然会投入更多更好的人力成本来实现。所以这样的网站就是所谓的大型网站。

    3.新建网站

    新建网站的用户群通常较小。最简单的网站架构就能解决用户的实际需求。当然，为了保证网站的稳定性和安全性，我们会将网站应用部署到至少两台机器上。上面，数据库用于后端存储。如果经济实力允许，数据库部署在单台服务器上。由于数据是网站的生命线，所以我们经常使用部署数据库的服务器比较好。网站结构如下：

    这个结构非常简单。事实上，大多数初始网站开发中的业务逻辑并不像企业级系统那么复杂。因此，只要你有一个好的想法，建立一个新网站的成本是非常低的，所使用的技术手段也非常高。很基本很简单，但是在这张图中我们需要准备三台服务器，并租一个机房来放置我们的服务器。这些成本对于草根和失败者来说仍然非常高。

    幸运的是，现在很多大公司和机构都提供云平台。我们可以花很少的钱在云平台上部署我们的应用程序。这样，我们甚至不用考虑应用程序和数据库分开部署的问题。更进一步这样就大大降低了网站开发和运维的成本，但是这种做法也存在一个问题，那就是网站的生命被云平台掐住了。如果云平台出现故障，我们的网站服务也会出现故障。

    4、网站遇到的问题

    这里先说一下使用服务器独立部署网站的问题。如果我们想使用多台服务器来部署网站服务应用，这样做的目的一般有两个：

   

    为了保证网站的可用性，如果应用部署在多台服务器上，那么就会出现部分服务器挂掉的情况。只要网站和服务器能够正常运行，网站仍然可以向外界提供正常的服务。

    增加网站的并发量。服务器越多，网站可以服务的用户就越多，单位时间可以处理的请求数量也就越多。

    但是，要实现以上两点，我们不能简单地单独部署网站，因为大多数网站都需要在用户使用时维护用户的状态。具体一点就是网站必须记住这个请求是属于哪一个。客户，这种状态通过网站开发中的会话反映出来。

    单独部署的Web应用服务需要解决的首要问题之一是保持不同物理部署服务器之间的同步，以便当用户第一次请求访问服务器A并第二次请求访问服务器B时，网站保持不变相同。知道这两个请求来自同一个人，解决方案就很简单了：服务器A和服务器B上的信息必须时刻保持同步，那么如何保证两个服务器之间的信息同步呢？

    为了回答上述问题，我们首先需要了解其机制。信息存储在 Web 容器的内存中。 Web 容器将为连接到它的每个客户端生成一个值。该值将由 Web 容器放置。在http协议中的下，当客户端处理响应时，客户端会在本地存储这个值。来自用户的每个后续请求都会将此值传递到服务器。服务器会查找内存中存储的用户内容。 ，内存中的数据结构是map格式的。

    5、服务器越多，并发速度就越慢。

    为了保证不同服务器之间的共享，最直接的解决办法就是在服务器之间不断的传输和复制。例如Java开发中常用的容器就采用了这种方案。我之前测试过这个同步的性能。发现当需要同步的Web容器较多时，Web应用所能承载的并发数并不会因为服务器的增加而线性增加。当服务器数量达到临界值时，整个Web应用的并发数甚至会减少。为什么？是这个吗？

    原因很简单。不同服务器之间的传输和复制会消耗服务器本身的系统资源。服务器数量越多，消耗的资源就越多。当用户请求越来越频繁时，系统资源消耗也会越来越大。如果我们部署更多服务器的目的只是为了保证系统的稳定性，那么采用这种方案是很好的。不过，最好部署较少的 Web 应用程序，这样就不会影响 Web 应用程序的性能。如果我们还想提高网站并发量高的话，就必须采用其他的解决方案。

    现在最常用的解决方案是使用独立的缓存服务器，即将数据存储在独立的服务器上。如果你觉得拥有服务器不安全，可以使用这样的分布式缓存服务器进行存储，这样既可以满足网站稳定性问题，又可以提高网站的并发能力。

    不过，早期的淘宝比较巧妙地解决了这个问题。他们将信息直接存储在浏览器中。每个请求信息都会随着http一起传递到Web服务器，从而避免了Web服务器之间的信息同步问题。这个解决方案会受到很多人的批评。批评的原因是众所周知它不安全。如果有人恶意拦截信息，网站岂不是不安全？这个问题的答案确实很难说，但我认为我们只是跟踪用户的状态，将其存储在存储中实际上没什么大不了的。

    事实上，对于如此专业的淘宝来说，这样做是相当有意义的。我还记得本文开头提到的那个网站。是一个可以承载高并发的网站。它能做到这一点的原因很简单。这是一个静态网站。静止的。该网站的特点是不需要记录用户的状态。动态网站的服务器不需要使用宝贵的系统资源来存储大量的会话信息，从而有更多的系统资源来处理请求。早期淘宝会有这样的客户，所以淘宝网站上就采用了这种方案。它在建筑中已经使用了很长时间。

    在我的公司，客户端的请求在到达Web服务器之前，会先到F5。 F5是一个用于负载均衡的硬件设备。其作用是将用户请求均匀分配到后台服务器集群。 F5是一个硬件设备。负载均衡解决方案，如果我们没有那么多钱买这样的设备，还有软件负载均衡解决方案。这个解决方案就是大名鼎鼎的LVS！

    除了能够分发请求之外，这些负载均衡设备还具有一种能力。该能力是根据http协议的特点设计的。一个http请求在从客户端到达最终存储服务器之前可能会经过许多不同的设备。如果我们把一个请求比作高速公路上的汽车。这些设备也可以称为这些节点，它们是高速公路上的收费站。这些收费站可以根据自己的需要改变http报文的内容，因此负载均衡设备可以记住每个值对应的后台服务器。

    当带有值的请求经过负载均衡设备时，负载均衡设备会根据该值直接查找指定的Web服务器。这种方法有一个合适的名字叫做粘性。这种方式也比将信息放在不同服务器上的方式要好。复制效率更高，但是这种方法还是比保存效率低，而且对网站的稳定性也有一定的影响。如果服务器挂掉，则连接到该服务器的用户会话将失效。

    要解决的问题本质是解决存储问题，其本质是解决网站的存储问题。一个新建的网站在运营初期需要解决的问题基本上都是由存储引起的。上面我提到，现在很多新的Web应用都会将服务器部署在云平台上。一个好的云平台可能会帮助我们解决负载均衡和同步的问题，但是云平台有一个很难解决的问题：数据库的存储问题。如果我们使用的云平台发生重大事故，导致云平台中存储的数据丢失，这是否会导致我们在云平台中的数据库丢失呢？信息也会丢失。虽然这件事发生的概率不高，但是还是有可能发生这种情况的。尽管许多云平台声称可靠，但真正的可靠性并不为任何参与游戏的人所知。要知道，所以我们在使用云平台的时候首先考虑的就是数据的备份。如果发生数据丢失，对于一个快速增长的网站来说可能是非常致命的。

    6. 网站瓶颈

   

    当我们写这篇文章时，我们已经创建了一个婴儿般的网站。希望网站能够健康快速的发展。如果网站真的按照我们的预期发展，那么总有一天我们建造的婴儿屋将不再满足现实。需求，这个时候我们应该如何做决定呢？替换它，全部替换，采用新的架构，比如我们之前提到的SOA架构和分布式技术。这个方法不错，但是SOA和分布式技术难度很大，成本很高。如果这个时候通过增加几台服务器就能解决问题的话，我们绝对不应该选择任何分布式技术，因为成本太高了。上面我讲了几个分享的解决方案。该方案解决了应用程序横向扩展的问题。那么当我们的网站出现瓶颈的时候，多加几台服务器不就可以了吗？所以这里有一个问题。当网站快速增长时，网站首先遇到的瓶颈是什么？

    我在一家金融网站工作。我们网站的一个特点是，当用户访问我们的网站时，他们的目的非常明确，就是付费。当用户到达我们的网站时，他们希望速度更快。快速完成本网站的运营。很多用户在使用我们网站的时候并不太关心网站的其他内容，所以我们和数据库相比，网站的读写比例其实是非常均匀的，甚至很多时候写入比例是高于读取比例的。场景。这个功能是很多专业服务网站的特点。事实上，此类网站的特点与企业开发的特点非常相似：业务运营的重要性超过了业务呈现的重要性，因此专业网站吸收了更多企业系统开发的特点。但对于我们日常生活中常用的大多数网站，以及我们长期停留的网站来说，从数据库的角度来看，读写比往往远大于写读。例如大众点评网的读写比例往往是9比1。

    12306可能是中国最著名的网站之一。我记得12306早期经常出现的一个问题就是用户总是无法登录，甚至在高峰期整个网站都崩溃了，页面显示503网站拒绝访问的问题。这种现象非常好。理解是网站并发量高，大量人登录网站，买票，系统挂掉，最后没人能使用网站。

    当网站出现503拒绝访问时，那么最致命的问题就出现在网站上。解决大用户访问的问题确实是一个超级难题，但是当高并发无法避免的时候，整个网站就无法使用了。这只能说是在网站设计上发生的。致命的错误。当一个好的网站设计处理超出其能力的并发时，我们首先应该防止它因此而崩溃。没有人可以使用它。我们希望在可接受的请求范围内的请求仍然可以正常使用。超出范围的请求可以被拒绝，但不能影响整个网站的稳定性。现在我们看到12306网站的峰值一直没有下降，而且越来越频繁，但是12306网站宕机的问题却越来越少。通过12036网站的变化，我们可以进一步思考网站的瓶颈问题。

    排除一些不可控的因素，网站在高并发下挂掉的原因90%是数据库不堪重负，而应用瓶颈往往是在存储瓶颈解决之后才暴露出来，所以我们需要对网站的能力进行升级。第一步是提高数据库的承载能力。对于读远远大于写的网站，我们采取的方法是从读和写的角度来拆分数据库。具体操作就是将数据库的读写分离，如下图所示：

    这时候我们就需要设计两个数据库。一个数据库主要负责写操作，我们称之为主数据库。另一个数据库主要负责读操作，我们称之为副数据库。副数据库中的数据是从主数据库导入的。数据库的读写分离可以有效保证关键数据的安全，但一个缺点是用户浏览数据时，读取数据会有轻微的延迟。与整个站点不可用相比，这种延迟当然是可以接受的。

    但对于12306场景，仅仅读写分离是不够的。尤其是负责读操作的副库，在高访问下很容易达到性能瓶颈，所以我们不得不采用新的解决方案：使用分布式。但是，缓存的缺点是无法实时有效更新。因此，在使用缓存之前，我们首先要对数据进行分类，以进行读操作。经常不变化的数据可以提前存储在缓存中。缓存的访问效率非常高。 ，这样会让读取更加高效，同时也减少了数据库的访问压力。

    至于用于写操作的主库，由于大多数网站的读与写的比例严重不平衡，所以仍然很难让主库达到瓶颈。但是主库也有一个读取压力，就是主库和从库之间的数据同步问题。 ，但是同步时是批量操作数据，而不是像请求那样进行少量的数据读取操作。读操作较多，所以还是很难达到瓶颈。听人说美国对数据的任何操作都会提前合并成批量操作，以达到减轻数据库压力的目的。

    7. 海量数据检索

    上述方案可以保证高并发下网站的稳定性，但对于读取来说，如果数据量过大，即使网站不挂掉，用户也能在海量数据中快速检索到所需信息。已经成为网站的瓶颈。如果用户需要很长时间才能获得自己想要的数据，很多用户就会失去耐心并放弃使用网站。那么如何解决这个问题呢？

    解决办法就是我们经常使用的百度。谷歌从哪里来？我们可以利用搜索技术来读取海量数据。我们可以将数据库数据导出到文件，对文件建立索引，并使用倒排索引技术来检索信息。我们看到百度和谷歌拥有整个互联网的信息，我们仍然可以快速检索数据。搜索技术是快速读取数据的有效解决方案，但这种读取与从数据库读取仍然不同。就像用户查询的数据如果通过数据库的主键字段来检索，或者通过明确索引的字段来检索，那么数据库的查询效率是非常高的，但是使用网站的人喜欢用一些模糊查询来查找他们自己。信息，那么这个操作就类似于数据库中的操作。数据库中的like操作效率很低。这时，利用搜索技术的优势就非常明显了。搜索技术非常适合模糊查询操作。