大规模网站开发技术
内容目录
大型网站的特点
单机网站构建------网站发展第一阶段
业务场景：
注：以上场景都是一个系统容量估算的问题；
注：以上场景中，访问量的评估需要跟据业务需求跟市场部沟通来确定一个数值；
top命令图未：
注：1）第一行：11:21:00 — 当前系统时间 13 days, 8:44 — 系统已经运行了13天8小时44分钟（在这期间没有重启过） users — 当前有1个用户登录系统 load average: 0.00, 0.01, 0.05 — load average后面的三个数分别是1分钟、5分钟、15分钟的负载情况。load average数据是每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转了。
2）Tasks — 任务（进程），系统现在共有72个进程，其中处于运行中的有1个，71个在休眠（sleep），stoped状态的有0个，zombie状态（僵尸）的有0个。
3）第三行：cpu状态 0.3 us — 用户空间占用CPU的百分比。 0.3 sy — 内核空间占用CPU的百分比。 0.0 ni — 改变过优先级的进程占用CPU的百分比 99.3 id — 空闲CPU百分比 0.0% wa — IO等待占用CPU的百分比 0.0 hi — 硬中断（Hardware IRQ）占用CPU的百分比 0.0 si — 软中断（Software Interrupts）占用CPU的百分比；在这里CPU的使用比率和windows概念不同，如果你不理解用户空间和内核空间，需要充充电了。
4）第四行：内存状态1017860k total — 物理内存总量（1GB）947200k used — 使用中的内存总量（947MB）70660k free — 空闲内存总量（70M）31424k buffers — 缓存的内存量 （30M）
5）第五行：swap交换分区 0 total — 交换区总量（0GB） 0 used — 使用的交换区总量（0M） 0 free — 空闲交换区总量（0GB） 273340 cached — 缓冲的交换区总量（273MB）
6）第六行是空行
7）第七行以下：各进程（任务）的状态监控
PID — 进程id
USER — 进程所有者
PR — 进程优先级
NI — nice值。负值表示高优先级，正值表示低优先级
VIRT — 进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
RES — 进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
SHR — 共享内存大小，单位kb
S — 进程状态。D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程
%CPU — 上次更新到现在的CPU时间占用百分比
%MEM — 进程使用的物理内存百分比
TIME+ — 进程使用的CPU时间总计，单位1/100秒
COMMAND — 进程名称（命令名/命令行）注2：这里要说明的是不能用windows的内存概念理解这些数据，如果按windows的方式此台服务器“危矣”：1G的内存总量只剩下70M的可用内存。Linux的内存管理有其特殊性，复杂点需要一本书来说明，这里只是简单说点和我们传统概念（windows）的不同。 第四行中使用中的内存总量（used）指的是现在系统内核控制的内存数，空闲内存总量（free）是内核还未纳入其管控范围的数量。纳入内核管理的内存不见得都在使用中，还包括过去使用过的现在可以被重复利用的内存，内核并不把这些可被重新使用的内存交还到free中去，因此在linux上free内存会越来越少，但不用为此担心。如果出于习惯去计算可用内存数，这里有个近似的计算公式：第四行的free + 第四行的buffers + 第五行的cached，按这个公式此台服务器的可用内存：70660+31424+273340= 366MB。对于内存监控，在top里我们要时刻监控第五行swap交换分区的used，如果这个数值在不断的变化，说明内核在不断进行内存和swap的数据交换，这是真正的内存不够用了。多U多核CPU监控在top基本视图中，按键盘数字“1”，可监控每个逻辑CPU的状况：
注：以上的Load是指top命令中第一行的load average；
应用服务器和数据服务器分离------网站发展第二阶段
注：php和mysql是解耦的，php和mysql之间仅仅是通一个mysql链接做通讯，所以当单机上网站负载不了时，最好是应用服务器(如php)和数据服务器(mysql)分离，这样对业务的影响是最小的；
应用服务器集群------网站发展第三阶段
负载均衡
注：服务层现在流行的是soa(面向服务的架构) ，服务层将某些服务独立出来，如用户中心服务、文件上传服务、发送邮件服务等；不仅是在客户端到web服务器之间，网站架构中，任何有多台服务器的地方都需要负载均衡，如多台database或多台cache之间都是需要负载均衡的；
注：http重定向的缺点是，用户的一个请求到服务器后会变成两个，对服务器的压力会变大；适应场景为，服务器本身处理该请求时，压力太大，可以将请求重定向到其它服务器处理，此时，重定向的开销远小于服务器要身处理请求的开销；
注：网络运营服务商，如电信、联通都会缓存DNS，就算我们自己更新了DNS，服务商那边的缓存没更新，服务商下游的用户就还会使用更新前的DNS；
dig示例(百度的IP有两个)：
[root@iZ28mhfkaunZ ~]# dig baidu.com ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> baidu.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26867 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;baidu.com. IN A ;; ANSWER SECTION: baidu.com. 254 IN A 220.181.57.216 baidu.com. 254 IN A 123.125.115.110 ;; Query time: 0 msec ;; SERVER: 10.143.22.118#53(10.143.22.118) ;; WHEN: Sun Jun 24 14:30:53 CST 2018 ;; MSG SIZE rcvd: 5
注：反向代理是指通过反向代理服务器(如nginx)，访问内网里没有外网IP，只有内网IP的服务器；
注：IP负载均衡和反向代理负载均衡类似，所有的数据进出都要经过负载机器，对服务器的负载太大；目前，服务器上瓶颈是网络带宽，即服务器上的网卡和传输的光纤；IP负载均衡因是在内核完成的转发，性能比反向代理服高很多；
IP负载均衡图示：
注：数据链路层的负载均衡解决前面几种带宽和性能的问题，唯一的缺点是配置复杂；
数据链路层负载均衡示例：
注：负载均衡的策略就是负载均衡的算法；
1）加权轮循就是依据服务器配置的不同，给不同的服务器一个权重值，以便让更多的请求给配置相对较高的服务器来处理；
2）最少连接数适用于下载服务器，该策略可以防止极端情况下，将多个下载速度慢，下载文件大的请求发到同一台服务器上，从而导致服务器宕机；
注：上图中的并发数是指1秒内的并发数；
注：目前，中国南北的网络连接还是相对较慢，一般的大型网站在南北都有机房，除了LVS外还是得靠DNS的负载均衡将请求发送最近的机房处理；
数据库读写分离------网站发展第四阶段
注：数据的读写分离只适用于读多写少的场景，因为读写分离只能扩展读操作，不能扩展写操作，只有主库能承担写改删的操作，并通过二进制日志同步到从库，所以从库只能分担数据库的读操作，没法分担写改删操作；
注：上图的情况下，在将所有写操作转到主库的情况下，2000次查询中，会有400的写操作，1600的读操作，每个每秒1000次查询的从库因为需要从主库同步400写操作，因此只能承担600的读操作，所以此种情况下，需要1主3从；
注：实际使用中，写操作的脚本强制读主库的方法是最常用的；
数据库的水平拆分与垂直拆分
注：数据表中如果有text型的字段时，会进行文件排序，因此如果是频繁查询的数据表里有text型字段时，最好将其拆分出来；
注：拆表时可以使用取余算法，如果一张数据表的规模有1亿时，查询速度会非常慢，但如果将其拆分成100张小表，每张小表100万，查询起来速度就非常快了；
注：二阶段提交就是先将用户的请求发到事务协调器，然后事务协调器将事务分别发到多个数据库上，此时，在多个数据库上执行的都是预处理，预处理完成后，多个服务器会将预处理的结果返回给事务协调器，事务协调器如果收到返回结果都是yes时，通知各个服务器真正提交预处理的结果；事务协调器收到的预处理返回里如果有no，就会通知回滚；
注：二阶段提交会锁定资源，所以并发性很差，也就是CAP中可用性很差；
注：冗余表是指拆分时，同一张表拆分两次，一次按buyer_id来拆分，一次按seller_id来拆分；
应用的拆分与服务化------网站发展第六阶段
避免系统中的单点
注：单点是指如上图所示的系统里，如果分发用户请求的负载均衡挂掉了，那么后面的整个系统就都不起作用了；解决方案之一是用软件keepalived；
