大规模网站开发技术

Posted 2020-12-18 jiangxiaobo

（一）单机构建网站

关于系统负载

什么是系统负载？

系统负载（System Load）是系统CPU繁忙程度的度量，即有多少进程在等待被CPU调度（进程等待队列的长度）。

平均负载（Load Average）是一段时间内系统的平均负载，这个一段时间一般取1分钟、5分钟、15分钟。

如何查看系统的负载情况？

top、uptime、w等命令都可以查看系统负载。

（二）应用服务器与数据库分类

应用服务器需要处理大量的逻辑，所以需要强大的CPU；

文件服务器需要存储大量用户上传的文件，所以需要更大的硬盘；

数据库服务器需要快速磁盘检索和数据缓存，所以需要更大的内存和更快的硬盘

（三）应用服务器集群

负载均衡

什么是负载均衡？

负载均衡（Load Balance）是分布系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。

负载均衡的工作方式

1. http重定向

当http代理（比如浏览器）向web服务器请求某个Url后，web服务器可通过Http响应头信息中的Location标记来返回一个新的URL。这意味着HTTP代理需要继续请求这个新的URL，完成自动跳转。

缺点：吞吐率限制

优点：不需要任何额外支持

适用场景：我们需要权衡转移请求的开销和处理实际请求的开销，前者相对于后者越小，那么重定向的意义就越大，例如下载，你可以去很多镜像下载网站，会发现基本下载都使用了Location做了重定向

2. DNS负载均衡

DNS负责提供域名解析服务，当访问某个站点的时候，实际上首先需要通过该站点域名的DNS服务器来获取域名指向的IP地址，这一个过程中，DNS服务器完成了域名到P地址的映射，同样，这样映射也可以是一对多的，这时候，DNS服务器便充当了负载均衡调度器。

使用命令：dig google.cn 查看DNS的配置

DNS服务器可以在所有可用的A记录中寻找离用户最近的一台服务器。

缺点：DNS记录缓存更新不及时、策略的局限性、不能做健康检查。

优点：可以寻找最近的服务器，加快请求速度。

适用场景：一般我们在多机房部署的时候，可以使用。

3.反向代理负载均衡

在用户请求到达反向代理服务器的时候（已经到达网站机房），由反向代理服务器根据算法转发到具体的服务器。常用的apache、nginx都可以充当反向代理服务器。反向代理的调度器扮演的是用户和实际服务器中间人的角色。

工作在HTTP层（第7层）

缺点：代理服务器成为性能的瓶颈，特别是一次上传大文件。

优点：配置简单，策略丰富、维持用户会话，可根据访问路径做转发。

适用场景：请求量不高的，简单负载均衡。后端开销大的应用。

4.IP负载均衡

工作在传输层（第4层）

通过操作系统内修改发过来的IP数据包，将数据包的目标地址修改为内部实际服务器地址，从而实现请求的转发，做到负载均衡。lvs的nat模式。

缺点：所有数据进出还是要过负载均衡的服务器，网络带宽成为瓶颈。

优点：内核完成转发，性能高。

适用场景：对性能要求高，但对带宽要求不高的应用。视频和下载等大带宽的应用，不适合。

5.数据链路层的负载均衡

工作在数据链路层（二层）

在请求到达负载均衡器后，通过配置所有集群机器的虚拟IP和负载均衡器相同，再通过修改请求的mac地址，从而做到请求的转发。与IP负载均衡不一样的是，当请求访问完服务器之后，直接返回客户。而无需再经过负载均衡器。LVS DR（Direct Routing）模式。

缺点：配置复杂

优点：由集群机器直接返回，提供了出口带宽。

适用场景：大型网站使用最广的一种负载均衡的方式。

负载均衡中如何维持用户的session会话？

1.把同一个用户在某个会话中的请求，都分配到固定的某一台服务器中，常见的负载均衡算法有ip_hash法。

2.session数据集中存储。session数据集中存储就是利用数据库或者缓存来存储session数据，实现了session和应用服务器的解耦。

