❶ python分布式進程中你會遇到的坑
寫在前面
小驚大怪
你是不是在用Python3或者在windows系統上編程？最重要的是你對進程和線程不是很清楚？那麼恭喜你，在python分布式進程中，會有坑等著你去挖。。。(hahahaha，此處允許我嚇唬一下你)開玩笑的啦，不過，如果你知道序列中不支持匿名函數，那這個坑就和你say byebye了。好了話不多數，直接進入正題。
分布式進程
正如大家所知道的Process比Thread更穩定，而且Process可以分布到多台機器上，而Thread最多隻能分布到同一陸坦咐台機器的多個CPU上。Python的multiprocessing模塊不但支持多進程，其中managers子模塊還支持把多進程分布到多台機器上。一個服務進程可以作為調度者，將任務分布到其他多個進程中，依靠網路通信。由於managers模塊封裝很好，不必了解網路通信的細節，就可以很容易地編寫分布式多進程程序。
代碼記錄
舉個例子
如果我們已經有一個通過Queue通信的多進程程序在同一台機器上運行，現在，由於處理任務的進程任務繁重，希望把發送任務的進程和處理任務的進程分布到兩台機器上，這應該怎麼用分布式進程來實現呢？你已經知道了原有的Queue可以繼續使用，而且通過managers模塊把Queue通過網路暴露出去，就可以讓其他機器的進程來訪問Queue了。好，那我們就這么干！
寫個task_master.py
我們先看服務進程。服務進程負責啟動Queue，把Queue注冊到網路上，然後往Queue裡面寫入任務。
請注意，當我們在一台機器上寫多進程程序時，創建的Queue可以直接拿來用，但是，在分布式多進程環境下，添加任務到Queue不可以直接對原始的task_queue進行操作，那樣就繞過了QueueManager的封裝，必須通過manager.get_task_queue()獲得的Queue介面添加。然後，在另一台機器上啟動任務進程（本機上啟動也可以）
寫個task_worker.py
任務進程要通過網路連接到服務進程，所以要指定服務進程的IP。
運行結果
現在，可信沒以試試分布式進程的工作效果了。先啟動task_master.py服務進程：
task_master.py進程發送完任務後，開始等待result隊列的結果。現在啟動task_worker.py進程：
看到沒，結果都出錯了，我們好好分析一下到底哪出錯了。。。
錯誤分析
在task_master.py的報錯提示中，我們知道它說lambda錯誤，這是因為序列化不支持匿名函數，所以我們得修改代碼，重新對queue用QueueManager進行封裝放到網路中。
其中task_queue和result_queue是兩個隊列，分別存放任務和結果。它們用來進行進程間通信，交換對象。
因為是分布式的環境，放入queue中的數據需要等待Workers機器運算處理後再進行讀取，這樣就需要對queue用QueueManager進行封裝放到網路中，這是通過上面的2行代碼來實現的。我們給return_task_queue的網路調用介面取了一個名早純get_task_queue,而return_result_queue的名字是get_result_queue，方便區分對哪個queue進行操作。task.put(n)即是對task_queue進行寫入數據，相當於分配任務。而result.get()即是等待workers機器處理後返回的結果。
值得注意 在windows系統中你必須要寫IP地址，而其他操作系統比如linux操作系統則就不要了。
修改後的代碼
在task_master.py中修改如下：
在task_worker.py中修改如下：
先運行task_master.py,然後再運行task_worker.py
(1)task_master.py運行結果如下
(2)task_worker.py運行結果如下
知識補充
這個簡單的Master/Worker模型有什麼用？其實這就是一個簡單但真正的分布式計算，把代碼稍加改造，啟動多個worker，就可以把任務分布到幾台甚至幾十台機器上，比如把計算n*n的代碼換成發送郵件，就實現了郵件隊列的非同步發送。
Queue對象存儲在哪？注意到task_worker.py中根本沒有創建Queue的代碼，所以，Queue對象存儲在task_master.py進程中：
而Queue之所以能通過網路訪問，就是通過QueueManager實現的。由於QueueManager管理的不止一個Queue，所以，要給每個Queue的網路調用介面起個名字，比如get_task_queue。task_worker這里的QueueManager注冊的名字必須和task_manager中的一樣。對比上面的例子，可以看出Queue對象從另一個進程通過網路傳遞了過來。只不過這里的傳遞和網路通信由QueueManager完成。
authkey有什麼用？這是為了保證兩台機器正常通信，不被其他機器惡意干擾。如果task_worker.py的authkey和task_master.py的authkey不一致，肯定連接不上。
❷ 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 差不多，都是先試探性的執行，如果都可以那就真正的執行，如果不行就回滾。
適用於對實時性要求沒那麼高的業務場景，如：簡訊通知