Akka： - 为什么不能保证消息到达（发送后）？ 消息的失败率是多少？

Question

It says in the documentation that akka has "at-most once delivery", and that messages are not guaranteed to arrive at destination.

What is the reason for this behavior? What happens to the messages which are not delivered? Are they considered lost?

Edit: I forgot the most important part. Is there a rate of loss I can refer to? Do you know how pessimistic I have to be as regards message delivery guarantee (like is there % rate of failures?).. Just because I have a cluster of actors, and they will be running on the same web-server, and I don't know If I should be thinking if message failures will be 1 in 5, or 1 in 100.

Answer 1

So, Akka actually offers both options of "at-most once delivery" and guaranteed delivery aka "at least once delivery". See the link user1234 posted in the comments for a good introduction into the concepts of "at least once" vs "at most once".

So Akka can do either option. Why is "at most once" the default?

The short answer to your question is that switching to guaranteed delivery has at least five very significant costs:

• Guaranteed delivery in a distributed system requires persistence (otherwise you can't guarantee delivery in case of node failure). This introduces an enormous performance overhead, however.

• Guaranteed delivery in a distributed system introduces the chance of duplicate deliveries. (If you can't confirm delivery, fundamentally the only thing you can do is retry, introducing potential duplicates). For some applications this is problematic. (You can resolve this with de-duping, but this introduces additional overhead and is generally easier to do in application code.) Thus the term "at least once".

• Guaranteed delivery can also affect message order. eg you can either wait for each acknowledgement before attempting the next (which would be insanely slow) or you can deliver retries out of order. Which, for many applications, can be problematic.

• Guaranteed delivery just has a lot more overhead. This includes both the bookkeeping necessary, the memory to basically keep messages around longer, and also the network chatter of acknowledgements.

• Guaranteed delivery also requires persistence, as noted above. But not only does this add overhead as already mentioned, but this just also adds complexity. Especially since this generally means centralized storage if you want to handle failed nodes well and/or expanding/contracting clusters.

So, Akka gives you the choice. But it also cautions you (in that doc) that for most applications it is much easier to handle message delivery failures via application code than by relying on guaranteed delivery. (Both for performance reasons and because guaranteed delivery introduces its own problems like duplicates and out of order messages.)

EDIT: In response to the follow up on how reliable "at most once" messaging is, it's hard to give an exact answer. The key thing to understand is that it's not as if the messaging protocol is inherently unreliable. If your hardware is 100% reliable and your network is 100% reliable and your software is 100% reliable, then your messages will be delivered 100% of the time. But if your network is down then you will lose 100% of your messages. If your destination server crashed due to an NPE, you will lose 100% your messages.

Under normal circumstances all messages will arrive. The only question is how often you experience abnormal circumstances.