分佈式各種理論學習

分佈式學習

• CAP理論

  • C：一致性。通俗來講就是對於分佈式的系統，如果一個節點改了數據，其他節點要能看到改了以後的數據。官話：通過某個節點的寫操作結果對後面通過其他節點的讀操作可見。如果能保證就是強一致性，如果允許部分或者全部感知不到就是弱一致性。如果能保證最後能看見，那麼就是最終一致性。
  • A：可用性。任何一個沒有發生故障的節點，必須在有限的時間內返回合理的結果。
  • P：分區容忍性。指的分佈式系統中的某個節點或者網絡分區出現了故障的時候，整個系統仍然能對外提供滿足一致性和可用性的服務。

• BASE理論 我覺得說了和沒說一樣，其實就是CA每一個都做了點妥協

  • 基本可用：允許失去一部分可用性，就比如出現了短暫性的故障，導致返回結果的時間延長了1-2s，比如高併發的購物請求，我們把客戶的結果引導到一個降級頁面。
  • 弱狀態：允許不同節點的數據副本之間存在同步延時。
  • 最終一致性：也就是最終一致性，不要求強一致性。

• 限流

  • 降級

    降級是指自己的待遇下降了，從RPC調用環節來講，就是去訪問一個本地的僞裝者而不是真實的服務。 當雙11活動時，把無關交易的服務統統降級，如查看螞蟻深林，查看歷史訂單，商品歷史評論，只顯示最後100條等等。

  • 熔斷

    熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。在微服務架構中，熔斷機制也是起着類似的作用。當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的調用，快速返回錯誤的響應信息。當檢測到該節點微服務調用響應正常後，恢復調用鏈路。

    在Spring Cloud框架裏，熔斷機制通過Hystrix實現。Hystrix會監控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內20次調用失敗，就會啓動熔斷機制。

  • 微服務的雪崩–通過熔斷框架來解決

    A調用B，B調用C，C調用D，但D發生故障的時候，C會進行重試，但是A還是會繼續發請求給B，導致B佔用內存CPU標高，最後大家一起壞掉。

  • SpringCloud的限流zuul

  • 令牌桶：

    想象有一個木桶，系統按照固定速率，例如10ms每次，往桶裏加入Token，如果桶已經滿了就不再添加。新請求來臨時，會各自拿走一個Token，如果沒有Token 就拒絕服務。這裏如果一段時間沒有請求時，桶內就會積累一些token，下次一旦有突發流量，只要token足夠，也能一次處理。

    總結下令牌桶算法的特點，令牌桶即可以控制進入系統的請求請求量，同時允許突發流

  • 漏桶

    限定流出的速度，請求放到桶裏面去，如果滿了，就終止服務。

  • 使用guava的RateLimiter類—只能單機使用，因爲這個類只存在這個服務器上。redis集羣部署（也是一主多從）會保證全局一致性。

    RateLimiter.tryAcquire(時間)，等待獲取令牌如果超過一定時間就結束請求。

    RateLimiter.acquire()，獲取令牌。

  • **漏桶和令牌桶的區別：**從上面的例子估計大家也能看出來了，漏桶只能以固定的速率去處理請求，而令牌桶可以以桶子最大的令牌數去處理請求

  • redis實現：

    hmset rateLimit 
    last_ms 20 			-- 最後時間毫秒
    now_permits 20		-- 當前可用的令牌
    max_permits 40		-- 令牌桶最大數量
    rate 10    --1ms生成多少個令牌
    
    lua的邏輯是:
    if(last_ms == null){ // 如果沒有記錄上一次操作的時間 那麼就是第一次請求
    	now_permits = max_permits - 1; // 初始化40個數量
        last_ms = CURRENT_TIME;
    } else { // 獲取一個token
        now_permits = (CURRENT_TIME - last_ms) * 1000 * rate + now_permits;
        now_permits = Math.min(now_permits,max_permits);
        if(now_permits <=0 ) {
        	return false;
        }    
        now_permits--;
        return true ;
    }
    

• 分佈式和集羣：

  集羣就是一臺機幹不了，我就搞兩臺機。–nginx進行負載均衡

  分佈式是微服務，一個業務拆分成多個業務，分佈在不同的服務器上。

• 異地多活

  就是機房在不同地方，如果一個地方的機房斷電了，其他機房是否能夠一起承擔去往壞機房的請求，其實本質是要解決數據庫的問題，程序什麼的都是一樣的，關鍵是不同機房的數據是否一致，最基本的解決辦法就是分佈式經常用到的多個備份，這個庫的備份是存在其他機房的。

• 分層架構

  就是指ui、業務實現層、持久層。

• 分佈式事務：

  分佈式鎖：保證多個線程或者多個程序操作一個變量的時候，保證這個變量只有一個線程或者程序在使用，保證變量的安全性。

  分佈式事務：保證不同數據庫的一致性

  • 單一架構下的事務（一個服務），我們叫做本地事務，一般就是通過try catch finnally來進行的事務。
  • 多個服務之間的調用，每個服務都會訪問不同的數據庫，保證這整個事務的一致性那麼就是分佈式事務。

• 分佈式事務的解決方案

  1. XA協議的兩段提交–強一致

     由事務管理器來讓某一個服務開始事務，這個服務執行完後把結果返回給事務管理器，當所有的服務事務都成功的時候，事務管理器纔會讓各個服務提交，否則就回滾。

     這種形式需要你在每個服務寫上開啓事務，回滾事務的代碼，事務管理器也要自己實現，一般有實力的公司纔會這麼做。

     缺點：同步阻塞：當管理好幾個服務的事務的時候，其中一個要執行很久，那麼其他的服務已經執行完了也還是在等待那個執行久的，是阻塞的。

     缺點如果事務管理器故障了，那麼大家都阻塞了，尤其是在第二階段，事務也沒提交，也沒回滾，大問題。

  2. 三階段提交3PC

  3. s