接收器关闭时如何备份消息？答案

【问题标题】：How to back up messages when sink is down?接收器关闭时如何备份消息？
【发布时间】：2018-02-01 08:53:55
【问题描述】：

我们正在集思广益，在以下情况下什么是好的行为：

我们有大约 30 个服务器，它们每秒向接收器发布大约 300 条消息
水槽偶尔会掉下来，但我们不知道什么时候和多久
服务器在 Auto Scaling 组中，可以随时关闭时间（即我们不能在服务器中保存/存储未发布的消息本地）

在这种情况下，当接收器关闭时，发布商的推荐行为是什么？

更具体的问题是：

推荐用于故障转移的辅助存储是什么？ - 文件系统、数据库、队列
故障转移行为应该是什么
接收器恢复正常后恢复消息的好策略是什么

【问题讨论】：

您可以拥有多个水槽吗？源和汇之间的传输是什么？水槽为什么会失效？

标签： architecture high-availability failover fallback

【解决方案1】：

第一种方法：我会建议一些不完全是您正在寻找的答案的东西。我有非常相似的情况。但是向接收器发送消息的服务器（在我的例子中是 NServiceBus）被允许保留消息，以防它们向接收器发送消息失败（因为接收器已关闭）。我的服务器也是 Auto Scaling 计划的一部分。但是我使用的是 AWS，它允许终止生命周期挂钩（如果不满足某些条件，基本上允许推迟终止），所以我用它们尝试推迟终止，直到所有消息都成功发送（服务器有一个 API 可以通过 AWS 促进这一点拉姆达函数）。如果超时，我们将拍摄服务器快照并稍后恢复消息。

第二种方法：这更多是为了让您的消息队列（即接收器）具有高可用性。现在，我认为从服务器到接收器的消息传递可能由于多种原因而失败（可能是服务器驱动程序错误或服务器有一些内部错误等，或者到接收器的线路坏了！）所以发送消息的系统必须能够存储消息。对于基于消息的分布式系统，拥有故障安全消息发送器和高可用性接收器是绝对必要的。因此，如果您必须努力使您的水槽具有高可用性；您可以通过将接收器置于负载平衡器后面并拥有多个服务器或在发送消息时选择辅助接收器的非常规方式（这容易出现服务器内部问题）来使接收器具有高可用性。不完全是你的答案，但这份 Kafka 架构文档会让你深思 https://www.infoq.com/articles/apache-kafka

【讨论】：

第一种方法，如何保留失败的消息？存储在磁盘中？
@gyoho 是的。在我们的例子中，它是 MSMQ。我们必须备份整个 MSMQ 系统驱动器（以避免编写自定义代码以导出到其他地方）。