域名反向解析查询_从单机至亿级流量大型网站系统架构的演进过程

优点：简单。

缺点：性能较差。

2、DNS域名解析负载均衡：DNS域名解析负载均衡是指当用户请求DNS服务器获取某个域名对应的IP地址时，DNS服务器经过负载均衡后直接给出服务器IP。

优点：交给DNS，我们不需要维护负载平衡服务器。

缺点：当应用服务器崩溃时，无法及时通知DNS，而且DNS负载均衡的控制权在域名服务商的手中，因此网站无法做更多的改进和更有力的管理。

3、反向代理服务器。当用户的请求到达反向代理服务器（已经到达网站机房）时，反向代理服务器会根据算法，将其转发到特定的服务器上。常用的，nginx 就可以充当反向代理服务器。

优点：部署简单。

缺点：代理服务器可能会成为性能瓶颈，尤其是在一次上传大文件时。

4、IP层负载均衡：请求到达负载均衡器之后，负载均衡器修改请求的目标IP地址，将请求进行转发，实现负载均衡。

优点：性能更佳。

缺点：负载均衡器的带宽成为瓶颈。

5、数据链路层负载均衡。请求到达负载均衡器后，负载均衡器会修改请求的 MAC 地址，实现负载均衡。与 IP 负载均衡不同的是，请求访问完服务器后，直接返回给客户端，不需要经过负载均衡器。

2、第二个问题是集群调度算法，常见的调度算法有10种。

1、rr轮询调度算法，顾名思义，轮询就是将请求进行分发。

优点：实现简单

缺点：没有考虑每个服务器的处理能力

2、WRR加权调度算法。我们给每个服务器设定一个权重，负载均衡调度器根据权重对服务器进行调度，服务器被调用的次数与权重成正比。

优点：考虑到服务器的不同处理能力

3.sh原始地址hash：提取用户IP，根据hash函数得到一个key，然后根据静态映射表查对应的值，也就是目标服务器IP，如果目标机器超载，则不返回任何内容。

4.dh目标地址哈希：与上面相同，但现在提取目标地址的IP地址进行哈希计算。

优点：以上两种算法都可以使同一个用户访问同一个服务器。

5.lc least . 优先将请求转发到连接数较少的服务器。

优点：使得集群中各个服务器的负载更加均匀。

6、WLC加权最少连接数。在LC的基础上，给每个服务器增加一个权重，算法为：（活跃连接数*256+不活跃连接数）÷权重，计算值较小的服务器优先被选中。

优点：可以根据服务器的功能分配请求。

7、sed 最短预期延迟。其实 sed 和 wlc 类似，不同之处在于不考虑非活跃连接数，算法为：（活跃连接数 + 1）*256 ÷ 权重。同样，优先选择计算值较小的服务器。

8、nq 永不排队。改进的sed算法。我们来想一下什么时候可以实现“永不排队”。那就是当服务器连接数为0的时候。如果服务器连接数为0，那么会直接把请求转发给它，而不需要sed计算。

9、LBLC基于本地最少连接，负载均衡器根据请求的目的IP找到最近被使用的服务器，并将请求转发给该服务器，如果该服务器超载，则使用最小连接算法。

10、LBLCR 基于本地复制的最少连接。均衡器根据请求的目的 IP 地址，找到该 IP 地址最近使用过的“服务器组”，注意不是特定的服务器。然后使用最少连接数从组中选择一个特定的服务器，将请求转发给它。如果服务器超载，则根据最少连接数算法，从集群中不属于服务器组的服务器中找出一个服务器，将其加入到服务器组中，然后将请求转发给它。

3、第三个问题是集群模式问题，一般有三种解决方案：

1、NAT：负载均衡器收到用户的请求后，转发到特定的服务器，服务器处理完请求后返回给均衡器，均衡器再返回给用户。

2、DR：负载均衡器接收用户的请求，转发到特定的服务器，服务器处理请求后直接返回给用户，这需要系统支持IP协议，跨平台实现难度较大。

3、TUN：与上述相同，但不需要IP协议，具有良好的跨平台能力，可以被大多数系统支持。

4.第四个问题，一般有4种解决方法：

1、一个会话中同一个用户的所有请求都会被分配到固定的服务器上，这样就不需要解决跨服务器的问题了，常见的算法有上面提到的两种hash算法。

优点：实现简单。

缺点：应用服务器重启后就会消失。

2.在集群中进行复制，以便每台服务器都存储所有用户的数据。

优点：减少负载均衡服务器的压力，不需要实现算法来转发请求。

缺点：复制时带宽开销较大，访问次数较多时内存占用较大，浪费。

3、集中式数据存储：集中式数据存储就是使用数据库来存储数据，实现与应用服务器的解耦。

