[TOC] # RabbitMq怎么保證高可用 RabbitMQ是一個比較有代表性的消息中間件，因為是基于主從做的高可用架構、我們就以它為例子來聊下其高可用是如何實現的。 RabbitMQ有三種模式：單機模式、普通集群模式、鏡像集群模式。 ## 1.1 單機模式 單機模式就是處于一種demo模式、一般就是自己本地搞一個玩玩，生產環境沒有那個哥們會使用單機模式的。 ## 1.2 普通集群模式  ](images/screenshot_1615898622499.png) 如上圖是普通集群模式 1、RabbitMQ在多臺服務器啟動實例、每臺服務器一個實例、當你創建queue時、queue（元數據+具體數據）只會落在一臺RabbitMQ實例上、但是集群中每個實例都會同步queue的元數據（元數據：真實數據的描述如具體位置等）。 2、當用戶消費時如果連接的是另外一個實例，當前實例會根據同步的元數據找到具體的數據所在的實例從其上把具體數據拉過來消費。 這種方式的缺點很明顯，沒有做到所謂的分布式、只是一個普通的集群。這種方式在消費數據時要么隨機選擇一個實例拉去數據、要么固定連接那個queue所在的實例來拉取數據，前者導致一次實例見拉取數據的開銷、而后在會導致單實例性能的瓶頸。 而且如果存放數據的queue的實例宕機了、會導致其它實例無法從該實例來拉取數據了，如果你開啟了RabbitMQ的持久化功能，消息不一定會丟失，但是得等待這個實例重啟后才能繼續從該queue拉取數據。 所以總的來說這事就比較尷尬了，就完全沒有所謂的高可用一說了，這個方案主要的目的是提高吞吐量的，就是說讓集群中的多個節點來服務某個queue的讀寫操作。 ## 1.3鏡像集群模式  這種集群模式真正達到了RabbitMQ高可用性，和普通集群不一樣的是你創建的queue不管是元數據還是里面的具體消息都會存在于所有的實例上。每次寫消息時都會把消息同步到每個節點的queue中去。 這種方式的優點在于，你任何一個節點宕機了、都沒事兒，別的節點都還可以正常使用。 缺點： 1、性能開銷太大，消息同步到所有的節點服務器會導致網絡帶寬壓力和消耗很嚴重。 2、這種模式沒有擴展性可言，如果你某個queue的負載很高，你加機器，新增的機器也包含了這個queue的所有數據，并沒有辦法線性擴展你的queue. 這里在多說下如何開啟鏡像集群模式？其實開啟很簡單在RabbitMQ的管理控制臺，新增一條策略、這個策略就是開啟開啟鏡像集群模式策略、指定的時候可以指定數據同步到所有的節點，也可以要求同步到指定的節點數量，之后你在創建queue時使用這個策略、就會在動降數據同步到其它節點上去了。  # Zookeeper怎么支持高可用 **高可用**：Zookeeper 系統中只要集群中存在超過一半的節點（這里指的是投票節點即非 Observer 節點）能夠正常工作，那么整個集群就能夠正常對外服務 # Redis怎么保證高可用 ## 1.如何保證Redis高可用和高并發? Redis主從架構，一主多從，可以滿足高可用和高并發。出現實例宕機自動進行主備切換，配置讀寫分離緩解Master讀寫壓力。 ## 2.Redis高可用方案具體怎么實施？ 使用官方推薦的哨兵(sentinel)機制就能實現，當主節點出現故障時，由Sentinel自動完成故障發現和轉移，并通知應用方，實現高可用性。它有四個主要功能： * 集群監控，負責監控redis master和slave進程是否正常工作。 * 消息通知，如果某個redis實例有故障，那么哨兵負責發送消息作為報警通知給管理員。 * 故障轉移，如果master node掛掉了，會自動轉移到slave node上。 * 配置中心，如果故障轉移發生了，通知client客戶端新的master地址。 ## 3.你能說說Redis哨兵機制的原理嗎？ 通過sentinel模式啟動redis后，自動監控master/slave的運行狀態，基本原理是：心跳機制+投票裁決。每個sentinel會向其它sentinal、master、slave定時發送消息，以確認對方是否活著，如果發現對方在指定時間內未回應，則暫時認為對方宕機。若哨兵群中的多數sentinel都報告某一master沒響應，系統才認為該master真正宕機，通過Raft投票算法，從剩下的slave節點中，選一臺提升為master，然后自動修改相關配置。 # Kafka怎么保證高可用 Kafka不是完全同步，也不是完全異步，是一種特殊的ISR（In Sync Replica）。 ISR（in-sync replica） 就是 Kafka 為某個分區維護的一組同步集合，即每個分區都有自己的一個 ISR 集合，處于 ISR 集合中的副本，意味著 follower 副本與 leader 副本保持同步狀態，只有處于 ISR 集合中的副本才有資格被選舉為 leader。 ## Kafka的Replica 1. kafka的topic可以設置有n個副本（replica），副本數最好要小于等于broker的數量，也就是要保證一個broker上的replica最多有一個。 2. 創建副本的單位是topic的分區，每個分區有1個leader和0到n-1follower，Kafka把多個replica分為Lerder replica和follower replica。 3. 當producer在向topic partition中寫數據時，根據ack機制，默認ack=1，只會向leader中寫入數據，然后leader中的數據會復制到其他的replica中，follower會周期性的從leader中pull數據，但是對于數據的讀寫操作都在leader replica中，follower副本只是當leader副本掛了后才重新選取leader，follower并不向外提供服務。 ## Kafka ISR機制 **ISR副本：** 就是能跟首領副本基本保持一致的跟隨副本，如果同步的速度太慢的話，就會被踢出ISR副本。 **副本同步：** * LEO（last end offset）：日志末端位移，記錄了該副本對象底層日志文件中下一條消息的位移值，副本寫入消息的時候，會自動更新 LEO 值。如果LE0 為2的時候，當前的offset為1。 * HW（high watermark）：高水印值，HW 一定不會大于 LEO 值，小于 HW 值的消息被認為是“已提交”或“已備份”的消息，并對消費者可見。 * producer向leader發送消息，之后寫入到leader，leader在本地生成log，之后follow從leader拉取消息，follow寫入到本地的log中，會給leader返回一個ack信號，一旦收到了ISR中的所有的ack信號，就會增加HW，然后leader返回給producer一個ack。 ## Kafka的復制機制 kafka 每個分區都是由順序追加的不可變的消息序列組成，每條消息都一個唯一的offset 來標記位置。 kafka中的副本機制是以分區粒度進行復制的，在kafka中創建 topic的時候，都可以設置一個復制因子(replica count)，這個復制因子決定著分區副本的個數，如果leader 掛掉了，kafka 會把分區主節點failover到其他副本節點，這樣就能保證這個分區的消息是可用的。leader節點負責接收producer 發過來的消息，其他副本節點（follower）從主節點上拷貝消息。 \[站外圖片上傳中...(image-31f1f9-1614765714779)\] kakfa 日志復制算法提供的保證是當一條消息在producer端認為已經committed的之后，如果leader 節點掛掉了，其他節點被選舉成為了 leader 節點后，這條消息同樣是可以被消費到的。 **關鍵配置:** [unclean.leader.election.enable](https://kafka.apache.org/documentation/#brokerconfigs_unclean.leader.election.enable) ~~~ Indicates whether to enable replicas not in the ISR set to be elected as leader as a last resort, even though doing so may result in data loss Type: boolean Default: false Valid Values: Importance: high Update Mode: cluster-wide ~~~ 默認為 `false`, 即允許不在isr中replica選為leader，這個配置可以全局配置，也可以在topic級別配置。 這樣的話，leader選舉的時候，只能從ISR集合中選舉，集合中的每個點都必須是和leader消息同步的，也就是沒有延遲，分區的leader 維護ISR 集合列表，如果某個點落后太多，就從 ISR集合中踢出去。 producer 發送一條消息到leader節點后， 只有當ISR中所有Replica都向leader發送ACK確認這條消息時，leader才commit，這時候producer才能認為這條消息commit了，正是因為如此，kafka客戶端的寫性能取決于ISR集合中的最慢的一個broker的接收消息的性能，如果一個點性能太差，就必須盡快的識別出來，然后從ISR集合中踢出去，以免造成性能問題。 **如何判斷副本不會被移除ISR集合？** `replica.lag.max.messages` : follower副本最大落后leader副本的消息數。(0.9.0.0版本后移除)。 `replica.lag.time.max.ms`: 不僅指自從上次從副本獲取請求以來經過的時間，而且還指自上次捕獲副本以來的時間。 設置`replica.lag.max.messages`為3，只要 follower 只要不落后leader 大于2條消息，就然后是跟得上leader的節點，就不會被踢出去。 設置 replica.lag.time.max.ms 為 300ms， 意味著只要 follower 在每 300ms內發送fetch請求，就不會被認為已經dead ，不會從ISR集合中踢出去。 ## 結語 Replica的目的就是在發生意外時及時頂上，leader失效后，就需要從follower中馬上選一個新的leader 。選舉時優先從ISR中選定，因為這個列表中follower的數據是與leader同步的，從他們中間選取可以保證數據完整 。 但如果不幸ISR列表中的follower都不行了，就只能從其他follower中選取，這時就有數據丟失的可能了，因為不確定這個follower是否已經把leader的數據都復制完成了。 還有一種極端情況，就是所有副本都失效了，這時有兩種方案： * 等待ISR中的一個活過來，選為Leader，數據可靠，但活過來的時間不確定 。 * 選擇第一個活過來的Replication，不一定是ISR中的，選為leader，以最快速度恢復可用性，但數據不一定完整。 Kafka支持通過配置選擇使用哪一種方案，可以根據可用性和一致性進行權衡。 # Zookeeper的CAP CAP理論告訴我們，一個分布式系統不可能同時滿足以下三種 一致性（C:Consistency） 可用性（A:Available） 分區容錯性（P:Partition Tolerance） 這三個基本需求，最多只能同時滿足其中的兩項，因為P是必須的,因此往往選擇就在CP或者AP中。 **在此ZooKeeper保證的是CP** 分析：可用性（A:Available） **不能保證每次服務請求的可用性**。任何時刻對ZooKeeper的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性；但是它不能保證每次服務請求的可用性（注：也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果）。所以說，ZooKeeper不能保證服務可用性。 **進行leader選舉時集群都是不可用**。在使用ZooKeeper獲取服務列表時，當master節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行leader選舉。問題在于，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓，雖然服務能夠最終恢復，但是漫長的選舉時間導致的注冊長期不可用是不能容忍的。所以說，ZooKeeper不能保證服務可用性。 ————————————————