高併發高可用處理大數據量

時間 2019-11-07

標籤併發可用處理數據简体版

原文原文鏈接

教學大綱：

教學內容
大型互聯網三大問題-高併發，高可用，大數據量
第一天內容以下：
1：什麼是高併發？
2：爲何要解決高併發
3：畫圖分析：
    1） 多用戶訪問單臺App服務器及數據庫時，性能分析，瓶頸在哪裏？
    2） 提出解決辦法：加App服務器
    3） 隨之出現更多問題 問題1：用戶訪問IP多了 怎麼解決？ 問題2：數據庫出現瓶頸 怎麼辦？
    4） 問題1 採用負載均衡解決 
    5） 問題2：
    • 採用緩存
    • 採用讀寫分離+主從複製解決，須要多臺數據庫，畫圖說明解決方案（系統級別解決）
    • 更好的解決方案是分庫分表，庫表散列（應用級別解決）
目前 ：高併發網站架構設計方案
    • 網頁HTML 靜態化（須要CMS項目支持）
    • 圖片服務器分離（經常使用解決方案）
    • 數據庫集羣和庫表散列（終級解決方案）
    • 緩存（經常使用解決方案）
    • 鏡像（下載較多）
    • 負載均衡（終級解決方案）


4：介紹什麼是負載均衡？
5：負載均衡原理—畫圖說明 –總結它的功能
6：負載均衡的種類
7：本節課採用LVS負載均衡演示?
8：爲何採用LVS？
1）此時要先講解網絡七層相關東西。以後說明LVS工做在四層上，而Nginx，apache工做在七層上
    2） 四層與七層對服務器CPU，內存等性能的消耗進行說明
9：搭建負載均衡環境準備—4臺虛擬服務器，4個IP，
10：須要安裝的軟件
11：開始搭建---演示效果
12：講解keepalived配置參數參數
13：講解linux lo接口VIP綁定腳本參數說明
14：什麼是高可用？
15: 搭建備用負載均衡---演示主機掛掉，備機自動接管工做，主機恢復，從新接管工做，備機進入等待
次日內容以下：
16：什麼是大數據量？
17：爲何不演示讀寫分離？採用讀寫分離只能解決數據庫併發問題，但隨着天天數據量的增長，若是使用的是Mysql，mysql的數據量達到千萬級時，即便使用讀寫分離，mysql查詢數據的速度也慢的要命，此時，不少公司會更換oracle來解決這個問題，但oracle是按CPU收費的。採用讀寫分離一定是多臺數據庫，多臺oracle是一筆不小的費用，費用仍是其次，隨着天天數據量的增長，oracle也有頂不住的一天
18：oracle頂不住怎麼辦？
答案1：hadoop集羣
答案2：分庫分表，庫表散列
目前形勢簡介：大多公司都會走上hadoop集羣這條路上來，由於分庫分表，庫表散列是須要在項目初期時，公司高管就要有懂這方面人才存在，但現實當中，這樣的人不多，包括淘寶，剛開始也不是分庫分表，庫表散列，然後來採用了oracle，再後來成立了本身的研究院，才解決了分庫分表，庫表散列的設計，但麻煩的事情也隨之而來，就是老數據怎麼遷移進新庫中，還要平滑的遷移，平滑指的是網站正常運轉，隨時都會有新數據進來，怎麼將時刻動態變化的數據遷移到新庫中來，難度很是大。採用的辦法是：全量+增量 運維人員寫三個腳本，分別是導數據腳本，read log腳本，對比數據腳本

採用分庫分表，庫表散列
好處：
    (一) 可以使用免費的mysql集羣便可，可節省出orcal集羣的大筆費用
    (二) 當數據量增多到當前數據庫集羣不能容納時，也支持動態添加新庫來應對
    (三) 可以使用很是廉價服務器來安裝mysql



什麼是分庫？
什麼是分表？
什麼是庫表散列？

本節課演示案例：演示的內容來自於阿里研究院，已經運行三年以上，較爲成熟
支持數據庫容災、備份

實現級別？
    應用級別實現
採用什麼架構實現？
    Spring + mybatis + mysql 實現
搭建環境準備
    開發工具：myeclipse ,jdk
演示效果
    
詳細講解如何配置 （見意不對外給源碼）

資料篇：

View Code

企業的劃分：

選擇成熟企業仍是創業企業

    小公司看老闆——老闆靠譜，願意分享，空間無限。

    中公司看制度——制度合理，空間可見，成長階段。

    大公司看文化——文化適合，空間有限，平臺價值。


