說明
講師：李智慧
消息隊列與異步架構
同步調用
發郵件時序圖：同步調用，每個調用都會阻塞等待。
同步調用：線程前後執行，都要一步一步同步等待結果。
多個耗時操作同步調用
異步調用
異步調用：寫入消息隊列裏面，就直接返回。1毫秒就可以返回，比同步調用快了1,000倍以上。
有回調的異步調用
多次異步調用，不阻塞應用線程
消息隊列構建異步調用架構
重要角色：
- 消息生產者
- 消息隊列
- 消息消費者
點對點模型
發佈訂閱模型
消息隊列的好處
實現異步處理，提升寫操作處理性能。
支付、訂單等需要消息隊列，提升的是寫操作的性能，特別是雙十一這種大促的時候感受等待的時間比較長。
緩存提升的是讀的性能，消息隊列提升的是寫的性能。
更好的伸縮性
削峯填谷
比如服務器的處理能力爲100TPS，100併發；當來了200TPS，200併發的時候，消息隊列還是按照100TPS，100併發來處理。
失敗隔離和自我修復
因爲發佈者不直接依賴消費者，所以消息系統可以將消費者系統錯誤與生產者系統組件隔離。
生產者和消費者互相不受雙方失敗影響。
這意味着任意時刻，我們都可以對後端服務器執行維護和發佈操作。我們可以重啓、添加或刪除服務器，而不影響生產者可用性，這樣簡化了部署和服務器管理的難度。
解耦
事件驅動架構 EDA (Event Driven Architecture)
同步調用耦合度高、事件驅動異步調用耦合度低
主要 MQ 產品比較
- RabbitMQ 的主要特點是性能好，社區活躍，但是 RabbitMQ 用 Erlang 開發，對不熟悉 Erlang 的同學而言不便於二次開發和維護。（社區 49 Million）
- ActiveMQ 影響比較廣泛，可以跨平臺，使用 Java 開發，對 Java 比較友好。 （社區 27 Million）
- RocketMQ 是阿里推出的一個開源產品，也是使用 Java 開發，性能比較哈，可靠性也比較高。（社區 35 Million）
- Kafka， LinkedIn 出品，Scala開發，專門針對分佈式場景進行了優化，因此分佈式的伸縮性比較好。（社區 63 Million）
負載均衡
負載均衡架構
負載均衡就是把請求分發到服務器上。
負載均衡服務器配置的應用服務器爲內網ip地址。這樣能保護內網服務器的安全。
HTTP 重定向負載均衡
- 用戶訪問一個http請求，DNS解析域名爲ip地址，ip地址指向負載均衡服務器；
- 負責均衡服務器，獲取服務器集羣列表，修改http的header爲集羣中的某臺的服務器地址，告訴客戶端做302跳轉；
- 客戶端請求集羣中的某臺的服務器
- 集羣中的某臺的服務器處理完後，返回response。
重定向服務10來行代碼，就能實現。
缺點：
- 兩次http請求，性能差。
- 暴露了應用服務器的公網ip，安全性很差。
一般不會採用HTTP 重定向負載均衡。
DNS 負載均衡
- 性能方面沒有問題，DNS解析只在第一次請求的時候會用到，後面就記錄在客戶端裏面。而且域名的解析是緩存起來的。
- 安全方面也沒有問題。DNS解析的IP地址是負載均衡服務器的ip地址。
這裏用了2級負載均衡服務器。DNS，和DNS返回的ip地址都是負載均衡服務器。
反向代理負載均衡
小型應用會用，通常10幾臺應用服務器的時候會用。多了以後就不夠用了。爲什麼呢？
因爲反向代理服務器轉發的是http請求，http請求每次通信的時間比較慢，對反向代理服務器的壓力比較大。當併發比較高的時候，反向代理服務器就會成爲瓶頸。
IP 負載均衡
TCP/IP 的數據包比較小，一般是幾K。
- 客戶端發起請求，請求到達負載均衡服務器，負載均衡服務器修改發起的ip爲自己，目標地址爲應用服務器。
- 應用服務器處理請求後返回給負載均衡服務器，負載均衡服務器修改發起的ip爲客戶端，目標地址爲負載均衡服務器，返回給客戶端。
缺點：
請求和響應的壓力都在負載均衡服務器。負載均衡服務器，網卡的出口網絡帶寬會不夠用。
數據鏈路層負載均衡
- 客戶端請求到達負載均衡服務器，負載均衡服務器的網卡和應用服務器的網卡爲一樣，這是虛擬網卡。修改Mac地址，分發給應用服務器，達到負載均衡。
- 應用服務器處理完後，直接返回給客戶端。
LVS
數據鏈路層負載均衡是張文衝，現任 滴滴的首席科學家發明的。
負載均衡算法
- 輪詢：所有請求被依次分發到每個應用服務器上，適合於所有服務器硬件都相同的場景。
- 加權輪詢：根據應用服務器硬件性能的情況，在輪詢的基礎上，按照配置的權重將請求分發到每個服務器，高性能的服務器分配更多的請求。
- 隨機：請求被隨機分配到每個應用服務器，在許多場合下，這種方案都很簡單實用，因爲好的隨機數本身就很均衡。如果應用服務器硬件配置不同，也可以很容易的使用加權隨機算法。
- 最少連接：記錄每個應用服務器正在處理的連接數（請求數），將新到的請求分發到最少連接的服務器上，應該說，這是最符合負載均衡定義的算法。
- 源地址散列：根據請求來源的IP地址進行Hash計算，得到應用服務器，該算法可以保證同一個來源的請求總在一個服務器上處理，實現會話粘滯。
應用服務器集羣的 Session 管理
應用服務器的高可用架構設計主要基於服務無狀態這一特性，但是事實上，業務總是由狀態的，在交易類的電子商務網站，需要有購物車記錄用戶的購買信息，用戶每次國脈請求都是向購物車種增加商品；在社交類網站中，記錄用戶的當前登錄狀態、最新發布的消息以便及時將這些信息通知他的好友。Web應用中將這些狀態信息稱作會話（Session），單機情況下，Session可交給Web容器管理，在使用負載均衡的集羣環境中，Session 管理主要有以下幾種手段。
Session 複製
這種方案是已經淘汰的。每臺服務器都同步session，http請求很重。做集羣本來就是爲了分擔負載均衡，但是session複製又加重了服務器的壓力。計算稍微大一點，就會被session拖垮了。
Session 綁定
相同的IP地址，總是到達相同的服務器。Session綁定，IP地址Hash值的作爲Key去模服務器。
Session綁定是不好的，也已經被淘汰了。爲什麼？
業務的快速發展、快速迭代，7 x 24 小時運轉，沒法支持快速發佈版本。發佈版本的流程爲，關閉應用服務器，發佈新應用，重啓服務器。如果關閉應用服務器，session就丟失了，導致用戶處理失敗，用戶就丟失了。
利用 Cookie 記錄 Session
缺點：每次請求響應，都要維護session，如果瀏覽器禁用cookie，那麼就用不了了。
在Web的時代，這種方案還是比較流行的，生命力強很多。
Session 服務器
分佈式數據庫
MySQL 主從複製
主服務器修改表，更新表數據操作會記錄到Binlog裏面，Binlog會啓動一個客戶端線程，把更新的數據同步到從服務器的Relay Log裏面。
更改字段的流程：
- 增加字段的時候，數據庫表結構要先加字段，應用服務器更新再上線。
- 刪除字段的時候，所有應用服務器先取出該字段，數據庫表結構才能刪掉該字段。
MySQL 一主多從複製
一主多從複製的優點
- 分攤負載
- 專機專用
- 便於熱備份和冷備分
- 高可用
MySQL 主主複製
客戶端線程更新數據，更新數據，追加到binlog，主服務器啓動客戶端線程，主服務器A從
MySQL 主主失效恢復
MySQL 主主失效的維護過程
MySQL 複製注意事項：
- 主主複製的兩個數據庫不能併發寫入。
- 主主複製/主從複製，只是增加了數據的讀併發處理能力，沒有增加寫併發能力和存儲能力。
- 更新表結構會導致巨大的同步延遲。
MySQL支持的記錄量級是千萬級的，千萬不能增加過億的數據。
注意：以上信息如有侵權，請聯繫筆者刪除。謝謝。