优点：与其他方案相比，大大减轻了集群间带宽、内存的压力。

缺点：需要维护存储的数据库。

4、Base：Base就是浏览器，告诉应用服务器我有什么东西，同时它也实现了和应用服务器的解耦。

优点：实现简单、基本免维护。

缺点：长度限制、安全性低、消耗带宽。

值得一提的是：

目前nginx支持的负载均衡算法有wrr、sh（支持一致性哈希）、fair（我觉得可以归功于lc）。不过如果把nginx当做均衡器的话，也可以当做静态资源服务器来用。

+ 功能强大，目前支持的算法包括：rr、wrr、lc、wlc、lblc、sh、dh

支持的集群模式：NAT、DR、TUN

Nginx本身不提供同步解决方案，但是提供共享支持。

好了，解决了上面的问题之后，系统的结构如下：

阶段四：数据库读写分离

在上文中我们始终假设数据库负载正常，但是随着访问量的增加，数据库负载也在慢慢增大。那么有些人可能立刻就会想到将数据库拆分成两个，然后进行负载均衡，就像应用服务器那样。但是对于数据库来说，并不是那么简单，如果我们简单的将数据库拆分成两个，然后分别将数据库请求加载到机器 A 和机器 B 上，显然会造成两个数据库数据不一致的问题。对于这种情况，我们可以首先考虑使用读写分离的方法。

读写分离后的数据库体系结构如下：

这种结构性变化还会带来两个问题：

主从数据库之间的数据同步问题

数据源应用选择问题

问题解决方案：

我们可以利用MYSQL内置的+slave的方式，实现主从复制。

使用第三方数据库中间件，比如mycat。mycat由cobar开发而来，cobar是阿里巴巴开源的数据库中间件，但后来停止了开发。mycat是国内比较优秀的MySQL开源数据库分片中间件。

第五阶段：利用搜索引擎缓解读取数据库的压力

当数据库作为读数据库时，经常会出现无法进行模糊搜索的情况，即使实现了读写分离，也并没有解决这个问题。就拿我们提到的交易网站来说，发布的商品都存放在数据库中，用户最常用的功能就是搜索商品，尤其是根据商品标题搜索对应的商品。对于这个需求，我们一般会使用like功能来实现，但是这种方式成本很高，这时候我们就可以利用搜索引擎的倒排索引来完成。

搜索引擎具有以下优点：

可以大大提高查询速度。

搜索引擎的引入还会带来以下成本：

这带来了很多维护工作，需要自己实现索引的构建过程，设计全量/增量的构建方法来应对非实时和实时的查询需求。

搜索引擎集群需要维护

搜索引擎并不能替代数据库，它只是在特定场景下解决“读”的问题，是否引入搜索引擎需要综合考虑整个系统的需求，引入搜索引擎后的系统结构如下：

阶段六：利用缓存缓解读数据库的压力

1.后端应用层和数据库层的缓存

随着访问量的增长，很多用户逐渐访问的是同一部分内容，对于这些热门内容，没必要每次都从数据库读取，我们可以使用缓存技术，比如开源的缓存技术guava，或者作为应用层的缓存，或者使用redis作为数据库层的缓存。

另外，关系型数据库在某些场景下也不是很适合。比如我要做一个“限制每日密码输入错误次数”的功能，思路是当用户登录时，如果登录错误，会记录用户的IP和错误次数。那么这些数据应该存放在哪里呢？如果放在内存中，显然占用空间太大；如果放在关系型数据库中，需要创建数据库表、恢复相应的Java bean、编写SQL等。而如果分析一下我们要存储的数据，无非就是{ip:}这样的key:value数据。对于这种数据，我们可以使用NOSQL数据库来代替传统的关系型数据库。

2. 页面缓存

除了数据缓存之外，还有页面缓存，比如使用HTML5或者。

优势：

减轻数据库压力

显著提高访问速度

缺点：

需要缓存服务器维护

编码复杂性增加

值得一提的是：

缓存集群的调度算法和上面说的应用服务器、数据库不一样，最好使用“一致性哈希算法”，以提高命中率，这里就不细说了，有兴趣的可以去查阅相关资料。

添加缓存后的结构：

阶段七：数据库的水平和垂直拆分

我们的网站发展到现在，交易、商品、用户数据还是在同一个数据库中，虽然我们采取了增加缓存、读写分离的方法，但是随着数据库压力的不断增大，数据库的瓶颈越来越凸显，这时候我们就有两个选择：数据垂直拆分和数据水平拆分。

7.1. 垂直数据分割

垂直拆分是指将数据库中不同的业务数据拆分到不同的数据库中，在当前例子中，即分离交易、产品、用户数据。

优势：

解决了把所有业务放在一个数据库的压力问题。