第8次作业

1. 总结 哨兵机制实现原理，并搭建主从哨兵集群。

哨兵Sentinel主要实现的是一个redis的故障转移，来实现主从之间的故障切换，并不能提高主节点写入的并发效率。
工作原理就是哨兵Sentinel为客户端提供的并不是一个代理功能实现哨兵Sentinel对redis的转发，而是哨兵Sentinel为客户端提供redis服务器端的地址，让客户端自己去访问。在哨兵Sentinel需要监控每一个哨兵Sentinel和redis的master、salve的状态，并且会定时向这些节点发送消息，来判断节点是是否异常，如果redis主节点异常，Sentinel内部会通过流言协议，来投票是否要下线该主节点，进行故障的转移。如果一个Sentinel认为主节点宕机称为主观宕，如果是投票结果是主节点宕机称为客观宕。哨兵Sentinel的数量最好是在三个或者三个之上的奇数，偶数的话会产生脑裂现象。投票结果为哨兵数量一半的向上取整。

对哨兵架构的搭建
①准备主从节点的配置

从节点配置

查看节点状态和对从节点进行配置

对哨兵Sentinel进行配置

启动服务

测试Sentinel故障转移成果

重启原主节点，发现Sentinel能够自动更改原主节点指向新主节点

2. 总结redis cluster工作原理，并搭建集群实现扩缩容。

Redis Cluster 是采用分布式存储的方式，进行数据的写入，能够支持多个master节点并行写入和故障的自动转移。Redis Cluster最少是由三个master节点才能实现，slave节点数量不限，一般来说一个master节点最少对应一个slave节点。Redis Cluster上一共有16384个槽位，一般情况下来说如果有几个master节点，这几个master节点就把16384个槽位平分，比如有三个master节点，节点M1：0 -5460；节点M2：5461-10922： 节点M3：10923-16384.
如果客户端连接的话是连接整个Redis Cluster集群，每个节点都要连接，如果是客户端写入数据时，每保存一个key都要先经过哈希函数CRC16（key）得到一个整数，然后再对16384取模，得到对应槽位的数值，通过这个数值来判断，这个key存入到那个master节点上。Redis Cluster是自带哨兵机制的，在主节点宕机时能自动切换节点。
 

创建集群

配置文件设置

bind 0.0.0.0
masterauth 123456   #建议配置，否则后期的master和slave主从复制无法成功，还需再配置
requirepass 123456
cluster-enabled yes #取消此行注释,必须开启集群，开启后 redis 进程会有cluster标识
cluster-config-file nodes-6379.conf #取消此行注释,此为集群状态数据文件,记录主从关系及slot范围信息,由redis cluster 集群自动创建和维护
cluster-require-full-coverage no   #默认值为yes,设为no可以防止一个节点不可用导致整个cluster不可用

扩容，新增节点

3. 总结 LVS的NAT和DR模型工作原理，并完成DR模型实战。

NAT模式是跟DNAT差不多属于是有多目标转发的DNAT，它的工作原理就是如果一个客户端访问服务器是用客户端地址访问VS的VIP,然后通过VS把目标地址VIP改为后端服务器的RIP进行转发访问。如果是响应报文的话就是由RIP发向CIP，经过VS转发把RIP替换成VIP。但是NAT模式只解决的后端服务器的负载均衡，但是这种模式对VS的负载就比较大，所以更多的是使用DR模式。
DR模式叫直接路由，是LVS默认的模式，应用最广泛的，它的工作原理就是需要在VS和RS上都要有VIP，但是RS上的VIP要忽略ARP的广播协议和禁止主动发送自己的VIP。如果从客户端访问服务器时源IP（CIP)和目的IP（VIP）是不变的，只是在请求报文的首部封装上VS的MAC地址，通过VS时源地址和目标地址不变，MAC地址变为RS的MAC地址，实现转发。响应报文的话就直接用源地址是VIP目的地址是CIP，直接响应给客户端，不需要通过VS进行转发，大大降低了VS的工作压力。由于VS需要通过广播来获取RS的MAC地址所以VS和RS直接不能使用路由器，不能够跨网段
 

