?

#####################################################? #本文內容來自《老男孩linux運維實戰培訓》學生—鄭東旭? #如有轉載，請務必保留本文鏈接及本版權信息。? #歡迎廣大運維同仁一起交流linux/unix網站運維技術!? #QQ:919953500 #E-mail:weilandeshanhuhai@126.com? =====================================================? 老男孩linux運維實戰培訓中心? 咨詢QQ:?70271111?357851641
咨詢電話：18911718229? 網站地址：?http://www.etiantian.org? 老男孩博客:?http://oldboy.blog.51cto.com
老男孩的QQ:?31333741
##################################################### 本文說明： 綠色為重點?紅色為警告或注意藍色為提示或說明黑色為正常輸出 =============================================================================== 面試經驗談架構 1、四層七層負載均衡綜合架構... 2 (1)、架構說明... 2 (2)、用戶訪問流程... 2 (3)、為什么要使用七層負載均衡... 3 (4)、CDN網絡說明... 3 2、LB層... 3 (1)、LVS原理... 3 1)、NAT模式-網絡地址轉換... 3 2)、TUN模式-隧道模式... 3 3)、DR模式-直接路由... 4 4)、FullNAT模式... 4 (2)、DR模式的問題... 4 思考：為什么要綁定VIP. 4 思考：為什么要抑制ARP. 4 思考：RS沒有公網地址(dr模式)出站流量怎么走(這個問題有待考證). 4 (3)、LVS調度算法... 4 (4)、keepalived高可用兩大功能... 5 1)、LVS directors failover功能... 5 2)、LVS cluster nodes healthchecks 功能（未完成）... 5 (5)、心跳和腦裂簡單介紹... 6 3、Proxy層... 6 4、App層... 6 (1)、lamp & lnmp. 6 (2)、Java. 6 (3)、MFS. 6 (4)、Gateway(網關服務器)6 5、Cache層... 6 (2)、memcache原理... 6 (2)、什么是Session. 7 (3)、Session共享方案... 7 6、DB層... 7 (1)、MySQL主從同步解決方案... 7 (2)、MySQL讀寫分離... 7 (3)、MySQL備份方案... 7 (4)、MySQL高可用... 7 (4)、MySQL高可用腦裂注意事項... 8 面試經驗談架構 把以前的知識復習一遍，并連串起來 1、四層七層負載均衡綜合架構