面對創業型、發展型、成熟型的企業，該如何選擇？


創業型企業意味着更艱苦的條件和更大的風險，可是也意味着更大的機會，只是這種機會比較渺茫而已。
由於它的成活率很低，成活後能發展爲偉大企業的概率就更低，並且你要伴隨它很長時間才能知道你的選擇是否正確。
這些都是你要掂量的，這也是不少學生不肯去那些美名曰「創新工做」的企業的緣由。

發展型企業已經沒有成活的風險，最艱苦的日子已過，也積累了至關的市場和組織基礎，
只是與成熟型企業相比，制度、福利待遇或者技能培訓體系有可能還不足夠完善。
若是你能參與其中的建設和完善工做，將來在這個組織中，你必將有本身的位置。

成熟型企業自有它的優點，好比已經造成的企業文化，老中青相結合的組織隊伍，成熟的晉升體制，至關規模的市場基礎等。

View Code

企業的架構圖：

高併發：

什麼是高併發呢？
多個進程或線程同時(或着說在同一段時間內)訪問同一資源會產生併發問題。mysql

大量用戶直接訪問一臺Tomcat服務器：linux

初期解決方案：

系統或服務器級別的解決方案
1：增大服務器的CPU。
2：增長內存條。
3：增長硬盤個數，對硬盤作Raid5。
4：換掉免費的Tomcat，使用商用weblogic(美國Oracle公司出品的)
5：增長到二塊網卡。
6：聘請系統架構師優化Linux內核
甚至花高價直接購買高性能服務器ios

隨着業務的不斷增長，服務器性能很快又到達瓶頸nginx

應用級別的解決方案
1：網頁HTML 靜態化（須要CMS項目支持）
2：圖片服務器分離（經常使用解決方案）
3：緩存（經常使用解決方案）
4：鏡像（下載較多）c++

可否增長服務器數量？

隨之出現更多問題

問題1：用戶訪問IP多了怎麼解決？
問題2：數據庫出現瓶頸怎麼辦？web

DNS：

DNS（Domain Name System，域名系統），因特網上做爲域名和IP地址相互映射的一個分佈式數據庫，可以使用戶更方便的訪問互聯網，而不用去記住可以被機器直接讀取的IP數串。經過主機名，最終獲得該主機名對應的IP地址的過程叫作域名解析（或主機名解析）。DNS協議運行在UDP協議之上，使用端口號53。redis

畫圖說明
1：通過DNS解析
2：不通過DNS解析算法

解決IP多--DNS

DNS服務器能夠解決IP多了的問題
http://www.itcast.cn : 192.168.1.100
192.168.1.101
192.168.1.102
……更多sql

缺點：雖然循環複用 DNS 是一個廣泛使用的在 Web 服務器上負載平衡的解決方案，可是，該方式有它自身的缺陷。循環複用 DNS將傳入的 IP 請求映射到定義的一系列循環形式的服務器。一旦發生服務器故障，循環複用 DNS 繼續把請求發送到這個故障服務器，一直到把該服務器從 DNS 中移走爲止。這樣許多用戶必須等到 DNS 鏈接超時之後才能成功地訪問目標網站shell

用戶訪問IP多了怎麼解決

採用負載均衡技術（終級解決方案）

因爲目前現有網絡的各個核心部分隨着業務量的提升，訪問量和數據流量的快速增加，其處理能力和計算強度也相應地增大，使得單一的服務器設備根本沒法承擔。在此狀況下，若是扔掉現有設備去作大量的硬件升級，這樣將形成現有資源的浪費，並且若是再面臨下一次業務量的提高時，這又將致使再一次硬件升級的高額成本投入，甚至性能再卓越的設備也不能知足當前業務量增加的需求。
　　針對此狀況而衍生出來的一種廉價有效透明的方法以擴展示有網絡設備和服務器的帶寬、增長吞吐量、增強網絡數據處理能力、提升網絡的靈活性和可用性的技術就是負載均衡（Load Balance）。

負載在均衡工做原理：

總結：負載均衡功能

1.轉發請求
2:故障移除
3:恢復添加

負載均衡種類

1）一種是經過硬件來進行解決，常見的硬件有NetScaler、F五、Radware和Array等商用的負載均衡器，可是它們是比較昂貴的

