關於訊息傳送，有兩條基本規則：
問題是，我們要保證訊息傳遞在什麼環節可靠：
訊息已經發到網路上了？
訊息被遠端主機接收到了？
訊息已經在接收者actor的郵箱裡了？
目標actor是否能處理這個訊息?
訊息在目標actor上開始處理了?
訊息在目標actor上已經處理完畢了？
上面每一條都有不同的挑戰和成本。為什麼不需要那麼可靠？檢視這篇文章
底線：你是乙個開發者，知道你的應用中需要提供哪些保證，那麼你可以飛快又可靠地使用專門的ack和retry來實現（如果你真的需要，大多數情況你並不需要）。使用akka的durable郵箱會有幫助。
actor a1 傳送訊息 m1, m2, m3 給 a2 actor a3 傳送訊息 m4, m5, m6 給 a2
意味著:
如果 m1 被投遞了，那麼它一定在 m2 和 m3之前被投遞
如果 m2 被投遞了，那麼它一定在 m3之前被投遞
如果 m4 被投遞了，那麼它一定在 m5 and m6之前被投遞
如果 m5 被投遞了，那麼它一定在 m6之前被投遞
a2 收到 a1 的訊息會與收到的 a3的訊息交織在一起
因為沒有投遞保證，所以可能會「沒有」，或有「一些」，或「全部」訊息到達 a2
Akka學習筆記 Actor訊息傳遞 2
文章目錄 hide 3 teacher actor 我們在前面僅僅討論了actorref的quoterequest，並沒有看到message的類！這裡將介紹，如下 1packageme.rerun.akkanotes.messaging.protocols 2 3objectteacherproto...
訊息佇列學習筆記2 可靠傳遞 重複消費 秒殺設計
二 訊息的重複消費 三 秒殺系統的簡單設計 思考題在生產階段，訊息佇列通過最常用的請求確認機制，來保證訊息的可靠傳遞。只要 producer 收到了 broker 的確認響應，就可以保證訊息在生產階段不會丟失。有些訊息佇列在長時間沒收到傳送確認響應後，會自動重試，如果重試再失敗，就會以返回值或者異常...
Akka學習筆記06 Actor的訊息
向actor傳送訊息，分為兩種方式 1.tell，或者使用符號 沒有返回值。寫法如下 actor msg or actor.tell msg or actor tell msg 如果需要指定傳送訊息的actor，可以寫成 actor.tell msg,anotheractorref 2.ask，或者...