? (1)、架構說明 綠色線條為正常數據走流，紅色線條為備用線路數據走流，藍色線為掛載存儲，CDN網絡中紅色為同步數據走流 (2)、用戶訪問流程 用戶請求到達VIP地址(公網地址，與域名綁定)，由四層負載均衡LVS根據自身的算法將用戶請求轉發到七層負載均衡Proxy代理服務器，代理服務器根據用戶的請求(可判斷head頭部信息)判斷用戶請求的資源(如：如果用戶使用手機訪問，代理服務器將請求wap業務機，如果用戶使用電腦訪問，代理服務器將請求web業務機)， (3)、為什么要使用七層負載均衡 有些公司會有如下的需求，是四層負載均衡做不到的 (1)、代理服務器根據用戶的請求(可判斷head頭部信息)判斷用戶請求的資源(如：如果用戶使用手機訪問，代理服務器將請求wap業務機，如果用戶使用電腦訪問，代理服務器將請求web業務機) (2)、如果內網服務器跑多個應用，比如啟動多個基于IP地址的虛擬主機，代理服務器可將用戶訪問一個地址，轉發到不同的應用服務器 (3)、四層和七層負載均衡在中小企業首選七層負載均衡，等以后架構擴展在前端添加四層負載均衡(原因：七層負載均衡配置簡單，不像lvs需要對后端服務器配置操作，并且七層負載均衡可以抵擋千萬PV) (4)、CDN網絡說明 當有西藏的用戶訪問電子商城，如果直接訪問北京機房的電子商城，速度會非常緩慢，，大大減少用戶訪問速度 各地機房放兩臺CDN節點服務器(電信和聯通) (1)、無CDN節點訪問流程 西藏聯通用戶直接訪問北京服務器(綠色線)，延遲非常大，有可能頁面顯示"無法顯示該頁面" (2)、CND節點訪問流程 1)、西藏聯通用戶請求到智能DNS解析域名 2)、通過智能DNS解析最近西藏機房域名后返回給用戶，用戶請求到西藏機房 3)、如果西藏機房CDN中無用戶請求資源，CDN代替用戶從上海或北京CDN節點請求用戶資源，應答給用戶 4)、請求后的資源緩存到本地CDN節點 2、LB層 lvs+keepalived四層負載均衡高可用 (1)、LVS原理 1)、NAT模式-網絡地址轉換 通過網絡地址轉換，用戶發送請求包到調度器(負載均衡器)的VIP地址，調度器重寫請求報文的目標地址，根據預設的算法，將請求分發給后端的真實服務器，真實服務器響應報文通過調度器時，調度器重寫報文的源地址，再返回給用戶，完成整個負載調度過程 應用范圍：由于LVS/NAT模式入站和出站的流量都經過LB，大于處理的后端真實服務器是10-20臺 2)、TUN模式-隧道模式 采用NAT模式時，由于請求和響應報文都經過負載均衡器地址重寫，當客戶端請求越來越來越多時，調度器的處理能力將成為瓶頸，為了解決這個問題，調度器通過算法把請求的報文通過IP隧道(加密的相當于ipip，或ipsec)分發至后端真實服務器，后端真是服務器將響應直接發送給客戶端，這樣調度器只處理請求的報文，由于一般網絡服務應答數據比請求報文大很多，采用VS/TUN技術后，集群系統的最大吞吐量可以提高10倍 說明：LVS/TUN不改IP地址，是通過隧道轉發，開啟隧道會有系統開銷，并且響應報文不經過負載均衡器，由真實服務器直接響應給用戶 應用范圍：LVS/TUN在互聯網中用的不多，它可以處理局域網的請求也可處理廣域網的請求 3)、DR模式-直接路由 LVS/DR模式通過修改請求報文的MAC地址，將請發送發給后端真是服務器，后端真是服務器將響應直接返回給用戶，和VS/TUN模式一樣，VS/DR模式可極大提高集群系統的伸縮性，它沒有IP隧道的開銷，集群系統對后端真是服務器也沒有必須支持IP隧道協議的要求，但是要求調度器和所有后端真是服務器都有一塊網卡連在同一物理網段上(都在一個網段上)(最后一段話重要，加顏色)，因為他是通過數據鏈路層ARP協議實現的 1、客戶端計算機CIP請求被發送到LVS調度器VIP 2、LVS調度器收到目標地址為VIP的請求包后，將該數據包的目的MAC地址通過算法改成某一臺RS的MAC地址，并通過交換機發送個這臺RS服務器，(因為目的MAC地址是RS服務，所以RS服務器可以接受該數據包)注意：此時數據包的目標IP地址和源IP地址沒有發生任何改變 3、RS服務器收到發來的數據報文請求后，會從鏈路層上傳到IP層，此時IP層需要驗證請求的目標IP地址，因為包的目標IP地址(Director的VIP地址)并不像常規數據包那樣為RS的本地IP，而僅僅目的MAC地址是RS的 這個時候RS的IP層是驗證不過的，因為數據包的目的MAC地址是自己的，數據包目的的IP地址卻不是自己的，那么這個時候，網絡層就不會把包上傳到傳輸層來處理這個數據包 所以在RS上需要配置一個VIP的loopback device,因為loopback device是服務器本地使用的網絡接口，對外是不可見的，與LVS的VIP不會沖突，(會有一個ARP抑制問題)（RS收到的數據包在自己的網絡層驗證不過，所以要配置一個loopback device上綁定一個IP地址） 4、RS處理數據包完成后，將應答包直接返回給客戶端CIP，(此時數據包報文的源地址為客戶端請求的目的地址VIP，而目的地址為客戶端的CIP)，應答數據包不會在經過LVS調度器。因此，如果是對外提供LVS負載均衡服務，則RS需要連上互聯網(公網IP或網關)才能將應答包返回給客戶端，生產環境中RS最好有帶公網IP的服務器，這樣可以不經過網關直接回應客戶端，如果多個RS使用了同一個出口網關，網關可能會成為LVS架構的瓶頸，會大大降低LVS的性能 說明：為什么RS能直接回應給客戶端，因為客戶端的請求包報文的源地址和目的地址都沒有被調度器在網絡層改動，所以根據以太網的協議，回應數據包可以將請求的數據包的源IP當前目的IP，把目標IP當前源IP 應用范圍：互聯網公司常用的模式 4)、FullNAT模式 1、可以跨VLAN通信，支持更多的后端RS 2、有防DDOS模塊 應用范圍：淘寶新出的一種模式，占未廣泛使用 (2)、DR模式的問題 思考：為什么要綁定VIP 過程原理：當客戶端的請求包到達路由器，路由器會發出廣播誰是VIP，負載均衡器會響應，負載均衡器收到請求包通過自身的算法選擇一臺RS，(比如RS1)修改客戶端請求包的目的MAC地址為RS1的MAC地址并發送給RS1，這個時候RS1的數據鏈路層把請求包給網絡層，網絡層需要驗證請求包的目標IP地址不是自己就會丟掉此包(此時的數據包源IP是CIP，目的IP是VIP)，這個時候需要在RS節點上綁定VIP 思考：為什么要抑制ARP 過程原理：當客戶端的請求包到達路由器，路由器會發出廣播誰是VIP，這個時候，擁有VIP的負載均衡器和RS真實服務器都會響應這個包，導致無法正常工作，所以還有對RS做ARP抑制 思考：為什么VIP要綁定RS的lo網卡上 RS綁定VIP地址，一般情況下是綁定到lo網卡上，但我們也可以綁定到其他虛擬網卡，比如eth0:10，設置改網卡的ARP功能即可 思考：RS沒有公網地址(dr模式)出站流量怎么走(這個問題有待考證) 負載均衡為DR模式，后端RS沒有公網IP地址，如何將用戶請求直接返回給用戶 答案： 應答請求不走LB，直接從路由器返回 (3)、LVS調度算法

