使用Akka持久化——消息发送与接收

前言

在《使用Akka持久化——持久化与快照》一文中介绍了如何使用Akka持久化消息及生成快照。对于集群应用来说，发送者发出消息，只有当收到了接受者的成功回复才应当认为是一次完整的请求和应答（一些RPC框架只提供了远程调用、序列化/反序列化的机制，但是具体调用的成功与否实际是抛给了开发者本人），利用Akka的应答机制很容易实现这些功能。特殊情况下发送者发送了消息，但是最终接受者却没有接收到消息，导致这一情况发生的因素很多（例如：发送者调用完发送接口后，发送者所在进程奔溃了；网络故障；接收者不存在等）。如果这些消息的成功接收与处理对于整个应用而言具有强一致性的要求，那么这些都会导致很多困扰，好在我们可以使用Akka的持久化机制。

发送者在发送消息之前先对消息进行持久化，那么无论任何原因导致没有收到接收者的成功回复时，我们总能有办法从持久化信息中找出那些未被成功回复的消息进行重发（这说明接收者接到的消息有可能会重复，此时需要保证接收者的实现是冥等的）。当接收者收到消息进行处理后需要向发送者发送成功回复，发送者收到回复后的第一个动作应当是对回复内容的持久化，否则有可能在还未真正对成功回复处理时宕机或进程奔溃导致回复消息丢失（在持久化与收到消息之间仍然会存在宕机和进程奔溃的情况，只不过这个时间非常短，因此丢失回复的可能会很低），当持久化回复消息完成后，可以自己慢慢来处理这些确认信息，而不用担心它们丢失了。

本文将根据Akka官网的例子，对其做一些适应性改造后，向大家展示Akka持久化的另一个强大武器——At least once delivery！

消息投递规则

一般而言，消息投递有下面三种情况：

• at-most-once 意味着每条应用了这种机制的消息会被投递0次或1次。可以说这条消息可能会丢失。
• at-least-once 意味着每条应用了这种机制的消息潜在的存在多次投递尝试并保证至少会成功一次。就是说这条消息可能会重复但是不会丢失。
• exactly-once 意味着每条应用了这种机制的消息只会向接收者准确的发送一次。换言之，这种消息既不会丢失也不会重复。

at-most-once的成本最低且性能最高，因为它在发送完消息后不会尝试去记录任何状态，然后这条消息将被他抛之脑后。at-least-once需要发送者必须认识它所发送过的消息，并对没有收到回复的消息进行发送重试。exactly-once的成本是三者中最高的而且性能却又是三者中最差的，它除了要求发送者有记忆和重试能力，还要求接收者能够认识接收过的消息并能过滤出那些重复的消息投递。Akka的Actor模型一般提供的消息都属于at-most-once，那是因为大多数场景都不需要有状态的消息投递，例如web服务器请求。当你有强一致性需求时，才应该启用Akka的at-least-once机制，那就是你的Actor不再继承自UntypedActor，而是继承自UntypedPersistentActorWithAtLeastOnceDelivery。

配置

如果要使用，那么需要在中增加以下的一些配置：

    at-least-once-delivery {
      redeliver-interval = 20000
      redelivery-burst-limit = 100
    }

redeliver-interval用于配置重新进行投递尝试的时间间隔，单位是毫秒。redelivery-burst-limit用于配置每次重新执行投递尝试时发送的最大消息条数。

<