在RS服务器上安装http服务

对RS服务器进行IPVS的配置

LVS主机的配置

4. 总结 http协议的通信过程详解

http协议通信过程 

HTTP协议分层

URI与URL

URI ： Uniform Resource Identifier 统一资源标识，分为 URL 和 URN
URN ： Uniform Resource Naming ，统一资源命名
示例： P2P 下载使用的磁力链接是 URN 的一种实现
magnet:?xt=urn:btih:660557A6890EF888666
URL ： Uniform Resorce Locator ，统一资源定位符，用于描述某服务器某特定资源位置
两者区别： URN 如同一个人的名称，而 URL 代表一个人的住址。换言之， URN 定义某事物的身份，而
URL 提供查找该事物的方法。 URN 仅用于命名，而不指定地址
URL组成：

 <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

scheme:方案，访问服务器以获取资源时要使用哪种协议

user:用户，某些方案访问资源时需要的用户名

password:密码，用户对应的密码，中间用：分隔

Host:主机，资源宿主服务器的主机名或IP地址 port:端口,资源宿主服务器正在监听的端口号，很多方案有默认端口号

path:路径,服务器资源的本地名，由一个/将其与前面的URL组件分隔

params:参数，指定输入的参数，参数为名/值对，多个参数，用;分隔

query:查询，传递参数给程序，如数据库，用？分隔,多个查询用&分隔

frag:片段,一小片或一部分资源的名字，此组件在客户端使用，用#分隔

网站访问量

IP( 独立 IP) ：即 Internet Protocol, 指独立 IP 数。一天内来自相同客户机 IP 地址只计算一次，记录远
程客户机 IP 地址的计算机访问网站的次数，是衡量网站流量的重要指标
PV( 访问量 ) ： 即 Page View, 页面浏览量或点击量，用户每次刷新即被计算一次， PV 反映的是浏览
某网站的页面数， PV 与来访者的数量成正比， PV 并不是页面的来访者数量，而是网站被访问的页
面数量
UV( 独立访客 ) ：即 Unique Visitor, 访问网站的一台电脑为一个访客。一天内相同的客户端只被计算
一次。可以理解成访问某网站的电脑的数量。网站判断来访电脑的身份是通过 cookies 实现的。如
果更换了 IP 后但不清除 cookies ，再访问相同网站，该网站的统计中 UV 数是不变的
QPS ： request per second ，每秒请求数
PV ， QPS 和并发连接数换算公式
QPS= PV * 页面衍生连接次数 / 统计时间（ 86400 ）
并发连接数 =QPS * http 平均响应时间
峰值时间：每天 80% 的访问集中在 20% 的时间里，这 20% 时间为峰值时间
峰值时间每秒请求数 (QPS)=( 总 PV 数 * 页面衍生连接次数） *80% ) / ( 每天秒数 * 20% )

HTTP工作机制

