12.1 Nginx/lua 12.2 LVS 12.3 CDN 12.4 keepalived
12.1 Nginx/lua
一款輕量級Web服務器/反向代理及電子郵件代理服務器
佔內存少，數據結構緊湊，零拷貝，配置文件簡單
高性能，一臺可十萬併發，epoll的nio，零拷貝。成本低
一萬個請求來，Nginx一個線程處理，Apache則有一萬個線程會炸。Nginx和Apache可作靜態Web服務器。
一般Nginx用於反向代理，Tomcat動態服務器
反向代理作用
1 保證內網安全，可用反向代理的WAF功能，阻止Web攻擊。大型網站，通常將反向代理作爲公網訪問地址，Web服務是內網。
2 優化負載均衡
默認：輪詢
最少連接
IP地址Hash
基於權重
負載均衡配置
服務器上host文件改域名 如 127.0.0.1 yunyun.1.com
服務器配置nginx.conf文件，配輪詢方式
upstream yunyun.1.com{
server:127.0.0.1:8881
server:xxx
server:xxx
}
Nginx緩存
http_proxy 模塊，可實現緩存功能 (如訪問靜態html網頁經過Nginx會緩存)
Nginx緩存配置
哪裏配置？
nginx.conf文件中proxy_cache_path指定位置 2個參數：目錄/緩存名稱及佔內存大小
哪些能配置？
默認所有get/head方法的請求結果緩存key
可自定義key，指定請求至少發送多少次以上才緩存，可指定哪些方法請求被緩存(get/head/post等)
有效期
默認長留，除非cache總量大於limit，可指定cache時間
一些請求可自定義不緩存
通過proxy_cache_bypass指定請求不走緩存
網頁的緩存是由HTTP消息頭中 "Cache-control" 控制，默認private(僅客戶端可以緩存，代理服務器不行)
比如把private改成public，則nignx可以緩存
Ngx_lua模塊
Nginx模塊用c開發，規則複雜。所以用ngx_lua模塊，用lua腳本實現業務邏輯(lua解釋器繼承Nginx)
特點：高併發，非阻塞
lua內建協程(併發佔內存很小)，可以很好將異步回調改成順序調用
每個協程有一個獨立的全局環境(變量空間)，繼承於全局共享只讀的"common data"
協程
類似多線程，不是操作系統線程，所以創建切換開銷比線程小
協程棧在用戶進程空間模擬的，所以創建切換開銷小
多線程是併發執行，一個瞬間多個流執行。協程強調協作，一瞬間能有一個運行
因爲一瞬間只能一個運行，對臨界區不用加鎖，多線程則需要加
因爲多線程有多個控制流，程序行爲不可控，協程可控
Nginx每個worker進程都在epoll/kqueue上封裝成協程，每個請求一個協程處理，與lua內建協程模型一致。
所以ngx_lua執行lua對c開銷很小，高併發能力仍然很好
這個解釋的更清楚
協程是線程內的一個內存模型，一個線程可以有多個協程。當我們的協程(如read方法)遇到阻塞的時候，那麼系統會立馬調用另一個不阻塞的線程來執行read。這樣做的好處是，這樣就不需要關注什麼時候socket的read會返回。因爲當read完成，epoll多路複用會執行一個回調。這個回調是一個return函數，read完成會順序的執行。這樣我們的協程機制就是一個同步的，它就不需要進行加鎖。
網圖
Nginx進程模型
採用多進程，單master進程，多worker進程。master進程管理worker進程
worker 用單線程非阻塞事件模型(個數一般CPU數量) 具體處理請求
master
接收外界信號
向各個worker發送信號
監控worker運行狀態
當worker異常退出，會自動重啓worker
總結：不就是reactor模式IO多路複用麼，只是這裏是epoll比select牛逼點
HTTP請求處理
反向代理Nginx先分階段處理
OpenResty
原理：可用lua腳本直接調用Nginx，可直接對redis/mysql等操作
目標：web服務器可直接跑在Nginx server內部
使用：下載OpenResty後，編寫OpenResty的lua腳本 xxx.conf
應用
//1 目標：訪問http://127.0.0.1:8080時，返回請求報文和輸出Hello World
nginx.conf下
http{
server{
listen:8080; //監聽8080端口
location/{
//很多參數
default_type text/html;
return 200 "Hello World"
}
}
}
//2 目標：調用http://yunyun.123.com會重定向到127.0.0.1:8080
1 host文件
127.0.0.1 yunyun.123.com
2 nginx.conf下
upstream origin.123.com{
server 127.0.0.1:8080;//通過負載均衡策略，選擇服務器
server ...
server ...
}
server{
listen 8080;
server-name yunyun.123.com;
location/{ //通過location攔截
proxy_pass http://origin.123.com
}
}
Nginx常用配置
inclue各種conf文件
worker一些控制(控制worker進程運行的用戶，用戶組，進程打開的最大句柄數)
限制信號隊列
worker_rlimit_sigpending limit 某用戶信號隊列滿了，再發的信號量
設置worker進程個數
設置worker到指定的CPU內核，worker優先級設置
設accpet鎖，accept延遲時間
設事件模型 poll/select/kqueue
批量連接 on/off
12.2 LVS
Linux Virtual Server
在linux2.6版本後加入內核。基於IP+TCP Port，主要用於服務器負載均衡
企業簡單負載均衡架構圖
LVS框架
E-Commerce
General Network Services
Cluster Management
KTCPUS (基於內容請求分發Layer-7交換機)
IPVS (3種IP負載均衡IP虛擬服務器軟件)
IPVS (IP負載均衡，效率最高)
1 VS/DR (Virtual Server vs Direct ROuting)
通過改寫MAC地址，將請求發到真實服務器上，直接相應客戶，不再需要IP隧道的開銷。但要求調度器和真實服務器都有一塊網卡連在同一物理網段上
2 VS/NAT
調度器重寫請求報文目標地址，通過調度算法請求發送到真實服務器上。服務器響應後通過調度器，再次重寫報文源地址返回客戶
3 VS/TUN
使用NAT時，請求和響應都要調度器重寫，當請求太大時，調度器承受不了，所以調度器把請求報文通過IP隧道發送到真實服務器響應。所以調度器只處理請求報文，集羣吞吐量上升10倍。
IPVS調度算法
Source Hash
輪詢
加權輪詢
最少連接
加權最少連接
局部性最少連接
帶複製的局部性最少連接
目標地址hash
12.3 CDN
內容分發網絡
使用戶就近獲取所需要的內容，減少網絡阻塞，提高訪問響應
CDN依靠部署在各地邊緣服務器，包括中心平臺負載均衡，內容分發，調度等功能模塊
比如下載Jquery庫，通過CDN分析從就近節點上快速下載下來
CDN優勢
本地Cache加速(大量圖片，靜態頁面訪問加速)
鏡像，遠程加速，帶寬優化，集羣抗攻擊
CDN服務模式
分發服務系統(保存緩存) -> 負載均衡系統(user訪問調度) -> 內容管理系統(收集整理交付)
CDN工作流程
常規Web請求
1 用戶網站上輸入url
2 瀏覽本地DNS(如有直接相應)
3 如無，整個DNS系統遞歸解析
4 瀏覽器拿到域名解析結果(IP地址)
5 瀏覽器向服務器請求內容
5 服務器將請求內容發給瀏覽器
引入CDN後Web請求
1 url後，經本地DNS解析，DNS系統將域名解析權交給CNAME指向的CDN專用DNS server
2 CDN的DNS server 將全局負載均衡設備IP返回用戶
3 用戶用CDN全局負載均衡設備發送url請求
4 CDN全局負載均衡設備選一個區域負載均衡設備響應
5 區域負載均衡設備選一個緩存服務器
6 緩存服務器與用戶交互
7 如果此緩存服務器沒有用戶需要數據，則它向上一級緩存服務器要數據，知道追溯到源服務器，拿到數據返回用戶
12.4 keepalived
用於檢查服務器狀態。一臺服務器掛了，keepalived會將它剔除選擇新的節點替換，服務器恢復正常了會再加入，全程自動。
人工只需要修復服務器
ARP協議：IP轉MAC地址(網卡)的協議
RARP協議：MAC轉IP
ICMP協議：控制IP的協議
特性
配置簡單
穩定性強，成本低
應用範圍廣，用於幾乎所有高可用應用(LVS,數據庫，htttp，nginx)
支持多種類型(主從，主主等)
原理
keepalived以VRRP協議實現，通過優先級確定虛擬路由器中每個路由器角色(master/backUp路由器)，
優先級一樣時候，接口地址大的爲master。比Zookeeper簡單粗暴效率高
三大模塊
core：核心，主進程啓動，維護及全局配置文件的加載和解析
check：健康檢查
vrrp：vrrp協議的實現