现状：目前我有几十个网站将html表单数据发送到收集服务器。 然后，此集合服务器稍后将数据重新发送到处理服务器。 让处理服务器出现故障没什么大不了的，但丢失表单数据意味着失去我的工作。
目标：我想确保没有单点故障会阻止收集 html 表单数据。
可能的解决方案：我的方法是拥有 3 台服务器，然后将 html 表单数据从网站发送给它们中的每一个。 我想要某种方法来确保只有一个潜在客户副本从收集服务器传递到处理服务器。
#Users fill Form Data It is Captured Redundantly And processed here
website01 -> collectionServer01 -> processingServer
website06 collectionServer02
website24 collectionServer03
website#N
我认为这被称为分布式队列？？
问：假设这是我描述的分布式队列，这是实现我的目标的好方法吗？ 人们还有其他使用方式吗？ 您建议如何确保只有一个副本从集合服务器发送到处理服务器？
正确理解你的问题，你有这样的东西
Some Website
Another Website Intake Server Processing Server
(reliable) (unreliable)
Yet Another Website
（客户？）潜在客户从许多不同的网站流向您的接收服务器，然后转发到处理服务器。 您担心您的接收服务器出现故障，因为这是您负责跟上的原因。
此问题的经典解决方案是在负载均衡器后面有 2 个或更多 Intake 服务器，并有一个主数据库和至少一个从数据库。
为了避免在失去数据中心时失去服务的风险（还记得日本的海啸吗？）是在多个数据中心运行您的设置，并使用地理负载平衡将流量发送到最近的数据中心，或者，如果发生故障，则发送到其他数据中心之一。
在这种情况下，您可能希望在各个数据中心之间复制所有数据（例如，主/主数据库，使用本地从属数据库进行冗余，或数据中心A中的主数据库加上数据中心A中的从数据库加上数据中心B中主A的从属数据库等）。
我多次成功地使用了这种安排。 有些服务以非常可靠的方式管理地理负载平衡（尽管它们并不便宜）。
如果接收服务器出现故障，负载均衡器会检测到这种情况并将流量路由到其余的接收服务器。 如果主数据库出现故障，则切换到从数据库并恢复主数据库。
对于负载平衡，下面是一些常规信息。 我在使用 NGinX 和 HAProxy 作为负载均衡器方面拥有丰富的经验。
如果您将所有数据发送到所有数据中心，那么当您考虑到可能会丢失一个或多个数据中心时，协调哪个数据中心向处理服务器发送哪些线索的任务非常重要（您如何知道它在出现故障之前发送了哪些线索？ 您如何决定哪个数据中心应该发送哪个潜在客户？ 即使您有一个"主"数据中心和一个"热备用"数据中心，如果"主"出现故障，如果它们不像复制的数据库解决方案那样不断同步状态，那么知道"热备用"需要在哪里工作也不是一件容易的事。
其中一位评论者提到（几次）可以使用分布式队列来解决这个问题。 这也是一条可行的途径，但我的经验比我描述的解决方案少。