一次 http 事务包括：
http 请求： http request
http 响应： http response
Web 资源 ： web resource ， 一个网页由多个资源（文件）构成，打开一个页面，通常会有多个资源展
示出来，但是每个资源都要单独请求。因此，一个 "Web 页面 ” 通常并不是单个资源，而是一组资源的集合
资源类型：
静态文件：无需服务端做出额外处理 , 服务器端和客户端的文件内容相同
常见文件后缀： .html, .txt, .jpg, .js, .css, .mp3, .avi
动态文件：服务端执行程序，返回执行的结果 , 服务器端和客户端的文件内容不相同
常见文件后缀： .php, .jsp ,.asp
HTTP 连接请求
串行和并行连接
串行 , 持久连接和管道
提高 HTTP 连接性能
并行连接：通过多条 TCP 连接发起并发的 HTTP 请求
持久连接： keep-alive ，重用 TCP 连接，以消除连接和关闭的时延 , 以事务个数和时间来决定是否关
闭连接
管道化连接：通过共享 TCP 连接，发起并发的 HTTP 请求
复用的连接：交替传送请求和响应报文（实验阶段）
HTTP1.0 和 HTTP1.1 的区别
缓存处理，在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，
HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag ， If-Unmodified-Since, If-Match, If-None
Match 等更多可供选择的缓存头来控制缓存策略
带宽优化及网络连接的使用， HTTP1.0 中，存在一些浪费带宽的现象，例如：客户端只是需要某个
对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能， HTTP1.1 则在请求头
引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206 （ Partial Content ），方便了
开发者自由的选择以便于充分利用带宽和连接
错误通知的管理，在 HTTP1.1 中新增 24 个状态响应码，如 409 （ Conflict ）表示请求的资源与资源当
前状态冲突； 410 （ Gone ）表示服务器上的某个资源被永久性的删除
Host 头处理，在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并
没有传递主机名（ hostname ）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个
虚拟主机（ Multi-homed Web Servers ），并且它们共享一个 IP 地址。 HTTP1.1 的请求消息和响应
消息都应支持 Host 头域，且请求消息中如果没有 Host 头域会报告一个错误（ 400 Bad Request ）
长连接， HTTP 1.1 支持持久连接（ PersistentConnection ）和请求的流水线（ Pipelining ）处理，
在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟，在
HTTP1.1 中默认开启 Connection ： keep-alive ，弥补了 HTTP1.0 每次请求都要创建连接的缺点。
HTTP2 协议
http/2.0 ： 2015 年， HTTP2.0 是 SPDY 的升级版
头信息和数据体都是二进制，称为头信息帧和数据帧
复用 TCP 连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一
一对应，避免了 " 队头堵塞 ", 此双向的实时通信称为多工（ Multiplexing ）
引入头信息压缩机制（ header compression ） , 头信息使用 gzip 或 compress 压缩后再发送；客户端
和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，不发送同样字段，
只发送索引号，提高速度
HTTP/2 允许服务器未经请求，主动向客户端发送资源，即服务器推送（ server push ）。
1.3.7 HTTP 请求访问的完整过程
一次完整的 http 请求处理过程
1 、建立连接：接收或拒绝连接请求
2 、接收请求：接收客户端请求报文中对某资源的一次请求的过程
Web 访问响应模型（ Web I/O ）
单进程 I/O 模型：启动一个进程处理用户请求，而且一次只处理一个，多个请求被串行响应
多进程 I/O 模型：并行启动多个进程 , 每个进程响应一个连接请求 复用 I/O 结构：启动一个进程，同时响应 N 个连接请求
复用的多进程 I/O 模型：启动 M 个进程，每个进程响应 N 个连接请求，同时接收 M*N 个请求
3 、处理请求：服务器对请求报文进行解析，并获取请求的资源及请求方法等相关信息，根据方法，资源，首部和可选的主体部分对请求进行处理
常用请求 Method: GET 、 POST 、 HEAD 、 PUT 、 DELETE 、 TRACE 、 OPTIONS
4 、访问资源：
      服务器获取请求报文中请求的资源 web 服务器，即存放了 web 资源的服务器，负责向请求者提供对方请求的静态资源，或动态运行后生成的资源
5 、构建响应报文：
       一旦 Web 服务器识别除了资源，就执行请求方法中描述的动作，并返回响应报文。响应报文中包含有响应状态码、响应首部，如果生成了响应主体的话，还包括响应主体
1 ）响应实体：如果事务处理产生了响应主体，就将内容放在响应报文中回送过去。响应报文中通常包括：
描述了响应主体 MIME 类型的 Content-Type 首部
描述了响应主体长度的 Content-Length
实际报文的主体内容
2 ） URL 重定向： web 服务构建的响应并非客户端请求的资源，而是资源另外一个访问路径
3 ） MIME 类型： Web 服务器要负责确定响应主体的 MIME 类型。多种配置服务器的方法可将 MIME 类型与资源管理起来
魔法分类： Apache web 服务器可以扫描每个资源的内容，并将其与一个已知模式表 ( 被称为魔法文
件 ) 进行匹配，以决定每个文件的 MIME 类型。这样做可能比较慢，但很方便，尤其是文件没有标准
扩展名时
显式分类：可以对 Web 服务器进行配置，使其不考虑文件的扩展名或内容，强制特定文件或目录内
容拥有某个 MIME 类型
类型协商： 有些 Web 服务器经过配置，可以以多种文档格式来存储资源。在这种情况下，可以配
置 Web 服务器，使其可以通过与用户的协商来决定使用哪种格式 ( 及相关的 MIME 类型 )" 最好 "
6 、发送响应报文
      Web 服务器通过连接发送数据时也会面临与接收数据一样的问题。服务器可能有很多条到各个客户端的连接，有些是空闲的，有些在向服务器发送数据，还有一些在向客户端回送响应数据。服务器要记录连接的状态，还要特别注意对持久连接的处理。对非持久连接而言，服务器应该在发送了整条报文之后，关闭自己这一端的连接。对持久连接来说，连接可能仍保持打开状态，在这种情况下，服务器要正确地计算Content-Length首部，不然客户端就无法知道响应什么时候结束
