❶ 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 差不多,都是先試探性的執行,如果都可以那就真正的執行,如果不行就回滾。
適用於對實時性要求沒那麼高的業務場景,如:簡訊通知