2016-08-24 71 views
4

我有一個聚合了一些信息並處理它的演員。目前,它看起來像這樣:如果我有一個演員,該怎麼辦應該有很大的節奏?

class MessageTracerActor extends Actor{ 

    override def receive: Receive = { 
     case MyActor.TracableMessage(msg) => //send processed msg to another place 
     case v: Any => //corner-case, has special handler 
    } 
} 

演員應該要發送的延長TracableMessage消息的痕跡。但TracableMessages是從相當多的演員發送和主機MessageTracerActor在一臺機器上不是很好。

我看着cluster shrading,但這似乎並非如此。他們說,當你比有一個適合機器 很多演員狀態 一起消耗更多的資源(例如內存)

集羣分片通常使用。如果你只有幾狀態的演員,可能更容易 一個集羣辛格爾頓節點上運行它們。

但是,Cluster Singleton嚴格地託管在一個不可伸縮的節點上。

也許有與我可以指定線程用於處理由演員收到的郵件數量(甚至節點)的一些配置選項?

+3

我是一個新手,阿卡,但不會是有意義的使用阿卡路由器/ routees增加吞吐量,而不是隻用一個演員。 – Samar

+0

@Samar有趣的是,我讀了這篇文章。在他們的例子中,他們自己創造了演員。在羣集的情況下,我將不得不手動部署演員到特定的節點。也許分片更好,因爲它本身可以跨節點傳播分片。 –

+0

路由器可以將消息發送到分佈式系統中其他節點上的路由。這是一個解釋路由器/ routee策略以增加吞吐量的鏈接。 https://www.packtpub.com/books/content/dispatchers-and-routers – Samar

回答

4

有幾個選項可以將消息處理擴展到單個參與者之外。

在單個節點

如果跟蹤消息處理是無狀態的傳播的消息處理,您可以分發使用routing跟蹤消息處理者的多個實例之間的工作。路由器是一個建立處理角色池的角色,並將處理角色之間的每個傳入消息進行分配。

// create a round robin style router for actors 
val router: ActorRef = context.actorOf(RoundRobinPool(5).props(Props[MessageTracerActor]), "tracer-router") 

在上面的例子中,循環式路由器用於均勻分配消息在跟蹤者之間。這意味着您將失去發送給路由器的消息之間的訂購保證:稍後排入隊列的消息可能在之前入隊的消息之前處理。由於每個消息處理器只能看到傳入消息的任意子集,因此聚合等有狀態處理也不能一致地完成。

爲了使順序一致,你要想想什麼樣的信息需要在順序。如果所有的tracable消息都需要按照它們進入路由器的順序進行處理,那麼路由器不會爲你提供很多幫助。但是,某些可跟蹤消息可能需要按照與某些消息相關的順序進行處理,而不是其他消息。例如,您的可跟蹤消息可能包含消息來源,並且只能在來自同一來源的消息之間保證排序。

識別信息之間的次序可以讓你以一致的方式發佈消息處理器之間的消息。 Akka使用consistent hashing pools爲此提供了功能。在一致性散列池中,路由器根據散列鍵機制將傳入消息分發給消息處理器。具有相同路由哈希鍵的消息將被路由到同一個消息處理器,這意味着您可以始終如一地對傳入消息進行聚合,以處理一部分可跟蹤消息。

跨多個節點

如果一個節點阿卡是不夠的處理tracable信息傳播的消息處理,您可以縮放消息用阿卡的clustering features處理。在集羣中,您有多個Akka節點相互連接,通過在集羣中分發工作而不是在單個節點中處理所有內容來一起工作。

在集羣中,您有分佈式版本的前述工具可用。對於消息的無狀態和有狀態路由,您可以使用a cluster aware router。羣集感知路由器在羣集成員節點上創建消息處理器池,而不是在單個節點中創建它們。

除了集羣感知路由器,您還可以使用cluster sharding。就像在一致的哈希池中一樣,您需要爲集羣分片指定一個哈希鍵,以便將消息一致地路由到正確的參與者。羣集感知路由器和分片之間的區別在於分片會爲每個密鑰自動創建一個actor,因此消息處理器actor不需要分別處理來自不同密鑰的消息。

如果所有的tracable消息都需要在相同的狀態下進行聚合,您的最終選擇是考慮Akka的distributed data功能。在此功能中,聚合工作分佈在多個節點上,並在稍後階段加入。請注意,分佈式數據API在Akka 2.4中仍處於試驗階段。

其他領域尋找到

分佈在多個節點的消息處理裝置,有個人消息處理器滴的風險較高(例如網絡連接失敗,節點崩潰)。爲了保持狀態在節點之間持久和可轉移,您可能需要查看Akka的persistence功能。

相關問題