3.使用cookie来代替session的使用。

负载均衡的常见策略

轮询(Round Robin)：能力比较弱的服务器导致能力较弱的服务器最先超载

加权轮询(Weighted Round Robin)：这种算法解决了简单轮询调度算法的缺点：传入的请求按顺序被分配到集群中的服务器，但是会考虑提前为每台服务器分配的权重

最少连接数(Least Connection)：最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有块有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前连接数最小的一台服务器来处理当前的请求，尽可能地提高后端服务器的利用效率，将负责合理地分流到每一台服务器。

加权最少连接数(Weighted Least Connection)：如果服务器的资源容量各不相同，那么“加权最少连接”方法更合适：在考虑连接数的同时也权衡管理员根据服务器情况定制的权重。

源ip_hash(source Ip Hash)：这种方式通过生成请求源ip的哈希值，并通过这个哈希值来找到正确的真实服务器，这意味着对于同一主机来说他对应的服务器总是相同。

随机：通过系统随机算法，根据后端服务器的列表大小值来随机选取其中一台服务器进行访问，实际效果接近轮询的结果。

常见的负载均衡方案

硬件：常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器。优点就是专业的维护团队维护、性能高。缺点就是昂贵，所以对于规模较小的网络服务来说暂时还没有需要使用。

软件：nginx、Haproxy、LVS等

负载均衡技术	优点	缺点	并发数
LVS	抗负载能力强、配置性比较低、工作稳定、应用范围广	不支持7层转发，配置较为繁琐	十多万的并发
Haproxy	4层和7层都支持，配置简单，有监控界面	性能没有LVS高	可以支持5到10万的并发
Nginx	只支持7层转发、配置简单、epoll模型能挡高并发	主要支持http和email应用范围小	1万次
F5 BIG-IP	性能非常强大，功能非常强大	需要专业维护人员，售价几十万，比较贵	几百万并发

 

LVS这么牛逼能不能只用它就够了？

不可以，假如现在每天并发数在1000W，应该怎么设计这个架构呢？

答案：域名一个，对应多个IP服务器（不同地区都是独立且相同的负载均衡器及服务器集群），通过DNS解析到用户临近的服务器。当DNS解析到某个负载均衡器后，受理业务。比如，现在一个负载均衡器可以并发10W，那么DNS可以映射10个，那么最大并发量就是100W。

（四）数据库读写分离化

随着访问量的提高，数据库的负载也在慢慢增大。大部分互联网的业务都是“读多写少”的场景，数据库层面，读性能往往成为瓶颈。业界通常采用“一主多从，读写分离，冗余多个读库”的数据库架构来提升数据库的读性能。

问题：

主从数据库之间数据同步怎么实现？

根据负载量，如何计算需要扩展的从库数量？

同步的延迟如何保证读数据的准确？

MYSQL复制原理

1.master将改变记录到二进制日志（binary log）中（这些记录叫做二进制日志事件，binary log events）；

2.slave将master的binary log events拷贝到它的中继日志（relay log）；

3.slave重做中继日志中的事件，将改变反映它自己的数据。

负载容量的规划

例如：假设工作负载为20%的写以及80%的读。为了计算简单，假设有一些前提：

读和写查询包含同样的工作量。

所有的服务器都是等同的，每秒能进行1000次查询。

备库和主库有同样的性能特征。

可以把所有的读操作转移到备库。

如果当前有一个服务器能支持每秒1000次查询，那么应该增加多少备库才能处理当前两倍的负载，并将所有的读查询分配给备库？

解：

两倍负载： 1000 * 2 = 2000

写负载： 2000 * 20% = 400

读负载： 2000 * 80% = 1600

每个从库的可以承受负载： 由于每个从库都需要从中继日志中同步400次，所以原本1000的负载，每个从库服务器变成 1000 - 400 = 600

从库数量： 1600 / 600 约等于 3，所以需要三台从库

DB主从架构一致性优化方法