第十五周学习内容：keepalived和varnish
第十五周作业：
1、简述HA cluster原理。
集群中存在着多个单点，如调度器、session server、NFS等，他们的宕机会导致整个集群不可用。解决办法就是高可用集群（HA cluster），将多台能够提供相同服务的主机组成一个组，活动中的主机不停将自己还在服务的信息以某种协议同步给备用主机。工作正常时相安无事，一旦活动主机发生故障，则会将活动主机提供服务所需的资源转移到备用主机上，这个过程叫做失效转移，也叫故障转移。在开源领域，高可用集群的解决方案有很多，keepalive、heartbeat、Corosync等。
keepalived在设计之初就是为lvs服务的，可为其提供高可用和健康监测，其工作原理是利用网络中的vrrp协议，建立一个虚拟IP地址，背后是真正的物理接口，多台主机的多个物理接口共享同一个虚拟IP地址，主机中有主有被，通过优先级来决定。虚拟IP地址一直在主服务器上，有其向外提供服务，一旦主设备发生故障，备机将会把虚拟IP地址抢占过来，从而改由备机提供服务。在配置过程中还可以定义是否抢占，主备，优先级和优先级惩罚等多种属性。
heartbeat和Corosync是另外一种架构，基于分层的高可用集群。最底层叫资源层也被称为心跳层，用来确保各台主机状态是否正常，可以互相通信传递心跳信息。上面一层叫做资源管理层crm，用来配置策略，决定哪些资源被监控，当活动主机发生故障要传递哪些资源等，但这一层是无法在不同主机之间通信的，也不能对主机作出具体的更改，算是中间层，决策层。再往上一层叫本地资源管理层lrm，通过ra资源代理调用一个个外部指令做出具体更改。
2、keepalived实现主从、主主架构。
keepalived是vrrp协议的具体实现，简单来说就是可以做到地址流动，可以为虚拟IP地址所在节点生成ipvs规则，为后端real server做健康状态检测，还可以基于脚本调用接口通过执行脚本完成脚本中定义的功能。keepalived就存在base仓库，主配置文件是/etc/keepalived/keepalived.conf，配置文件可分为三部分：全局配置、VRRP配置、LVS配置。
keepalived实现主从配置：主服务器配置
从服务器配置，主要区别在state、priority这两个配置。
现在将两台主机的keepalived服务启动起来，并准备两张主页且启动http服务，尝试访问虚拟地址主页。
发现访问的是主设备，现在把主设备的http服务关闭了。
再去访问该主页，自动就切换到备机了。
keepalived实现主主配置：在主从设置中，大多数情况下是一台主机一直处于活动，一台主机一直处于闲置。为了避免浪费可以使用主主配置，就是再定义一个实例，加一个虚拟地址，将前一个实例中的主服务器定义为备用，再将备用主机定义为主，再基于DNS实现域名的负载均衡。
主服务器配置
备用服务器配置
这样基于两个不同的地址，将访问两台不同的主机。
当其中一台主机发生宕机，则会两个地址都去往同一台可用主机。
3、简述http协议缓存原理及常用首部讲解。
缓存的名词解释为数据交换的缓冲区，缓存能够生效是因为程序的运行具有局部性特征：时间局部性，一个数据被访问过之后，可能很快再次访问；空间局限性：一个数据被访问时，其周边的数据也有可能被访问到。
以web站点为例，缓存的数据库数据成为datacache，缓存的PHP资源称为opcode。缓存的上线并不是立即生效的，是需要热身，了解哪些是需要缓存的，这一过程短则1,2个小时，长则1天。所以在生产环境中，会用线上数据去做压测，将热身过程在上线前完成，缓存上线后即可立即生效。
缓存空间肯定是小于实际存储空间的，当缓存空间满了以后，可根据LRU（最近最少使用规则）清理缓存。可自己定义缓存保留时长，当过期后即使缓存空间未满也会清理。
缓存的目的是为了加速访问，而一直不被访问就叫有效性很差，有效性的评估方法叫命中率：hit/（hit+miss），有页面命中率、字节命中率等。缓存是有多级结构的，用户本地缓存叫做private cache，每一层的反代也都会有各自的缓存叫做public cache。
缓存服务器也有两种组织形式，最常见的就是反代，接收到用户请求，查找本地缓存，没找到在反代给后端服务器，等待后端服务器响应后自己也缓存一份，web服务都是以这种形式组织的；还有一种叫做旁挂式缓存，接收到用户请求，查找本地缓存，没找到就告诉用户没有缓存，用户再重新发请求找真正的后端服务器，此种方式所有的选择权都在用户这边，memcache就是这种架构。
http协议的缓存机制：http1.0时代，通过响应报文首部Expires来控制，记录的是绝对时间，表示给用户的响应多久以后会过期，是单纯的以时间为衡量标准，如果有时差的话会出现收到响应报文缓存已经过期的情况，这样的话缓存根本无法发挥作用。到了http1.1时代，可以通过cache-control来进行控制了，该首部中记录了很多内容，如maxage，也是过期时间，但用的是相对时间，以秒为单位，可用于所有缓存，这样就避免了收到即过期的情况；s-maxage，同样是过期时间，仅用于公共缓存，且会覆盖maxage；no-cache表示即使被用户缓存，用户在请求时也要做有效性验证；no-store表示不能缓存；public表示可用于所有缓存；private表示仅用于私有缓存等。除了基于时间作为控制缓存的机制以外，http1.1还引入了条件式控制，Last-Modified定义了自从多久没更新，会向后端服务器发起验证，验证该缓存是否依然可用，当响应码为304时，表示可以继续使用；当响应码为200时，表示不可继续使用同时新的响应资源会被送达；ETag定义了已缓存文件的校验吗作为判断，两种方式可结合起来使用。
4、简述回源原理和CDN常见多级缓存 。
回源原理：回源是指浏览器在发送请求报文时，响应该请求报文的是源站点的服务器，而不是各节点上的缓存服务器，那么这个过程相对于通过各节点上的缓存服务器来响应的话就称作为回源。回源的请求或流量太多的话，有可能会让源站点的服务器承载着过大的访问压力，进而影响服务的正常访问。
CDN：Content Delivery Network，内容分发网络，其搭建的思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，尽量使内容传输的更快更稳定。CDN通过在网络边缘部署边缘服务器，依靠CDN中心平台的负载均衡、内容分发及调度等功能，使用户就近获取所需的内容，降低网络拥堵，提高用户访问响应速度和命中率。所以基本上CDN就是广泛采用各种缓存服务器，使得用户的请求直接由这些缓存服务器响应，加快了响应速度；只有在用户请求的资源在缓存服务器上没有找到或者请求访问的资源在源站点服务器上已经修改过的情况下，缓存服务器才会去访问源站点服务器以获取最新的资源。
在CDN系统中，直接面向用户，负责给用户提供内容服务的的Cache设备都部署在整个CDN网络的边缘位置，所以将这一层称为边缘层。而中心层负责全局的管理和控制，同时也保存了最多的内容Cache。在边缘层设备未能命中Cache时，需要向中心层设备请求；而中心层未能命中时，则需要向源站请求。不同的CDN系统设计存在差异，中心层可能具备用户服务的能力，也可能只会向下一层提供服务。如果CDN系统比较庞大，边缘层向中心层请求内容太多，会造成中心层负载压力太大。此时，需要在中心层和边缘层之间部署一个区域层，负责一个区域的管理和控制，也可以提供一些内容Cache供边缘层访问。
CDN边缘节点缓存策略因服务商不同而不同，但一般都会遵循http标准协议，通过http响应头中的Cache-control: max-age的字段来设置CDN边缘节点数据缓存时间。当客户端向CDN节点请求数据时，CDN节点会判断缓存数据是否过期，若缓存数据并没有过期，则直接将缓存数据返回给客户端；否则，CDN节点就会向源站发出回源请求，从源站拉取最新数据，更新本地缓存，并将最新数据返回给客户端。
这一段完全靠百度......
5、varnish实现缓存对象及反代后端主机。
varnish是一款高性能、开源的反向代理服务器和缓存服务器。Varnish使用内存缓存文件来减少响应时间和网络带宽消耗。由于varnish先进的设计理念，性能要比古老的缓存服务器squid高上许多，varnish还可以通过端口进行管理，使用正则语句做到清除指定缓存的功能，这些squid都做不到。但是varnish在高并发的情况下，资源消耗较高，而且varnish服务进程一旦崩溃，重启，内存中的缓存数据将全部丢失。
VCL：是一种专用的配置语言，在报文到达用户空间后也会有一道道的关卡，被称为状态引擎，可以用iptables中的链去类比思考，在每个状态引擎上可以配置各种缓存规则，并且要在最后使用return()函数指明下一个状态引擎，引擎之间是彼此隔离的，但又存在相关性。在配置文件中每个状态引擎对应一个配置段，叫subroutine，子例程。默认配置文件中看不到任何配置，但在varnishadm命令行界面中使用vcl.show -v即可查看到有些已经做得隐藏配置并且是不能修改的。
状态引擎：从收到用户请求开始，先经过vcl_recv，如果可查看缓存则送往vcl_hash，如果是根本不认识的METHOD，根本不理解此请求报文则送往vcl_pipe作其它处理，如果METHOD是PURGE（修剪）则送往vcl_purge，再经过vcl_synth，将响应码与响应内容合成以后响应给客户。而可查缓存内容到达vcl_hash之后，查看hash表，命中则送往vcl_hit，未命中则送往vcl_miss。正常情况下vcl_hit会将缓存内容通过vcl_deliver响应给用户，但如果缓存文件过期或者设有条件式控制机制则会将报文发送至vcl_pass，而vcl_miss的下一步也是vcl_pass。vcl_pass会将报文送到专门的后台工作线程vcl_backend_fetch，不可响应的分到vcl_backend_error，可响应的分到vcl_backend_response，最终送达vcl_deliver，结束！除此之外，还有两个特殊的状态引擎：vcl_int，在处理任何请求之前先执行的vcl代码，用于初始化；vcl_finl，在所有请求处理完毕后用于清理。
内建函数和变量：return()，指明下一步到哪个引擎上；hash_data()，指明对哪个数据做哈希运算。varnish一般会接触到四种报文，分别为用户发来的请求，后端服务器的响应以及自己发给用户的响应和发给后端服务器的请求，只有后两种报文可以进行修改。req.*表示由客户端发来的请求报文相关属性值；bereq.*表示自己发往后端服务器的请求报文相关属性值；beresp.*表示后端主机发给我的响应报文相关属性值；resp.*表示由我发给客户端的响应报文相关属性值；obj.*表示存储在本地缓存空间的缓存对象的属性；server.*表示varnish服务器的属性；client.*表示用户的相关属性。而在这些分类中经常会用到的变量有bereq.和req.request：请求方法；bereq.url：请求的url；bereq.proto：请求的协议版本；bereq.backend：指明要调用的后端主机；req.url:请求的url；req.http.Cookie：客户端的请求报文中Cookie首部的值； req.http.User-Agent：浏览器类型；beresp.和resp.status：响应的状态码；reresp.proto：协议版本；beresp.backend.name：BE主机的主机名；beresp.ttl：BE主机响应的内容的余下的可缓存时长；obj.hits：此对象从缓存中命中的次数；obj.ttl：对象的ttl值；server.ip和client.ip：主机和客户端IP地址。
varnish实现缓存对象及反代后端主机：
在default.vcl中定义一个内建变量obj.hits，用于保存某缓存项的从缓存中命中与否，为了之后的显示更直观。
进入varnish的命令行接口，载入default.vcl配置
再次访问主页时，在响应报文首部就多了XX报头，并且显示缓存是否被命中
强制对某类资源的请求不检查缓存，这需要在recv段中配置
在不载入配置时，访问/admin路径
载入配置，别忘了要启动
再次进行访问，就显示miss状态，且不管刷新几次都是miss，不会命中
使用curl命令发送请求，直接不用缓存响应，且返回403响应码，依然是在recv段中配置
载入配置以后，使用curl命令进行访问
由于时间的关系，还有两个示例在下周进行补充。