算法	說明
rr?輪詢調度(Round-Robin)	它將請求一次分配不同的RS，也就是在RS中均攤請求，算法簡單，但是只適合于RS處理性能相差不大的情況(多個服務器硬件配置差不多)
wrr加權輪詢調度(Weighted Round-Robin)	它根據RS不同的權值分配任務，權值高的RS優先獲得請求，分配到的連接數將比權值低的RS更多，權值相同的RS得到的連接數數目相同
wlc加權最小連接數調度(Weighted Least-Comnection) (WLC)	具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。 假設各臺RS的權值一次為Wi(l = 1..n),當前的TCP連接數依次為Ti(l=1..n)一次選取Wi/Ti為最小的RS作為下一個分配的RS
dh?目的地址哈希調度(Destination Hashing)	以目的地址為關鍵字查找一個靜態hash表來獲得需要的RS
sh?源地址哈希調度(Source Hashing)	以源地址作為關鍵字查找一個靜態hash表來獲取需要的RS
LBLC 基于局部性的最少鏈接（Locality-Based Least Connections）	針對目標IP地址的負載均衡，目前主要用于Cache集群系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用“最少鏈接” 的原則選出一個可用的服務器，將請求發送到該服務器。
LBLCR 帶復制的基于局部性最少鏈接（Locality-Based Least Connections with Replication）	也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。它與LBLC算法的不同之處是它要維護從一個目標 IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按“最小連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按“最小連接”原則從這個集群中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。
DH 目標地址散列（Destination Hashing）	根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
SH 源地址散列（Source Hashing）	根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
SED 最短的期望的延遲（Shortest Expected Delay Scheduling SED）	基于wlc算法 ABC三臺機器分別權重123 ，連接數也分別是123。那么如果使用WLC算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用sed算法后會進行這樣一個運算 A(1+1)/1 B(1+2)/2 C(1+3)/3 根據運算結果，把連接交給C 。
NQ 最少隊列調度（Never Queue Scheduling NQ）	無需隊列。如果有臺realserver的連接數＝0就直接分配過去，不需要在進行sed運算

