本文翻译自《Distributed Locks with Apache Pulsar》。
原文链接：https://theboreddev.com/distr…

译者简介
魏伟 kivenwei，7 年研发工作经验，次要经验了 SOA、微服务架构。相熟云计算畛域的开源软件倒退和 CNCF、云原生生态，目前就任于中广核智能科技有限责任公司。

有时，软件工程师常常面临最具挑战性的工作就是如何确保咱们的分布式应用程序中每次只有一个组件在执行相应的计算。

例如，应用程序中三个运行节点，并且咱们须要每天运行一个打算工作，如何保障仅其中一个节点能够触发运行工作呢？如果咱们在此工作中向客户发送电子邮件并在三个节点上运行工作，则咱们的客户可能会收到 3 次此电子邮件。大失所望，那么如何解决此问题呢？

有人可能会说：“简略，只运行一个节点！”。

其实，没那么容易。在大多数状况下，咱们必须确保服务具备足够的可用性级别，而仅运行一个节点意味着如果呈现问题，服务将不可用。

咱们真正须要的计划是抉择某个“主节点”来负责此工作。另一个须要思考的因素是如果咱们的主节点呈现故障，则必须立刻将此工作委托给其中一个备用节点执行工作以防止中断。

让咱们来看看，咱们想要实现的成果。如下图：

在操作上，须要找出一种简略的办法来“选举”负责执行工作的主节点，其它节点将急躁期待轮到它执行的状况。因而这些备用节点将处于所谓的“休眠”状态；只有在主节点故障或无响应时，备用节点才会被唤醒。

如何解决这个问题

在一些场景中，会偏向于用一些相当简单的实现去确保只有其中一个节点执行工作。

当初一些数据库引擎反对的“CAS”原子操作，可能是疾速解决这个问题的正当办法。咱们利用数据库中一项个性即可解决问题，而无需本人从新实现。然而如果数据库不反对这样的原子操作呢？

问题会变得更简单，因为每个节点都会尝试竞争以取得锁，然而两个节点能够同时取得锁的值为“free”且都胜利设置了值，而不会留神到另一个节点也“取得锁”。这意味着不仅有一个节点，而是两个节点都将执行此工作，例如向客户发送电子邮件，

然而，即便在数据库中反对 CAS 操作，也须要提供一些机制来确保如果咱们的主节点故障后备用节点来接管：一个相似于心跳的过程，一直查看状态并在节点呈现故障时采取相应措施。然而，这种计划较为耗时耗精力，现实状况下，咱们心愿利用欠缺的并通过全面测试的产品。

如果你曾经部署了 Pulsar，那么这正是咱们应用 Apache Pulsar 这类产品来解决这一问题的起因。Kafka 也能够实现相似的解决方案，但这篇文章次要聚焦于 Apache Pulsar。

应用 Apache Pulsar 实现分布式锁

那么如何去利用 Apache Pulsar 的劣势呢？Pulsar 提供了一种叫做 failover（灾备）的订阅机制，它次要实现了一个 leader 选举机制。

如何充分利用这种选举机制来保障打算工作只执行一次呢？

无需深刻理解实现的具体细节，因为这在很大水平上取决于应用场景，能够想出一个简略的办法来实现这一点。具体如下：

基于心跳事件的主动启动调度器

一个实现办法是启动一个消费者并开始监听心跳事件，而后立刻开始发送心跳事件。消费者将应用 failover（灾备）订阅来订阅主题。因而，只有一个节点可能启动调度程序。如果主节点故障，那么其余备用节点将接管并立刻启动工作。下图是实现的思路：

在这个例子中，咱们有一个主题来治理分布式锁，每个消费者定期向这个主题发送心跳，同时应用 failover（灾备）订阅主题。只有其中一个节点会成为主节点并解决心跳事件。如果主节点还没有启动邮件调度器，它会在收到第一个心跳后立刻启动；对于其余的心跳，只有调度程序在运行，它们就会被疏忽。

如果主节点故障后将会产生什么？具体看下图：

在主节点故障的状况下，Pulsar 的灾备（failover）订阅会检测到该节点曾经故障，备用节点将接管。在图中，左侧的备用节点将收到心跳，触发工作执行的开始。一旦以前的主节点复原，它将作为备用节点再次“休眠”。

论断

咱们个别不倡议只为了实现分布式锁就采纳任何新技术，通常寻找并利用以后产品的劣势能够节省时间、升高操作的复杂性。

当然，用户也能够在其余零碎上构建本人的分布式锁，但这须要工夫，而且也容易出错。然而在 Pulsar 的实现过程中，该个性通过其余工程师的彻底测试后可用且牢靠，可为用户节俭贵重的工夫，缩小操作上的问题。

关注 公众号「Apache Pulsar」，获取干货与动静

退出 Apache Pulsar 中文交换群 👇🏻