我一直在寻找一个先进先出的解决方案，生产者和消费者可以部署在多个数据中心，在不同的地区（例如>20ms）。显然，付出了增加延迟的代价，主要目标是透明地处理增加的延迟、延迟峰值、链路故障。
这个理论用例是这样的：

Super Fast Producer --sticky-load-balancing-with-fail-over--> Multi-Region Processors --> 
       Queue(FIFO based on order established by the producer) --> Multi-Region Consumers with fail-over

消费者不应该同时从同一个“队列”消费，但是，这里我们不要考虑缩放方面。如果复制和故障转移在一个“队列”中运行良好，那么分区甚至可以在应用程序级别上应用，而且工作量相当大。
思想：
为了使故障转移正常工作，队列（如消息、使用者偏移量）必须在数据中心之间同步复制。我不明白在失败的情况下，如何在不丢失消息或中断fifo的情况下工作。
kafka stretch群集将是完美的，尽管它可以跨越多个可用区域（<2ms ping和稳定连接），但大多数人建议不要跨越多个区域（>15ms ping，不稳定连接）。
具有同步复制功能的confluent platform 5.4正在预览中，我们可以在应用程序级别进行故障转移，以防本地集群出现故障。因为数据是同步复制的，所以我们不应该在故障转移期间中断fifo或丢失消息。为了确保更活跃的设置，我们可以在数据中心之间定期轮换用户（例如，在非高峰时间每天轮换一到两次）。
db（如cassandra）可以跨多个数据中心/区域处理一致性。然而，队列用例是一种反模式（使用cassandra作为队列）。
第一点是关于纯insert/delete工作负载，这将使db很难删除tombstone。数据库的使用是次优的，但是如果它能可靠地处理工作负载，那就不是问题了
第二点是关于轮询，即使没有数据，使用者也会生成大量的仲裁读取，只用于轮询数据库。同样，伊姆霍Cassandra将可靠地处理这一点，即使这是一个糟糕的使用其能力。
使用带有通知的数据库，如couchdb/db。couchdb的复制是异步的，所以我看不出消费者如何拥有队列的一致视图。对于我来说，我不确定它跨地区工作的可靠性 majority 读写。
您是否在生产中部署了这样的“队列”，您会选择哪一种？