【架构设计】-- ACK 机制

1、ACK 机制的定义

        ACK（全称：acknowledgement） 机制是一种确认机制，起源于TCP报文到达确认（ACK）机制（参考：TCP报文到达确认（ACK）机制_tcp接收方在收到一个报文段后,如何回复ack报文?-CSDN博客）。用于确认接收方是否已经正确接收了发送方发送的数据。这种机制的好处是可以保证数据的可靠传输，防止数据的丢失或重复传输。如果没有ACK机制，就无法确保数据的正确性，可能会导致数据传输的失败或者错误。
        虽然也可以使用输入输出流来传输数据，但是这种方式无法保证数据的可靠性，因为在网络通信中，数据的传输可能会受到各种干扰和影响，如网络延迟、丢包等。因此，使用ACK机制可以更好地保证数据的可靠传输，提高数据传输的成功率和效率。

2、ACK 机制在大数据中的应用

2.1 Storm

      大概 13 年前（2011年），Storm 开源，约 8000 行 Clojure 代码组成一个完整的流计算系统，惊艳的设计，巧妙的 Ack 机制解决 At-least-once 的问题。

       ack 机制是 Storm 整个技术体系中非常闪亮的一个创新点，阿里的 JStorm 很好的继承了这个机制，并对原生 Storm 的ack机制做了一点点代码优化。

2.1.1 JStorm 中的 ack 应用

        通过Ack机制，spout发送出去的每一条消息，都可以确定是被成功处理或失败处理， 从而可以让开发者采取动作。比如在Meta中，成功被处理，即可更新偏移量，当失败时，重复发送数据。因此，通过Ack机制，很容易做到保证所有数据均被处理，一条都不漏。

       另外需要注意的，当spout触发fail动作时，不会自动重发失败的tuple，需要spout自己重新获取数据，手动重新再发送一次。ack机制即， spout发送的每一条消息，

• 在规定的时间内，spout收到Acker的ack响应，即认为该tuple 被后续bolt成功处理
• 在规定的时间内，没有收到Acker的ack响应tuple，就触发fail动作，即认为该tuple处理失败，
• 或者收到Acker发送的fail响应tuple，也认为失败，触发fail动作

      另外Ack机制还常用于限流作用： 为了避免spout发送数据太快，而bolt处理太慢，常常设置pending数，当spout有等于或超过pending数的 tuple 没有收到 ack 或fail响应时，跳过执行nextTuple， 从而限制spout发送数据。

      通过设置 spout pend数：

 conf.put(Config.TOPOLOGY_MAX_SPOUT_PENDING, pending); 

2.1.2 JStorm 如何使用 Ack 机制

• spout 在发送数据的时候带上msgid
• 设置acker数至少大于0；Config.setNumAckers(conf, ackerParal);
• 在bolt中完成处理tuple时，执行OutputCollector.ack(tuple), 当失败处理时，执行OutputCollector.fail(tuple); ** 推荐使用IBasicBolt， 因为IBasicBolt 自动封装了OutputCollector.ack(tuple), 处理失败时，请抛出FailedException，则自动执行OutputCollector.fail(tuple)

2.2 Kafka

参考：【Kafka 基础】-- acks 机制_kafka acks-CSDN博客

2.3 RabbitMQ

    在  RabbitMQ 中，有多种方式保证消息的成功投递、成功消费和消息丢失的处理，比较常用的一种就是 ACK 机制。

        ACK 机制是消费者从 RabbitMQ 收到消息并处理完成后，反馈给 RabbitMQ，MQ 收到反馈后才将此消息从队列中删除。消息的ACK确认机制默认是打开的。
      如果一个消费者在处理消息出现了网络不稳、服务器异常等现象，那么就不会有ACK反馈，RabbitMQ会认为这个消息没有正常消费，会将消息重新放入队列。
      如果在集群的情况下，RabbitMQ会立即将这个消息推送给这个在线的其他消费者。这种机制保证了在消费者服务端故障的时候，不丢失任何消息和任务。
      消息永远不会从RabbitMQ中删除，只有当消费者正确发送ACK反馈，RabbitMQ确认收到后，消息才会从RabbitMQ服务器的数据中删除。