解析：分布式應用框架Ray架構源碼 -4

Actor 管理

Actor 創建

Actor的創建任務是由GCS服務來進行調度的，如下圖

在Python代碼中創建一個Actor時，負責創建的worker首先同步注冊actor到GCS中，這樣可以確保Actor被創建之前worker就failure的場景下，所有的worker使用Actor的reference都可以發現這個failure

一旦actor創建任務的所有輸入依賴都被解析完成，creator會將task specification 發送給GCS Service。 GCS Service會通過分布式調度協議（與普通task一樣）調度創建actor的task，這是GCS就好像是這個創建task的owner， 由于GCS server會將所有的狀態數據持久化到后端存儲，一旦task specification被成功的發給了GCS Service， actor會立刻被創建出來。

句柄的原始創建者可以開始在actor句柄上提交任務，甚至在GCS調度參與者之前將其傳遞給其他任務/參與者。創建actor后，GCS會通過Pub-sub通知任何具有actor句柄的worker。每個句柄都緩存新創建的actor的運行時元數據（例如，RPC地址和它所在的節點）,在參與者句柄上提交的任何掛起任務都可以發送到actor執行。

Actor 任務執行

如上圖，創建后，actor任務將轉換為對actor進程的直接gRPC調用。一個actor可以處理許多并發呼叫，盡管在這里我們只顯示一個。

每個提交的任務都在調用方端分配了一個序列號，接收方使用該序列號來確保每個調用方的任務都按照提交的順序執行，不管消息在過程中是否重新排序，不保證調用者之間的任務執行順序。例如，調用者之間的執行順序可能會根據消息延遲和任務依賴項可用的順序而有所不同。

Actor Death

actor可以是detached，也可以是non-detached,默認actor都是non-detached，可以用于存儲臨時狀態，當actor的父級或作業退出時，應自動收集其物理資源。

對于non-detached 的actor，當actor的所有掛起任務都已完成，并且actor的所有句柄都超出范圍（通過引用計數跟蹤）時，actor的原始創建者通知GCS服務。然后，GCS服務向actor提交一個特殊的`ray_terate’任務，該任務將讓actor優雅地退出其進程。如果GCS檢測到創建者已經退出（通過心跳表發布），也會終止actor。然后，在此actor上提交的所有掛起任務和后續任務都將失敗，并出現RayActorError。

如上圖，Actor終止任務也通過GCS調度。

actor也可能在其運行時意外崩潰（例如，從segfault或調用sys.exit）。默認情況下，提交給崩潰的actor的任何任務都將失敗，并出現RayActorError，就像actor正常退出一樣。

Ray還提供了一個選項，可以自動重新啟動actor，最多可以指定次數。如果啟用此選項，GCS服務將嘗試通過重新提交其創建任務來重新啟動崩潰的actor。所有具有句柄的客戶端都將將任何掛起的任務緩存，直到重新啟動actor。如果actor不可重新啟動或已達到最大重新啟動次數，客戶端將使所有掛起的任務失敗。

第二個選項可用于在參與者重新啟動后啟用失敗的參與者任務的自動重試。這對于冪等任務和用戶不需要自定義處理RayActorError的情況非常有用。

參考代碼:

src/ray/core_worker/core_worker.cc

src/ray/common/task/task_spec.h

src/ray/core_worker/transport/direct_actor_transport.cc

src/ray/gcs/gcs_server/gcs_actor_manager.cc

src/ray/gcs/gcs_server/gcs_actor_scheduler.cc

src/ray/protobuf/core_worker.proto

Global Control Store

全局控制存儲（GCS）保存關鍵但訪問頻率較低的群集元數據，如連接的客戶端和節點的地址。在Ray的早期版本（<0.8）中，GCS還保存了小對象元數據，這意味著GCS處于大多數系統操作的關鍵路徑上，例如任務調度。在較新版本的Ray (0.8+)中，對象和元數據大部分已經上移動到worker中，允許GCS在大多數系統操作期間不處于關鍵路徑，這導致了整體性能的提高，并降低了GCS存儲要求。

存儲

GCS目前在Redis中實現，我們依賴Redis進行發布。但是，正在努力刪除redis依賴項，并啟用可插拔持久存儲（例如MySQL）。

Actor Table中包含了actor及其狀態的列表，這個表用于在失敗時重新創建演員，并管理演員生存期。

Heartbeat Table 保存連接到Ray的客戶端、worker和節點的列表。

每個raylet定期向GCS發送心跳，以指示節點處于活動狀態，并報告其調度程序線程當前資源使用情況和負載的信息。GCS定期聚合來自raylet的所有心跳，以減少網絡帶寬使用，并將聚合廣播回所有節點。這用于確定群集成員資格和分布式調度，廣播信息也用于自動伸縮。

如果GCS在可配置的心跳間隔數內沒有聽到來自raylet的消息，GCS將raylet標記為已死，并將此消息廣播到所有節點。這就像一個墓碑：如果raylet聽說它已被標記為已死，并且它的物理資源只能通過啟動新的raylet來重用，該raylet被分配了不同的唯一ID。

Job Table 保存了群集中運行的作業列表，當作業被終止時，Ray將取消作業創建的正在運行的task和actor，以避免資源泄漏。

Object Table保存了大型共享內存對象的節點位置，Raylet使用redis pub-sub訂閱感興趣的對象并在對象可用時獲得通知，選擇要從中下載對象數據的節點。當在共享內存中本地創建或刪除對象時，Raylet負責更新此表。

社區目前正在努力將對象表從GCS移動到所有權表，以提高可擴展性和分布式對象傳輸性能。

Profiling 事件存儲在Profile Table中，是用LRU淘汰機制。

持久化

GCS目前不提供持久化，盡管正在努力通過通用SQL數據庫啟用可插拔存儲。Redis設置了最大大小，使用LRU淘汰非關鍵數據。但是，對于Ray (0.8+)的最新版本，超過此最大大小是非常罕見的，因為大多數對象和任務元數據不再存儲在GCS中。

代碼參考：

src/ray/gcs/gcs_server/gcs_server.cc

src/ray/protobuf/gcs.proto

src/ray/protobuf/gcs_service.proto

RPC 任務調度 分布式

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。