上篇文章主要講了如何使用Akka作異步任務處理。最后還拋出一個問題。
具體問題的描述就不在這篇文章贅述了拷呆，我們僅簡單回顧一下第一種解決方案：覆寫persistenceId()時，加一個UUID疫粥，這樣三臺服務器上的Actor就不會再共享journal茬斧。雖然這個方案已經(jīng)可以解決問題了，但并不是最理想的梗逮。首先项秉，現(xiàn)在的項目中只是用akka處理一些無狀態(tài)的任務異步處理，但是將來肯定要用akka作更多的事情慷彤。比如娄蔼，緩存怖喻，DAO這些可以設計成有狀態(tài)的，而現(xiàn)在actor重啟時是不能replay消息消息歷史的岁诉，所以這樣不能最大限度發(fā)揮actor的優(yōu)勢锚沸。還有，我的目標是把所有的后端server構建為一個邏輯上的server涕癣，現(xiàn)在他們?nèi)匀皇侨齻€各自為營的獨立server哗蜈。因此我又繼續(xù)作了一些調(diào)研，最終發(fā)現(xiàn)了Cluster Singleton坠韩。
文檔上給出了Cluster Singleton的適用場景：
- 集群中的單點決策距潘，或者協(xié)調(diào)
- 統(tǒng)一外部系統(tǒng)出口
- 一主多從
- 統(tǒng)一命名服務或路由邏輯
第二點正好就是我們的場景。下邊看一下如何使用Cluster Singleton只搁。
- 添加依賴（我用的構建工具是Gradle）
compile("com.typesafe.akka:akka-cluster_2.11:${akkaVersion}")
compile("com.typesafe.akka:akka-cluster-tools_2.11:${akkaVersion}")
- 創(chuàng)建actor
actorSystem.actorOf(ClusterSingletonManager.props(
SpringExtProvider.get(actorSystem).props("NotificationActor"),
PoisonPill.getInstance(),
ClusterSingletonManagerSettings.create(actorSystem).withRole("master")
), "notification-master");
notificationActor = actorSystem.actorOf(
ClusterSingletonProxy.props(
"/user/notification-master",
ClusterSingletonProxySettings.create(actorSystem).withRole("master")),
"notification-proxy");
創(chuàng)建actor比原來復雜了音比。首先要創(chuàng)建一個ClusterSingletomManager。ClusterSingletonManager也是一個Actor须蜗，它會在Cluster的每個節(jié)點上都啟動起來（或者集群擁有某些角色的節(jié)點）。ClusterSingletomManager.props要傳入三個參數(shù)目溉，第一個是需要創(chuàng)建Singleton實例的Actor配置明肮；第二個是當Manager關閉時要給它管理的Actor發(fā)送什么消息；第三個缭付，集群部署配置柿估，即指定ClusterSingletomManager在哪些集群Node上啟動。
接下來ClusterSingletonManager會選擇一個最老的實例并在上面創(chuàng)建Actor單例陷猫。ClusterSingletonManager可以確保整個集群中至多有一個singleton的實例秫舌，言下之意，存在沒有singleton實例的時刻绣檬。比如cluster node crash足陨，原有的singleton實例丟失，這時需要重新選舉新最老的ClusterSingletonManager娇未，然后創(chuàng)建新的singleton實例墨缘。
訪問Singleton Actor需要借助于ClusterSingletonProxy，ClusterSingletonProxy會把所有的消息forward給當前被代理的Actor實例零抬。因為有可能某些時刻是沒有singleton actor實例的镊讼，所以遇到這種情況ClusterSingletonProxy會先把消息緩存，當新的Actor單例創(chuàng)建之后平夜，再把緩存的消息轉(zhuǎn)發(fā)過去蝶棋。
當然，Cluster Singleton也有它的問題忽妒，比如單點潛在的性能問題玩裙，而且singleton actor并不是100%可用兼贸。但相比于第一種方案，顯然這個要更接近我的期望献酗。
write on 2017-1-10
