（一）单机构建网站
关于系统负载
什么是系统负载？
系统负载（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，所以需要三台从库