Service Fabric 可靠參與者和 I/O 操作

Question

在 Microsoft 提供的文檔Service Fabric Reliable Actors Introduction 中，它指出 Actor 不應“通過發出 I/O 操作來阻止具有不可預測延遲的調用者”。

我有點不確定如何解釋這一點。

這是否意味着只要請求的延遲是可預測的，I/O 就可以了？

或者

這是否意味着最佳實踐是 Actor 不應在 Service Fabric 之外進行任何 I/O 操作？ 例如：某些 REST API 或寫入某種數據庫、數據湖或事件中心。

Answer 1

從技術上講，兩者兼而有之。

因為actor是單線程的，actor中只能同時發生一個操作。

SF Actor 使用 Ask 方法，其中每個調用都期望得到應答，調用者會不斷調用並等待應答，如果 Actor 收到太多來自客戶端的調用，並且這個 Actor 過於依賴外部組件，則它會占用太多時間long 處理每個調用，所有其他客戶端調用都將排隊，並且可能會在某些時候失敗，因為它們將等待太長時間和超時。

這對於使用 Tell 方法的演員來說不是大問題，例如 Akka，因為它不會等待答案，它只是將消息發送到郵箱並接收帶有答案的消息（如果適用）。 但是請求和響應之間的延遲仍然是一個問題，因為有太多消息等待單個參與者處理。 另一方面，如果一個命令失敗，可能會增加復雜性，並且在您知道第一個事件的答案之前觸發了 2 或 3 個事件序列（不是這里的范圍，但您將這種情況與下面的示例聯系起來）。

關於第二點，Actor 的主要思想是自包含，如果它過於依賴外部依賴，也許你應該重新考慮設計並評估 Actor 是否實際上是解決問題的最佳設計。

自包含的actor 是可擴展的，它們不依賴於外部狀態管理器來管理自己的狀態，它們不會依賴其他actor 來完成他們的任務，它們可以相互獨立地擴展。

例子：

Actor1（ActorTypeA）依賴Actor2（ActorTypeB）來執行操作。

為了讓它更人性化，讓我們說：

• ActorTypeA 是電子商務結賬車
• ActorTypeB 是股票管理
• Actor1 是用戶 1 的購物車
• Actor2 是產品 A 的庫存

每當客戶（用戶）與他的結賬車交互，添加或刪除產品時，它都會向 Actor1 發送添加和刪除命令來管理他自己的購物車。 在這種情況下，依賴是一對一的，當另一個用戶導航到網站時，將為他創建另一個角色來管理他自己的購物車。 在這兩種情況下，他們都會有自己的演員。

現在讓我們說，每當將產品放入購物車時，它都會保留庫存以避免重復銷售相同的產品。

在這種情況下，兩個 actor 都會嘗試在 Actor2 中保留產品，並且由於 Actors 的單線程性質，只有第一個會成功，第二個會等待第一個完成，如果產品不再有庫存，則失敗。 此外，第二個用戶將無法在他的購物車中添加或刪除任何產品，因為第一個操作正在等待完成。 現在將這些數字增加數以千計，看看問題如何快速發展和可擴展性失敗。

這只是一個小而簡單的例子，所以，第二點不僅僅針對外部依賴，它也適用於內部依賴，actor 之外的每一個操作都會降低它的可擴展性。

就是說，您應該盡可能避免外部（actor 之外）依賴，但如果需要，這不是犯罪，但是當外部依賴限制其獨立擴展時，您會降低可擴展性。

我回答的另一個 SO 問題可能對您也很有趣。