Akka学习笔记（六）：消息传递可靠性
一般规则
关于消息发送，有两条基本规则：
- 最多一次，即不保证消息传递可靠性
- message ordering per sender–receiver pair
消息传递机制
- 最多一次，意味消息有可能丢失
- 最少一次，保证消息传递可靠，但可能冗余
- 保证只成功一次，性能最差，消息成功传递，不冗余
为什么不保证传递可靠性
问题是，我们要保证消息传递在什么环节可靠：
- 消息已经发到网络上了？
- 消息被远程主机接收到了？
- 消息已经在接收者actor的邮箱里了？
- 目标actor是否能处理这个消息?
- 消息在目标actor上开始处理了?
- 消息在目标actor上已经处理完毕了？
上面每一条都有不同的挑战和成本。为什么不需要那么可靠？查看这篇文章
Akka拥抱分布式计算和分布式网络，并通过消息传递来明确实现它，因此它不说谎，而是模拟一个有漏洞的抽象方式。这是在Erlang中取得了重大成功的模型，并要求用户基于此为应用建模。你可以阅读Erlang 文档（10.9, 10.10）了解更多。Akka与它非常相似。
底线：你是一个开发者，知道你的应用中需要提供哪些保证，那么你可以飞快又可靠地使用专门的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
