1.10 對存在多個從節點緩存情況
如果架構中存在多個從節點（讀節點），我們需要做好讀節點的負載均衡。雖然多從節點能分攤讀操作壓力，但同時也降低了緩存命中的幾率，我們前面說明MySQL的前端Memcache是使用旁路的工作模式進行緩存的，雖可以做到部分緩存，但是當Memcache沒有對應緩存條目的時候，應用程序會向後端的MySQL查詢，MySQL自身也有緩存功能，但是由於存在對個從節點，而每個從節點之間做了負載均衡，所以應用程序可能查詢同一條數據的時候無法定位到同一個MySQL從節點，這樣就很難緩存命中，從而造成MySQL從節點的資源浪費，為了提高MySQL本地緩存可以得到有力的應用，進一步提到緩存的命中，那麼一般有下面兩種的模式
1、簡單的取模方式
前端應用在向後端發起數據請求時，某個語句如果發往同一個節點，那麼他就始終發往同一個節點。所以可以根據語句做均衡，以後只要是這個語句，就會發送到這個節點上（做法：使用取語法就行了，每個語句在在向後段發起請求時。只需要在應用程序中，對這個查詢語句做hash計算，取得他的校驗碼，對服務器的個數做取模計算。所以某語句特徵碼一樣，那麼他的取模計算也是一樣的。因此同一條語句將會始終發往同一個服務器。）
這種方案存在問題：萬一某個節點掛了，那麼你剩下的將會需要重新取模，那麼程序可能被調整。而且有可能導致之前的緩存全部失效了。所以這種方案並不理想。
2、一致性hash
這種算法很獨特，他不是對服務器節點數取模，而是把服務器每個節點都計算hash類似，對2^32取模，把每個服務器節點順時針分佈在一個虛擬環上。然後當客戶端請求數據的時候，就會根據順時針的來去查找節點，如果真的有一個節點掛了，也只是影響那段區域的緩存數據。
但是這個有可能導致不均衡，但是這個是在所難免的。但是我們可以使用虛擬節點機制，這樣節點就能分佈到不同區域下，每個虛擬節點都是單獨計算的，所以他們落的地方就不同，這樣就容易均衡。
當做好MySQL從節點之間的緩存取模配對，當用戶請求時會先去查詢Memcache中的緩存，有緩存命中則會立即返回，如果未命中，客戶端會向後端從節點發起查詢請求，此時從節點會查詢自身本地的緩存記錄，如有有命中，將記錄返回給客戶端，若沒有命中緩存，則會查看查詢數據庫表中的數據信息。
1.11 主節點單點瓶頸
在主從模型中，寫節點成為了整個架構單點故障所在，那麼我們需要做到MySQL的部署成雙主模型，來實現主節點的高可用。這種解決方案有： MySQL+Proxy，MySQL-MMM, DRBD等技術，建議使用MySQL-MMM技術。
額外說明：除了上面介紹的方法，我們還可以有一個思路，就是做雙寫模型，就是在應用程序層面做設置，當收到寫操作時，將寫操作在兩個主節點都寫一份，而其他從節點只需要同步其中一臺主節點，當一個主節點故障後，立即將從節點同步到新的主節點上完成同步即可，但是這些設置都必須在前端應用程序層面上做操作，道理和上面介紹的一樣，這種方式對於以後系統架構擴展性不高，不建議使用這樣的方法，所以這裡僅僅是給一個思路。
1.12 上傳文件存儲
在應用程序當中，我們需要存儲的可能不單單是結構化數據（也就是MySQL數據）。例如用戶通過應用程序上傳數據，而這些數據應該存儲在文件系統中，能夠提供文件系統的有類似NAS設備，如果用戶需要上傳數據，這個上傳請求就會給予http請求中的put方法上傳的數據保存在文件系統中，通過應用程序向文件系統發起數據請求，通過調用文件服務的API接口（或服務）來完成。
1.13 用戶的讀請求
如果用戶的操作是讀請求的話，此時我們應該做到動態與靜態服務器的分離，通過HAProxy來完成動靜分離，此前我們已經有動態應用服務器，那麼此處我們需要構建靜態服務器（一般會使用Nginx來構建靜態服務器）並且我們需要對靜態服務器配置高可用，那麼可用的方案有 Nginx + Keepalived。使用HAProxy來完成動態內容和靜態內容分離，通過靜態內容服務器所請求的內容一般都是文件系統裡的內容，靜態內容服務器會向後端的文件系統拿到用戶請求的內容後，會構建成http響應報文，然後響應給HAProxy，然後HAProxy再次構建響應報文發回給用戶
1.14 靜態內容緩存
考慮到文件檢索的速率，那麼對於靜態服內容也需要構建緩存，雖然我們可以使用動態部分的Memcache緩存服務器的，但是對於文件靜態內容緩存，使用Varnish或Squid相比之下更有優勢，其中Varnish可以直接響應HAProxy請求，當Varnish沒有數據時，會去趙Nginx，Nginx會從後端檢索數據，然後返回給Varnish，Varnish會將檢索到的數據緩存下來， 然後在響應給HAProxy，最後構建http響應報文返回給客戶端。當然，Nginx本身也存在本地緩存功能，所以可以開啟Nginx本地的緩存功能，所以如果Varnish向Nginx發來請求時，Nginx會先查詢Nginx本地自己的緩存，如果命中將直接返回給Varnish，否者會向後端服務器檢索數據。
1.15 CDN技術
對於中型的web站點，上面架構還是足以應付業務的需要，但是如果對於類似淘寶，京東等這一類大型的網購站點還不不夠，而且還需要注意，對於一些網購站點，訪問高峰時間段，甚至出現搶購這類活動，業務流量將成數倍的增長，所以現在的架構是無法滿足需要，考慮到這些大型的web站點，我們需要藉助於CDN機制，CDN（Content Delivery Network）內容分發網絡，簡單理解是各地搭建緩存服務器，將這些緩存服務器分佈到用戶訪問相對密集的區域或網絡中，利用全局負載均衡技術（GSLB），將用戶訪問的距離指向最近的緩存服務器中，然後由緩存服務器直接響應用戶請求，而且各地緩存服務器還能之間相互進行查找，直到CDN的緩存服務器上都沒有記錄，那麼就會向web站點主服務器去查詢資源，我們知道熱點的關係，其實用戶訪問的將近20%數據（估測）都是經常被訪問的數據，所以使用CDN技術能大大的降低主服務器的查詢請求，而且加快用戶的訪問速度已經用戶體驗，在選擇CDN方面，我們應該選擇至少2個以上的CDN服務提供商，目的也是為了提供線路的可用性。
1.16 監控系統、自動化運維、備份等工具
雖然我們為每個節點都部署高可用，但是隨著業務的不斷增長，傳統型的服務器運維工作已經無法適應業務需求。為了提高業務的穩定性、運維人員工作效率等，我們還需要在部署監控系統、自動化運維工作、備份等工具
① 監控系統
在各節點中部署監控客戶端，監控各節點的性能指標、服務狀態、硬件狀態，實時的將監控數據發送到監控服務器端，若出現數據異常或者節點故障，監控服務器會立即通知運維人員，這樣就能在業務未中斷的條件下預先知道業務中存在威脅，從而立即響應處理故障，保證業務正常穩定的運行。
常用的監控系統開源解決方案：Nagios、Zabbix。
②自動化運維工具
隨著業務不斷增長，所需的服務器節點設備不斷增多，運維人員不可能在一步步重新部署操作系統。而且當業務需要發佈更新，我們需要將所有的更新腳本文件分發至各對應節點，並同步執行更新，而這些操作簡單卻繁瑣，僅僅重複相同操作。類似這種情況，我們需要部署自動化運維工具，將這些操作通過自動化運維工具部署完成，從而增加運維人員的工作效率。
常見的自動化運維工具開源解決方案：Ansible、Puppet、Cobbler
③備份工具
數據對於企業而言是十分重要，雖然現在存儲技術可以使用RAID技術來保障數據的安全性，由於可能不可控因素，或者是系統出現操作失誤或系統故障導致數據丟失，將有可能導致不可預估的損失。而這就是備份的重要性，所以保證數據的安全性，也防範於未然。
常見的備份工具開源解決方案：Bacula
閱讀更多 編程小能手 的文章