7 、记录日志
    最后，当事务结束时， Web 服务器会在日志文件中添加一个条目，来描述已执行的事务。

HTTP的报文结构

HTTP响应报文

 HTTP 报文格式详解

1.4.3.1 Method 方法
请求方法，标明客户端希望服务器对资源执行的动作，包括以下：
GET ： 从服务器获取一个资源
HEAD ： 只从服务器获取文档的响应首部
POST ： 向服务器输入数据，通常会再由网关程序继续处理
PUT ： 将请求的主体部分存储在服务器中，如上传文件
DELETE ： 请求删除服务器上指定的文档
TRACE ：追踪请求到达服务器中间经过的代理服务器
OPTIONS ：请求服务器返回对指定资源支持使用的请求方法
CONNECT ：建立一个到由目标资源标识的服务器的隧道
PATCH ：用于对资源应用部分修改
 

5. 总结  网络IO模型和nginx架构

网络IO模型
1.阻塞型(blocking IO)
就是需要IO完成操作之后，才能再进行后续的动作，在整个IO请求过程中，用户线程都是被阻塞的，再此期间用户不能做任何事情，CPU利用与低，是一种串行结构，性能不佳。

2、非阻塞型(nonblocking IO)
在用户发起IO请求时立即返回，但是如果系统没有完成操作，用户线程会一直不停的继续发送IO请求，直到能够读取数据，这种模式会大量的消耗CPU，性能也不佳。

3、复用型（I/O multiplexing)
多路复用是一种机制，用户进程如果发起IO请求，不是直接发给内核，而是发给一个代理（select），在这个过程中是允许单线程处理多个IO请求的，但是在这个过程中用户进程也是阻塞的，是对select上的阻塞，如果IO操作完成之后select会对用户进程返回数据，这种模型提高了CPU利用率。

4、信号驱动型(signal-driven IO)
进程在发起IO请求之后不会阻塞，也不会去轮询。可以直接去处理其他的请求，让内核准备好数据之后，发送信号通知进程。但是进程接收到内核发送的信号之后就会进入阻塞状态，等待数据从内核拷贝到用户空间，拷贝这个过程时很短暂的。因此这种模式即不影响进程继续处理其他的请求也可以提高资源的利用率。

5、异步(asynchronous IO)
这种模型在发送一次系统调用后，不用等待内核的回应，可以接受其他的请求，在内核拷贝到用户空间的时候，用户进程也不会阻塞。相当于在两次IO的时候进程都不会阻塞。

nginx架构
由一个主进程，若干个子进程，每一个子进程可以接受若干个用户的连接，所以并发性能很高，还可以提供代理和缓存的功能，同时支持epoll和select两种模型。

6. 完成nginx编译安装脚本

7. 总结nginx核心配置

8. 总结nginx日志格式定制

log_format 后面就是默认格式的的内容，可以自行决定想要开启格式的形式，log_format只能放在http块里。
main 是格式模板的名字，取什么都可以，‘ ’单引号后面就是格式的内容，允许换行。
access_log 可以控制是否开启日志，关闭日志就off，开启后面就加日志存放的地址，和日志格式的名字。access_log可以写在http块也可以在server块，所已如果多个虚拟主机，可以把日志单独写在各自的配置文件中，生成单独的日志文件。