提示：現在大約有12中算法常用的有算法有：rr,wrr,wlc (4)、keepalived高可用兩大功能 1)、LVS directors failover功能 ha failover 功能：實現LB Master主機和LB Backup主機之間故障轉移和自動切換 這是針對有兩個負載均衡器Director同時工作而采取的故障轉移措施，當主負載均衡器(Master)失效或出現故障時，備份負載均衡器(Backup)將自動接管主負載均衡的所有工作，一旦主負載均衡器(Master)的故障恢復，Master又會接管原來處理的工作，而備份負載均衡器(Backup)會釋放Master失效時它接管的工作，此時兩者將恢復到各自最初的角色狀態 2)、LVS cluster nodes healthchecks 功能 rs healthcheck功能：負載均衡定時檢查RS的可用性決定是否給分發請求 當虛擬服務器中的某一個甚至多個真實服務器同時發生故障無法提供服務時，負載均衡器會自動將失效的RS服務器從轉發列隊中清除出去，從而保證用戶的訪問不受影響，當故障的RS服務器修復以后，系統又會自動的將它們加入到轉發列隊中，分發請求提供正常服務 (5)、心跳和腦裂簡單介紹 心跳：heartbeat：主節點和備節點相互檢測對方是否存活 腦裂：split-brain：兩端都認為對端有問題，備節點無法檢測到主節點的心跳(一般是心跳線故障)，各自都自動起VIP，這種沖突的問題就叫裂腦 3、Proxy層 haprox/nginx/apache七層負載均衡 前文已經說過了“為什么要使用七層負載均衡” 4、App層 (1)、lamp & lnmp 生產環境中web應用程序只用一種，要么apache要么nginx，圖中只是作者在做實驗時，將兩者混用了 (2)、Java 有些公司的頁面是由java編寫的，而使用java容器，場景的java容器有：tomcat resin weblogic jboss跑java程序 前兩者是免費的，后兩者是收費的 (3)、MFS 分布式文件系統，解決nfs單點故障問題 1)、MFS讀進程機制 1、客戶端向元數據服務器發出讀請求 2、元數據服務器吧所需數據存放的位置(Chunk Server的IP地址和chunk編號)告知客戶端 3、客戶端向已知的Chunk Server請求發送數據 4、Chunk Server向客戶端發送數據 特點：數據傳輸并不通過元數據服務器，這樣既減輕了元數據服務器的壓力，同時也增大了整個系統的吞吐能力，在多個客戶端讀取數據時，會被分散到不同的數據服務器請求 2)、MFS寫進程機制 1、客戶端向元數據服務器發送寫請求 2、元數據服務器與Chunk Server進行交互(只有當所需的分塊Chunks存在的時候才進行交互) (1)、元數據服務器只在某些服務器創建新的分塊chunks (2)、Chunk Server告知元數據服務器，步驟a已經操作成功 3、元數據服務器告知客戶端，你可以在哪個Chunk Server的哪些chunks寫入數據 4、客戶端向指定的Chunk Server寫入數據 5、Chunk Server與其他的Chunk Server進行數據同步 6、Chunk Server之間同步成功 7、Chunk Server告知客戶端數據寫入成功 8、客戶端告知元數據服務器本次寫入完畢 (4)、Gateway(網關服務器) 有上網需求時：內網服務器通過該網關服務器上網 5、Cache層 memcached應用非常廣泛，如：數據庫的查詢請求、session同步、前端web用戶請求 (2)、memcache原理 1.接到客戶請求后首先查看請求的數據是否在mem中存在，如果存在，直接返回給用戶 2.如果不存在，就去查詢數據庫，把從數據庫中獲得的數據返回給用戶，同時存在mem中一份，以后再有用戶需要這個數據就直接返回給用戶 3.每次更新了數據庫(增刪改查)以后，mem會同時更新數據，保證memcache中的數據和數據庫的數據一致 4.當分配給memcache內存空間用完后，會使用LRU(Least Recently Used最近最少使用)策略加到期失效策略，失效的數據首先被替換掉，然后在替換掉最近未使用的數據 5.服務停止后，緩存中的數據就會丟失 (2)、什么是Session 說明：該圖片由網友所畫 存放用戶登錄信息 集群環境 一個用戶訪問請求被分配到服務器A，并且在服務器A登錄了，并且在很短的時間，這個用戶又發出了一個請求，如果沒有會話保持功能的話，這個用戶的請求很有可能會被分配到服務器B去，這個時候用戶在服務器B上是沒有登錄的，所以又要重新登錄，但是用戶并不知道自己的請求被分配到了哪里，用戶的感覺就是登錄了，怎么又要登錄，用戶體驗很不好。 session文件 #ls /tmp sess_4tsn40hhhk4fjpc5nfqd7klla4? sess_eoej5vhddfnqulbjef24dqq926? sess_qjr829a27dhascevs36mg5c855 sess_53kcemteriqguf7q847nnsj4n3 (3)、Session共享方案 1).基于NFS的Session共享 2).基于數據庫的Session共享 3).基于Cookie的Session共享 4).基于Memcache的Session共享(推薦) 6、DB層 (1)、MySQL主從同步原理 面試必問 (1)、當有數據寫入到master，執行的SQL語句會寫入到binlog日志中(select查詢語句不記錄) (2)、Slave的IO線程會通過Master上授權的復制用戶請求連接Master服務器，請求從指定Binlog日志文件的指定位置之后的Binlog日志內容(日志文件和位置是在配置主從服務時執行change master命令時指定的) (3)、Master服務器接收到Slave服務器的IO線程請求后，Master上負責復制的IO線程根據Slave上的IO線程請求的信息讀取指定Binlog日志文件制定位置之后的Binlog日志內容，然后返回給Slave端的IO線程，返回的信息中還包括本次返回的binlog日志內容后在Master服務端的新的Binlog文件名稱以及Binlog的位置點 (4)、Slave的IO線程獲取到來自Master的IO線程發來的日志內容及日志文件及位置點后，將新的binlog日志位置點存放到master-info中，以便下次讀取Master端新Binlog日志時能夠告訴Master需要從新Binlog日志的那個文件那個位置開始請求新的Binlog日志內容。并將Binlog日志內容一次寫入到Slave端自身的Relay Log(中繼日志)文件的最末端(MySQL-relay-bin.xxxx) (5)、Slave端的SQL線程會實時的檢測本地Relay Log新增加的日志內容，然后及時的把Real Log文件的內容解析成在Master端曾經執行的SQL語句的內容，并在自身Slave上按語句的順序執行應用這些SQL語句 (6)、經過上面的過程，就可以確保在Master端和Slave端執行了同樣的SQL語句，當復制狀態正常情況下，Master端和Slave端的數據完全一致 (2)、MySQL主從同步注意事項 1、主庫和從庫的版本要完全相同 2、主庫和從庫的server-id不能一樣(一般為IP地址的最后一位) 3、主庫需要開啟binlog日志功能，從庫無需開啟binlog日志功能，除非做雙主模式和級聯復制模式 (3)、MySQL主從同步解決方案 方案一：MySQL主從同步 方案二：MySQL一主多從架構 方案三：MySQL多實例主從同步(互為主從) 方案四：MySQL雙主架構 方案五：MySQL多主(拆庫拆表) 方案六：MySQL級聯復制 (4)、MySQL讀寫分離 由開發人員參與 (5)、MySQL備份方案 備份時，從庫停止SQL線程，備份后開啟SQL線程，保證不丟失數據，如果要求比較嚴格可以備份binlog日志 (6)、MySQL高可用 mysql+heartbeat+drbd mysql+heartbeat+replication mysql+heartbeat+存儲 說明：也可以用keepalived做高可用軟件 (7)、MySQL高可用腦裂注意事項 數據庫腦裂非常危險，會導致數據不一致， (8)、MySQL高可用腦裂解決方法 R710有四個網口，一般無特殊情況只用其中兩個，剩下兩個在插兩根心跳線

轉載于:https://blog.51cto.com/shanhu/1069909

總結

以上是生活随笔為你收集整理的面试经验谈架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。