2）一種是經過軟件來進行解決的，常見的軟件有LVS、Nginx、apache等,它們是基於Linux系統而且開源的負載均衡策略

負載均衡--軟件解決

1：apache
2：nginx
3: lvs

Apache + JK

Apache是世界使用排名第一的Web服務器軟件。它能夠運行在幾乎全部普遍使用的計算機平臺上，因爲其跨平臺和安全性被普遍使用，是最流行的Web服務器端軟件
JK是apache提供的一款爲解決大量請求而分流處理的開源插件

Nginx

Nginx（發音同 engine x）是一款輕量級的Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，並在一個BSD-like 協議下發行。由俄羅斯的程序設計師Igor Sysoev(伊戈爾·西索夫)所開發，供俄國大型的入口網站及搜索引擎Rambler(漫步者)（俄文：Рамблер）使用。其特色是佔有內存少，併發能力強，事實上nginx的併發能力確實在同類型的網頁服務器中表現較好，中國大陸使用nginx網站用戶有：新浪、網易、騰訊等。

優勢：
1:可運行linux,並有 Windows 移植版。
2:在高鏈接併發的狀況下，Nginx是Apache服務器不錯的替代品Nginx在美國是作虛擬主機生意的老闆們常常選擇的軟件平臺之一。可以支持高達 50,000 個併發鏈接數的響應

LVS：

LVS的英文全稱是Linux Virtual Server，即Linux虛擬服務器。它是咱們國家的章文嵩博士的一個開源項目。在linux內核2.6中，它已經成爲內核的一部分，在此以前的內核版本則須要從新編譯內核。

網絡七層

什麼是網絡七層？
可畫圖說明。

理解網絡七層以後，有助於同窗們理解LVS的優點,對比nginx 與 lvs 區別

爲何選擇LVS？優點

一、抗負載能力強，由於lvs工做方式的邏輯是很是之簡單，並且工做在網絡4層僅作請求分發之用，沒有流量，因此在效率上基本不須要太過考慮。在我手裏的 lvs，僅僅出過一次問題：在併發最高的一小段時間內均衡器出現丟包現象，據分析爲網絡問題，即網卡或linux2.4內核的承載能力已到上限，內存和 cpu方面基本無消耗。
二、配置性低，這一般是一大劣勢，但同時也是一大優點，由於沒有太多可配置的選項，因此除了增減服務器，並不須要常常去觸碰它，大大減小了人爲出錯的概率。

三、工做穩定，由於其自己抗負載能力很強，因此穩定性高也是瓜熟蒂落，另外各類lvs都有完整的雙機熱備方案，因此一點不用擔憂均衡器自己會出什麼問題，節點出現故障的話，lvs會自動判別，因此係統總體是很是穩定的。
四、無流量，上面已經有所說起了。lvs僅僅分發請求，而流量並不從它自己出去，因此能夠利用它這點來作一些線路分流之用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。

五、基本上能支持全部應用，由於lvs工做在4層，因此它能夠對幾乎全部應用作負載均衡，包括http、數據庫、聊天室等等。

LVS 對比 Nginx

負載度
2：網絡的依賴
3：穩定度
4：服務器性能要求

效率最高的負載均衡技術

調度器的實現技術中,IP負載均衡技術是效率最高的,IP虛擬服務器軟件(IPVS)是在linux內核中實現的｡

IPVS軟件實現了三種IP負載均衡技術
1：VS/NAT
2： VS/TUN
3： VS/DR

VS/NAT

Virtual Server via Network Address Translation（VS/NAT）
經過網絡地址轉換，調度器重寫請求報文的目標地址，根據預設的調度算法，將請求分派給後端真實服務器；真實服務器的響應報文經過調度器時，報文源地址被重寫再返回給客戶，完成整個負載調度過程。

但一般在流量比較大的狀況下會形成調度器的瓶頸。由於服務數據的返回必須經過調度器出去。

能夠畫個圖來講明一下！

VS/TUN

Virtual Server via IP Tunneling（VS/TUN）
採用NAT技術時，因爲請求和響應報文都必須通過調度器地址重寫，當客戶請求愈來愈多時，調度器的處理能力將成爲瓶頸。爲了解決這個問題，調度器把請求報文經過IP隧道轉發至真實服務器，而真實服務器將響應直接返回給客戶，因此調度器只處理請求報文。因爲通常網絡服務應答比請求報文大許多，採用 VS/TUN技術後，集羣系統的最大吞吐量能夠提升10倍。

