1. python面試之分布式
主要用於分散壓力,所以分布式的服務都是部署在不同的伺服器上的,再將服務做集群
根據「分層」的思想進行拆分。
例如,可以將一個項目根據「三層架構」 拆分
然後再分開部署 :
根據業務進行拆分。
例如,可以根據業務邏輯,將「電商項目」拆分成 「訂單項目」、「用戶項目」和「秒殺項目」 。顯然這三個拆分後的項目,仍然可以作為獨立的項目使用。像這種拆分的方法,就成為垂直拆分
主要用於分散能力,主要是將服務的顆粒度盡量細化,且自成一脈,壓力這塊並不是其關注的點,所以多個微服務是可以部署在同一台伺服器上的
微服務可以理解為一種 非常細粒度的垂直拆分 。例如,以上「訂單項目」本來就是垂直拆分後的子項目,但實際上「訂單項目」還能進一步拆分為「購物項目」、「結算項目」和「售後項目」,如圖
現在看圖中的「訂單項目」,它完全可以作為一個分布式項目的組成元素,但就不適合作為微服務的組成元素了(因為它還能再拆,而微服務應該是不能再拆的「微小」服務,類似於「原子性」)
分布式服務需要提供給別的分布式服務去調用,單獨拆出來 未必外部可用
微服務自成一脈,可以系統內部調用,也可以單獨提供服務
為什麼需要用分布式鎖,見下圖
變數A存在三個伺服器內存中(這個變數A主要體現是在一個類中的一個成員變數,是一個有狀態的對象),如果不加任何控制的話,變數A同時都會在分配一塊內存,三個請求發過來同時對這個變數操作,顯然結果是不對的!即使不是同時發過來,三個請求分別操作三個不同內存區域的數據,變數A之間不存在共享,也不具有可見性,處理的結果也是不對的。
分布式鎖應該具備哪些條件:
1、在分布式系統環境下,一個方法在同一時間只能被一個機器的一個線程執行;
2、高可用的獲取鎖與釋放鎖;
3、高性能的獲取鎖與釋放鎖;
4、具備可重入特性;
5、具備鎖失效機制,防止死鎖;
6、具備非阻塞鎖特性,即沒有獲取到鎖將直接返回獲取鎖失敗
Redis性能高
命令簡單,實現方便
使用setnx加鎖,key為鎖名,value隨意不重復就行(一般用uuid)
給鎖添加expire時間,超過該時間redis過期(即自動釋放鎖)
設置獲取鎖的超時時間,若超過時間,則放棄獲取鎖
通過鎖名獲取鎖值
比較鎖值和當前uuid是否一致,一致則釋放鎖(通過delete命令刪除redis鍵值對)
2PC:two phase commit protocol,二階段提交協議,是一種強一致性設計。
同步阻塞(導致長久的資源鎖定) ,只有第一階段全部正常完成(返回失敗,回字返回超時都會返回 「准備失敗」 ),才會進入第二階段
因為協調者可能會在任意一個時間點(發送准備命令之前,發送准備命令之後,發送回滾事務命令之前,發送回滾事務命令之後,發送提交事務命令之前,發送提交事務命令之後)故障,導致資源阻塞。
T:try,指的是預留,即資源的預留和鎖定,注意是預留
C:confirm,指的是確認操作,這一步其實就是真正的執行了
C:cancel,指的是撤銷操作,可以理解為把預留階段的動作撤銷了
從思想上看和 2PC 差不多,都是先試探性的執行,如果都可以那就真正的執行,如果不行就回滾。
適用於對實時性要求沒那麼高的業務場景,如:簡訊通知