我的出发点实际上是发件箱模式。
为了确保发件箱中的消息只中继一次，我们在k8s集群中只有一个发件箱服务的副本可用。可以肯定的是，此服务的部署策略设置为Recreate。任何时候都不应该有两个服务同时读取和中继。
现在，我想说，从高可用性的角度来看，这是一种反模式，因为服务故障切换时间可能太长了。
我也知道有一种领导人选举模式，即多个部门就一个领导人达成一致，然后只有领导人采取某些行动。从我的角度来看，这正是我想要的：拥有同一服务的多个副本，其中只有一个副本读取和中继消息，因为它本身就是领导者。
做了一些谷歌搜索，结果出现在两个"出口"：
- Go Kubernetes客户端库的参考实现：https://github.com/kubernetes/client-go/blob/master/tools/leaderelection/leaderelection.go
- 一篇在Apache Camel中提到领导人选举的文章：https://developers.redhat.com/articles/2021/09/23/leader-election-kubernetes-using-apache-camel#running_camel_master_on_openshift
现在我的问题在这里。当搜索ApacheCamel实现的代码时，它看起来好像也在使用Kubernetes客户端库中实现的Kubernete锁。客户端库实现提到，尽管领导人选举并不保证只有一个大师。
Apache Camel如何保证这一点
KubernetsLeadershipController.java#L387是处理领导者选举的Camel类，它依赖于kubernetes乐观领导者的实现。在kubernetes的世界里，我想说，在与ACID事务相同的概念中，没有任何保证，但要以乐观的方式处理它。您可以在客户端微调一些参数以快速故障转移，例如：重试、抖动、截止日期。