可是目前支持TUN 只有Linux系統

VS/DR

Virtual Server via Direct Routing（VS/DR）
VS/DR經過改寫請求報文的MAC地址，將請求發送到真實服務器，而真實服務器將響應直接返回給客戶。同VS/TUN技術同樣，VS/DR技術可極大地提升集羣系統的伸縮性。這種方法沒有IP隧道的開銷，對集羣中的真實服務器也沒有必須支持IP隧道協議的要求，可是要求調度器與真實服務器都有一塊網卡連在同一物理網段上。也就是說，在這種結構中，數據從外部到內部真實服務器的訪問會經過調度器進來，可是真實服務器對其的應答不是經過調度器出去。即在大多數狀況下，真實服務器能夠經過各自的網關或者專用的網關對數據進行外發，從而下降調度器負載。

LVS中提供了八種不一樣的調度算法

1:輪叫調度（Round-Robin Scheduling）
2: 加權輪叫調度（Weighted Round-Robin Scheduling）
3:最小鏈接調度（Least-Connection Scheduling）
4:加權最小鏈接調度（Weighted Least-Connection Scheduling）
5:基於局部性的最少連接（Locality-Based Least Connections Scheduling）
6:帶複製的基於局部性最少連接（Locality-Based Least Connections with Replication Scheduling）
7:目標地址散列調度（Destination Hashing Scheduling）
8:源地址散列調度（Source Hashing Scheduling）
9:最短預期延時調度（Shortest Expected Delay Scheduling）
10:不排隊調度（Never Queue Scheduling）
對應: rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq

加權輪叫調度(WeightedRound-RobinScheduling)

調度器經過"加權輪叫"調度算法根據真實服務器的不一樣處理能力來調度訪問請求｡這樣能夠保證處理能力強的服務器處理更多的訪問流量｡調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值｡

加權最小鏈接調度(WeightedLeast-ConnectionScheduling)

在集羣系統中的服務器性能差別較大的狀況下,調度器採用"加權最少連接"調度算法優化負載均衡性能,具備較高權值的服務器將承受較大比例的活動鏈接負載｡調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值

搭建負載均衡的環境---準備

系統：Centos6 (三臺)
負載均衡：LVS + keepalived
服務器1：Http
服務器2：Http

ip配置

一、VIP（virtual ip）：用來提供virtual server服務的ip地址。分別綁定在Director一個物理網卡上（對外接收請求包）和RS的迴環設備上（迴環設備須要綁定兩個ip，一個是127.0.0.1，另外一個就是vip）。
二、DIP（director ip）：與vip綁定在一個物理網卡上，用來轉發請求包到RS的RIP對應的mac上，此設備能夠經過arp請求獲取RIP對應的mac地址。
三、RIP（real server ip）：綁定在RS上的一個物理網卡上，用來接收從Directory轉發過來的請求包。

一：realserver服務器IP綁定配置

在兩臺realserver服務器安裝並配置(本課演示用Linux自帶Http服務進行演示),創建測試網頁，先使用實際IP進行訪問測試，能正常訪問後，進行以下操做：

二：realserver服務器IP綁定配置

在前面的文章中介紹DR模式時提到：負載均衡器也只是分發請求，應答包經過單獨的路由方法返回給客戶端。
但實際上客戶端訪問時，IP都是指向的負載均衡器的ip（也就是LVS的VIP），如何能讓真是服務器處理IP頭爲VIP的請求，這就須要作下面的操做，將VIP綁定到真實服務器的lo網口（迴環），爲了防止IP廣播產生IP衝突，還需關閉IP廣播。

三：編輯開機啓動腳本

[root@web1 ~]# vim /etc/init.d/realserver

問題：
沒有realserver?
touch一個realserver便可

腳本在《開機啓動腳本》文檔中

四：設置腳本開機啓動並當即啓動

[root@web1 ~]# chkconfig realserver on
[root@web1 ~]# service realserver start

若是啓動正確
RealServer Start OK

五：開始搭建負載均衡

1:安裝 ipvsadm keepalived
命令:yum –y install ipvsadm keepalived
2:配置 keepalived
命令:vi /etc/keepalived/keepalived.conf

六：keepalived.conf

global_defs {                       
#   notification_email {             
#       admin@toxingwang.com
#   }
#   notification_email_from master@toxingwang.com
#   smtp_server smtp.exmail.qq.com
#   smtp_connect_timeout 30
    router_id LVS_DEVEL             
}
vrrp_instance VI_1 {            
    state MASTER             
    interface eth0            
    virtual_router_id 51        
    priority 100                  
    advert_int 1           
    authentication {        
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {         
        192.168.107.127
    }
}
virtual_server 192.168.107.127 80 {
    delay_loop 6           
    lb_algo wrr            
    lb_kind DR                          
    nat_mask 255.255.255.0   
    persistence_timeout 0    
    protocol TCP                          
    real_server 192.168.107.129 80 {     
        weight 3                             
        TCP_CHECK {                     
            connect_timeout 10   
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
    real_server 192.168.107.130 80 {
        weight 3
        TCP_CHECK {
            connect_timeout 10
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}

View Code

七：啓動keepalived服務

[root@lvs1 ~]# service keepalived start

注：因爲keepalived配置文件有語法錯誤也能啓動，所以看到啓動了lvs服務，不表明配置文件沒有錯誤，若是遇到lvs不能正常轉發，及時跟蹤日誌進行處理。

八：日誌跟蹤方法：

一、開兩個ssh窗口鏈接到lvs服務器，第一個窗口運行以下命令：
[root@lvs1 ~]# tail -f /var/log/message
二、第二個窗口從新啓動keepalived服務，同時觀察窗口1中日誌的變化，而後根據日誌提示解決便可。

九：測試LVS

在lvs master服務器上運行以下命令：
[root@lvs1 ~]# watch -n 1 ipvsadm -ln
在多臺客戶端經過瀏覽器訪問VIP或域名（域名需解析到VIP），看可否獲取到正確的頁面，且同時觀察上述窗口的變化。

lvs集羣內部網絡問題的解決

A、vip解決衝突的方式：因爲vip分別配置在director和RS上，若是不加限制會致使ip地址衝突，因此須要在RS的迴環設備上禁用arp響應（ echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore ），同時也要調整發送arp請求時使用哪一個ip做爲源地址（echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce）。即集羣的路由器/交換機在使用arp詢問誰有vip地址時，只有director做出響應，RS並不迴應此arp請求，因此集羣的路由器/交換機並不知道RS上也有VIP地址的配置。這個過程圖示以下：

realserver腳本說明

#!/bin/bash
#chkconfig: 2345 79 20
#description:realserver
SNS_VIP=192.168.1.98            #定義VIP變量
. /etc/rc.d/init.d/functions    #導腳本庫
case "$1" in                    #case語句 $1傳遞給該shell腳本的第一個參數
start)
ifconfig lo:0 $SNS_VIP netmask 255.255.255.255 broadcast $SNS_VIP #設置Lo：0 VIP  netmask  及廣播
/sbin/route add -host $SNS_VIP dev lo:0                              ##route del 增長本地路由
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
sysctl -p >/dev/null 2>&1                        # -p <file>   (default /etc/sysctl.conf) 將標準信息輸入設備空文件
echo "RealServer Start OK"
;;
stop)
ifconfig lo:0 down
route del $SNS_VIP >/dev/null 2>&1                 #route del 刪除本地路由
echo "0" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "0" >/proc/sys/net/ipv4/conf/lo/arp_announce
echo "0" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "0" >/proc/sys/net/ipv4/conf/all/arp_announce
echo "RealServer Stoped"
;;
*)
echo "Usage: $0 {start|stop}"  #$0 是腳本自己的名字
exit 1                            #表示進程正常退出
esac                            #case結束
exit 0                            #表示進程非正常退出

View Code

兩個參數說明：
arp_ignore：用來配置對arp請求的響應模式，每種模式表示的含義以下：
0 ：(默認值)迴應任何網絡接口上對任何本地IP地址的arp查詢請求
1 ：只回答目標IP地址是來訪網絡接口本地IP地址的ARP查詢請求
2 ：只回答目標IP地址是來訪網絡接口本地IP地址的ARP查詢請求,且來訪IP必須在該網絡接口的子網段內
3 ：不迴應該網絡接口的arp請求，而只對設置的惟一和鏈接地址作出迴應
4-7 ：保留未使用
8 ：不迴應全部（本地地址）的arp查詢

arp_announce：用來配置發送arp請求的模式，每種模式含義以下：
0：(默認值)使用任何interface上的任何本地地址，在此模式下不管使用哪一個接口發送arp請求，arp請求包裏的源ip地址在arp層不會作修改，也就是arp請求包裏的源ip地址爲即將發送ip數據包的源ip地址。
1：避免這個interface的不在目標子網裏的本地地址，當ARP請求包裏的目的IP地址是須要通過路由達到的時候頗有用，此時會檢查來訪IP是否爲全部接口上的子網段內ip之一，若是該來訪IP不屬於各個網絡接口上的子網段內，那麼將採用級別2的方式來進行處理。
2：對arp請求包使用最適當的本地IP地址，在此模式下將忽略即將發送IP數據包的源地址，並嘗試選擇與能與該目的地址通訊的本地地址，首先是選擇與目標IP地址屬於同一子網的接口IP地址。若是沒有合適的地址被發現，將選擇當前的發送網絡接口或其餘的有可能接受到該ARP迴應的網絡接口來進行發送，當內網的機器要發送一個到外部的ip包，那麼它就會請求路由器的Mac地址，發送一個arp請求，這個arp請求裏面包括了本身的ip地址和Mac地址，而linux默認是使用即將發送ip包的源ip地址做爲arp裏面的源ip地址(0模式)，而不是使用發送設備上面的，若是設置arp_announce爲2，則使用發送設備上的ip地址。

keepalived.conf 參數說明

#   notification_email {             ##下面幾行均爲全局通知配置，能夠實現出現問題後報警，但功能有限，所以註釋掉，並採用Nagios監視lvs運行狀況
#       admin@toxingwang.com
#   }
#   notification_email_from master@toxingwang.com
#   smtp_server smtp.exmail.qq.com
#   smtp_connect_timeout 30
    router_id LVS_DEVEL             ##設置lvs的id，在一個網絡內應該是惟一的
}
vrrp_instance VI_1 {            ##設置vrrp組，惟一且同一LVS服務器組要相同
    state MASTER             ##備份LVS服務器設置爲BACKUP
    interface eth0             # #設置對外服務的接口
    virtual_router_id 51        ##設置虛擬路由標識
    priority 100                   #設置優先級，數值越大，優先級越高，backup設置爲99，這樣就能實現當master宕機後自動將backup變爲master，而當原master恢復正常時，則如今的master再次變爲backup。
    advert_int 1            ##設置同步時間間隔
    authentication {         ##設置驗證類型和密碼，master和buckup必定要設置同樣
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {          ##設置VIP，能夠多個，每一個佔一行
        192.168.18.60
    }
}
virtual_server 192.168.18.60 80 {
    delay_loop 6            ##健康檢查時間間隔，單位s
    lb_algo wrr             ##負載均衡調度算法設置爲加權輪叫
    lb_kind DR                              ##負載均衡轉發規則
    nat_mask 255.255.255.0   ##網絡掩碼，DR模式要保障真實服務器和lvs在同一網段
    persistence_timeout 50    ##會話保持時間，單位s
    protocol TCP                           ##協議
    real_server 192.168.18.61 80 {      ##真實服務器配置，80表示端口
        weight 3                             ##權重
        TCP_CHECK {                       ##服務器檢測方式設置 keepalived的健康檢查方式 有：HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK
            connect_timeout 5    ##鏈接超時時間
            nb_get_retry 3         ##失敗重試次數
            delay_before_retry 3 ##失敗重試的間隔時間
            connect_port 80      ##鏈接的後端端口
        }
    }

    real_server 192.168.18.62 80 {
        weight 3
        TCP_CHECK {
            connect_timeout 10
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}

View Code

遺留問題

若是負載均衡服務器宕機了,怎麼辦?

演示備機操做

1：Master掛了，無備機，演示
2：Master掛了，備機自動接管
3：Master好了，備機進入待機狀態

問題2：數據庫出現瓶頸怎麼辦？

以Mysql爲例：
1：對Mysql進行優化（重點講解）
2：緩存,主流緩存Memcached，redis…
3: mysql讀寫分離 + 主從複製
4：Oracle
5：Oracle讀寫分離 + 主從複製
6：Oracle Partition 分區
7：Oracle RAC集羣（終級解決方案）
此方案：很是貴，即便是淘寶，京東這樣的大公司，也是很難受的。

Mysql主從複製與讀寫分離

MySQL主從複製(Master-Slave)與讀寫分離(MySQL-Proxy)實踐
Mysql做爲目前世界上使用最普遍的免費數據庫，相信全部從事系統運維的工程師都必定接觸過。但在實際的生產環境中，由單臺Mysql做爲獨立的數據庫是徹底不能知足實際需求的，不管是在安全性，高可用性以及高併發等各個方面。
所以，通常來講都是經過主從複製（Master-Slave）的方式來同步數據，再經過讀寫分離（MySQL-Proxy）來提高數據庫的併發負載能力這樣的方案來進行部署與實施的。

開始搭建主從複製

服務器二臺：
分別安裝二臺Mysql數據庫
1：安裝命令
yum –y install mysql-server
2:配置登錄用戶的密碼
演示此操做
3：配置容許第三方機器訪問本機Mysql
演示此操做

場景描述

主數據庫服務器：192.168.1.112，MySQL已經安裝，而且無應用數據。
從數據庫服務器：192.168.1.115，MySQL已經安裝，而且無應用數據。

Mysql配置

1：vi /etc/my.cnf

接下來確認slave和master的上的server_id是否正確。能夠分別在slave和master上運行 SHOW VARIABLES LIKE 'server_id'; 來查看server_id是否和你配置的同樣。

啓動Mysql服務器

1：分別從新啓動master,slaver的二臺mysql服務
2：登錄
3：輸入
Mysql> SHOW VARIABLES LIKE 'server_id';
來查看server_id是否和你配置的同樣。
4：master輸入
Mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000005 | 261 | | |
+------------------+----------+--------------+------------------+
記錄下 FILE 及 Position 的值，在後面進行從服務器操做的時候須要用到。

5：配置從服務器
change master to
master_host='192.168.0.104',
master_user='rep1',
master_password='root',
master_log_file='log.000002',
master_log_pos=364;
正確執行後啓動Slave同步進程
6：啓動slave
mysql> start slave;
7：查看slave狀態
mysql> show slave status\G
其中Slave_IO_Running 與 Slave_SQL_Running 的值都必須爲YES，才代表狀態正常。

測試主從複製

1:先肯定主，從庫上沒有任何自定義表

2：主服務器上的操做
在主服務器上建立數據庫itcast_db
mysql> create database itcast_db;
在主服務器上建立表itcast_tb
mysql> create table itcast_tb(id int(3),name char(10));
在主服務器上的表itcast_tb中插入記錄
mysql> insert into itcast_tb values (01, "itcast01");

3:從服務器上查看是否已經同步？

失敗緣由：

1:server_id 配置的同樣或是配置的沒有更新到Mysql數據中來
2:防火牆攔截了3306端口
3:用戶與密碼不正確
4：Mysql不容許其它機器訪問

開始搭建讀寫分離

服務器三臺：
1：安裝二臺Mysql數據庫(已經安裝)
2：安裝mysql-proxy，mysql
場景描述：
數據庫Master主服務器：192.168.1.112
數據庫Slave從服務器： 192.168.1.115
MySQL-Proxy調度服務器：192.168.1.101
如下操做，均是在192.168.1.101即MySQL-Proxy調度服務器上進行的。

Mysql-proxy

1：Mysql安裝
2：檢查系統所需軟件包
經過 rpm -qa | grep name 的方式驗證如下軟件包是否已所有安裝。
gcc* gcc-c++* autoconf* automake* zlib* libxml* ncurses-devel* libmcrypt* libtool* flex* pkgconfig*
libevent* glib* readline*
若缺乏相關的軟件包，可經過yum -y install方式在線安裝，或直接從系統安裝光盤中找到並經過rpm -ivh方式安裝。

3：編譯安裝lua
MySQL-Proxy的讀寫分離主要是經過rw-splitting.lua腳本實現的，所以須要安裝lua。

安裝Lua

cd /opt/install
wget http://www.lua.org/ftp/lua-5.1.4.tar.gz
tar zvfx lua-5.2.3.tar.gz
cd lua-5.1.4
vi src/Makefile
在 CFLAGS= -O2 -Wall $(MYCFLAGS) 這一行記錄里加上-fPIC，更改成 CFLAGS= -O2 -Wall -fPIC $(MYCFLAGS) 來避免編譯過程當中出現錯誤。
make linux
make install

安裝Mysql-proxy

MySQL-Proxy可經過如下網址得到：
http://mysql.cdpa.nsysu.edu.tw/Downloads/MySQL-Proxy/
推薦採用已經編譯好的二進制版本，由於採用源碼包進行編譯時，最新版的MySQL-Proxy對automake，glib以及libevent的版本都有很高的要求，而這些軟件包都是系統的基礎套件，不建議強行進行更新。
而且這些已經編譯好的二進制版本在解壓後都在統一的目錄內，所以建議選擇如下版本：
32位RHEL5平臺：
http://mysql.cdpa.nsysu.edu.tw/Downloads/MySQL-Proxy/mysql-proxy-0.8.4-linux-rhel5-x86-32bit.tar.gz
64位RHEL5平臺：
http://mysql.cdpa.nsysu.edu.tw/Downloads/MySQL-Proxy/mysql-proxy-0.8.4-linux-rhel5-x86-64bit.tar.gz

1：測試平臺爲RHEL5 32位，所以選擇32位的軟件包
wget http://mysql.cdpa.nsysu.edu.tw/Downloads/MySQL-Proxy/mysql-proxy-0.8.3-linux-rhel5-x86-32bit.tar.gz
2：tar xzvf mysql-proxy-0.8.3-linux-rhel5-x86-64bit.tar.gz
3：mv mysql-proxy-0.8.3-linux-rhel5-x86-64bit /opt/mysql-proxy
4：建立mysql-proxy服務管理腳本
mkdir /opt/mysql-proxy/init.d/mysql-proxy
5：cp mysql-proxy /opt/mysql-proxy/init.d/
6：chmod +x /opt/mysql-proxy/init.d/mysql-proxy
7：mkdir /opt/mysql-proxy/run
8：mkdir /opt/mysql-proxy/log
9：mkdir /opt/mysql-proxy/scripts

配置rw-splitting.lua讀寫分離腳本

最新的腳本咱們能夠從最新的mysql-proxy源碼包中獲取
cd /opt/install
wget http://mysql.cdpa.nsysu.edu.tw/Downloads/MySQL-Proxy/mysql-proxy-0.8.4.tar.gz

tar xzvf mysql-proxy-0.8.4.tar.gz
cd mysql-proxy-0.8.4
cp lib/rw-splitting.lua /opt/mysql-proxy/scripts

修改讀寫分離腳本rw-splitting.lua

修改默認鏈接，進行快速測試，不修改的話要達到鏈接數爲4時才啓用讀寫分離
vim /opt/mysql-proxy/scripts/rw-splitting.lua
=============================
-- connection pool
if not proxy.global.config.rwsplit then
proxy.global.config.rwsplit = {
min_idle_connections = 1, //默認爲4
max_idle_connections = 1, //默認爲8
is_debug = false
}
end

啓動mysql-proxy

1：啓動以前編輯啓動腳本
/opt/mysql-proxy/init.d/mysql-proxy

--daemon --log-level=debug --log-file=/var/log/mysql-proxy.log --proxy-backend-addresses="192.168.2.131:3306"  --proxy-read-only-backend-addresses="192.168.2.132:3306" --proxy-lua-script=/opt/mysql-proxy/share/doc/mysql-proxy/rw-splitting.lua

View Code

2：直接mysql-proxy/bin/mysql-proxy直接啓動
修改完成後，啓動mysql-proxy/opt/mysql-proxy/init.d/mysql-proxy start

測試讀寫分離腳本參數詳解：

//定義mysql-proxy服務二進制文件路徑
1：PROXY_PATH=/opt/mysql-proxy/bin 
//定義後端主服務器地址
2：--proxy-backend-addresses=192.168.10.130:3306 
 //定義lua讀寫分離腳本路徑
3：--proxy-lua-script=/opt/mysql-proxy/scripts/rw-splitting.lua「
//定義mysql-proxy PID文件路徑
4： PROXY_PID=/opt/mysql-proxy/run/mysql-proxy.pid
--daemon \ //定義以守護進程模式啓動
--keepalive \ //使進程在異常關閉後可以自動恢復
--pid-file=$PROXY_PID \ //定義mysql-proxy PID文件路徑
--user=mysql \ //以mysql用戶身份啓動服務
--log-level=warning \ //定義log日誌級別，由高到低分別有(error|warning|info|message|debug)
--log-file=/opt/mysql-proxy/log/mysql-proxy.log //定義log日誌文件路徑

View Code

遺留問題

MySQL-Proxy實際上很是不穩定，在高併發或有錯誤鏈接的狀況下，進程很容易自動關閉，所以打開--keepalive參數讓進程自動恢復是個比較好的辦法，但仍是不能從根本上解決問題，所以一般最穩妥的作法是在每一個App服務器上安裝一個MySQL-Proxy供自身使用，雖然比較低效但卻能保證穩定性；