15、分布式 Elixir：故障转移与节点连接实战

分布式 Elixir：故障转移与节点连接实战

1. 分布式 Elixir 概述

分布式 Elixir 提供了丰富的功能，包括内置函数用于构建分布式系统、实现具备负载均衡的分布式应用、使用 Tasks 进行短期计算以及开发命令行应用。接下来将重点探讨分布式与容错性的结合。

2. 容错性分布式应用基础

• 故障转移与接管 ：故障转移指运行应用的节点宕机后，在一定超时时间内，应用会自动在其他节点重启；接管则是当高优先级节点加入集群时，低优先级节点停止运行，应用在高优先级节点重启。
• Chucky 应用介绍 ：为了学习如何利用故障转移和接管机制使 OTP 应用具备容错性，我们将构建一个名为 Chucky 的分布式容错应用，它能提供关于武术家兼演员 Chuck Norris 的有趣“事实”。示例运行如下：

iex(1)> Chucky.fact
"Chuck Norris's keyboard doesn't have a Ctrl key because nothing controls 
Chuck Norris."
iex(2)> Chucky.fact
"All arrays Chuck Norris declares are of infinite size, because Chuck 
Norris knows no bounds."

3. 构建 Chucky 应用

3.1 实现服务器

首先，创建一个新的 Elixir 项目：

% mix new chucky

然后，创建 lib/server.ex 文件，代码如下：

defmodule Chucky.Server do
  use GenServer
  #######
  # API #
  #######
  def start_link do
    GenServer.start_link(__MODULE__, [], [name: {:global, __MODULE__}])
  end

  def fact do
    GenServer.call({:global, __MODULE__}, :fact)
  end
  #############
  # Callbacks #
  #############
  def init([]) do
    :random.seed(:os.timestamp)
    facts = "facts.txt"
             |> File.read!
             |> String.split("\n")
    {:ok, facts}
  end
  def handle_call(:fact, _from, facts) do
    random_fact = facts 
                  |> Enum.shuffle 
                  |> List.first
    {:reply, random_fact, facts}
  end
end

这里使用 {:global, __MODULE__} 全局注册 GenServer ，使得集群中的每个节点都有名称表的副本。调用和广播时也需要添加 :global 前缀。 init/1 回调函数读取 facts.txt 文件并初始化状态， handle_call/3 回调函数随机返回一条 Chuck Norris 的“事实”。

3.2 实现 Application 行为

创建 lib/chucky.ex 文件，代码如下：

defmodule Chucky do
  use Application
  require Logger
  def start(type, _args) do
    import Supervisor.Spec
    children = [
      worker(Chucky.Server, [])
    ]
    case type do
      :normal ->
        Logger.info("Application is started on #{node}")
      {:takeover, old_node} ->
        Logger.info("#{node} is taking over #{old_node}")
      {:failover, old_node} ->
        Logger.info("#{old_node} is failing over to #{node}")
    end
    opts = [strategy: :one_for_one, name: {:global, Chucky.Supervisor}]
    Supervisor.start_link(children, opts)
  end
  def fact do
    Chucky.Server.fact
  end
end

这是一个简单的 Supervisor，用于监督 Chucky.Server 。同样， Chucky.Supervisor 也进行了全局注册。 start/2 函数中的 type 参数在非分布式应用中通常为 :normal ，在故障转移和接管场景下会有不同的值。

3.3 Application 类型参数

start/2 函数的 type 参数在分布式应用中会有不同的值，主要有以下三种情况：
| 类型 | 说明 |
| ---- | ---- |
| :normal | 非分布式应用启动时的常见值 |
| {:takeover, node} | 高优先级节点接管低优先级节点时的值 |
| {:failover, node} | 节点故障转移时的值 |

4. 故障转移与接管配置步骤

• 步骤 1：确定机器的主机名 ：在 Mac 上可以使用以下命令获取主机名：

% hostname -s
manticore

• 步骤 2：为每个节点创建配置文件 ：在 config 目录下创建三个配置文件：
• a.config
• b.config
• c.config
• 步骤 3：填充配置文件
• config/a.config ：

[{kernel,
  [{distributed, [{chucky, 5000, [a@manticore, {b@manticore, 
c@manticore}]}]}, 
   {sync_nodes_mandatory, [b@manticore, c@manticore]},
   {sync_nodes_timeout, 30000}
  ]}].

• config/b.config ：

[{kernel,
  [{distributed, 
    [{chucky,
      5000,
      [a@manticore, {b@manticore, c@manticore}]}]},
   {sync_nodes_mandatory, [a@manticore, c@manticore]},
   {sync_nodes_timeout, 30000}
  ]}].

• config/c.config ：

[{kernel, 
  [{distributed, 
    [{chucky,
      5000,
      [a@manticore, {b@manticore, c@manticore}]}]},
   {sync_nodes_mandatory, [a@manticore, b@manticore]},
   {sync_nodes_timeout, 30000} 
  ]}].

配置文件中的参数说明如下：
- distributed ：指定应用名、超时时间和节点优先级。
- sync_nodes_mandatory ：必须在 sync_nodes_timeout 时间内启动的节点列表。
- sync_nodes_timeout ：等待其他节点启动的超时时间（毫秒）。
- 步骤 4：在所有节点上编译 Chucky ：在每个节点上运行以下命令：

% mix compile

• 步骤 5：启动分布式应用 ：打开三个不同的终端，分别运行以下命令：

# 节点 a
% iex --sname a -pa _build/dev/lib/chucky/ebin --app chucky --erl 
    ➥"-config config/a.config"
# 节点 b
% iex --sname b -pa _build/dev/lib/chucky/ebin --app chucky --erl 
   ➥"-config config/b.config"
# 节点 c
% iex --sname c -pa _build/dev/lib/chucky/ebin --app chucky --erl 
    ➥"-config config/c.config"

这些命令的参数说明如下：
| 参数 | 说明 |
| ---- | ---- |
| --sname <name> | 启动分布式节点并分配短名称 |
| -pa <path> | 将指定路径添加到 Erlang 代码路径 |
| --app <application> | 启动应用及其依赖 |
| --erl <switches> | 传递给 Erlang 的开关参数 |

5. 故障转移与接管实战

启动节点后，当所有节点都启动完成，在每个终端运行 Chucky.fact 可以看到应用的运行情况。最初，只有节点 a 运行 Chucky 应用。当终止节点 a 后，大约五秒后，节点 b 会自动启动 Chucky 应用。当节点 a 重新加入集群时，会接管节点 b 的运行。

6. 局域网节点连接、Cookie 与安全

• 节点通信的 Cookie 机制 ：为了使两个节点能够通信，它们需要共享一个 Cookie。在同一台机器上启动节点时，通常不需要担心 Cookie 问题，因为所有节点会使用主目录下的同一个 Cookie 文件。但在连接不同机器上的节点时，需要确保所有节点的 Cookie 相同。
• 确定机器的 IP 地址 ：在 Linux/Unix 系统上，可以使用 ifconfig 命令确定机器的 IP 地址。示例输出如下：

% ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
  options=3<RXCSUM,TXCSUM>
  inet6 ::1 prefixlen 128
  inet 127.0.0.1 netmask 0xff000000
  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
  nd6 options=1<PERFORMNUD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  ether 10:93:e9:05:19:da
  inet6 fe80::1293:e9ff:fe05:19da%en0 prefixlen 64 scopeid 0x4
  inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255
  nd6 options=1<PERFORMNUD>
  media: autoselect
  status: active

• 连接节点 ：在两台机器上分别启动节点：

# 第一台机器
% iex --name one@192.168.0.100
# 第二台机器
% iex --name two@192.168.0.103

尝试连接两个节点时，可能会失败，原因是缺少相同的 Cookie。
- 设置 Cookie ：为每个节点提供相同的 Cookie 值：

# 第一台机器
% iex --name one@192.168.0.100 --cookie monster
# 第二台机器
% iex --name two@192.168.0.103 --cookie monster

这样，两个节点就可以成功通信。

通过以上步骤，我们学习了如何构建一个分布式容错应用，并掌握了在局域网中连接节点的方法，同时了解了 Cookie 在节点通信中的重要性。

分布式 Elixir：故障转移与节点连接实战

7. 故障转移与接管的详细流程分析

为了更清晰地理解故障转移与接管的过程，我们可以通过 mermaid 流程图来展示：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(启动节点 a、b、c):::process
    B --> C{节点 a 运行正常?}:::decision
    C -->|是| D(所有请求由节点 a 处理):::process
    C -->|否| E(等待超时时间):::process
    E --> F(节点 b 检测到 a 故障):::process
    F --> G(节点 b 启动 Chucky 应用):::process
    G --> H{节点 a 重新加入集群?}:::decision
    H -->|是| I(节点 a 接管节点 b):::process
    H -->|否| J(节点 b 继续处理请求):::process

从这个流程图可以看出，整个故障转移与接管的过程是一个有序的状态转换过程。当主节点 a 正常运行时，它处理所有的请求；当 a 出现故障时，经过一定的超时时间，节点 b 会检测到并自动启动应用；如果 a 重新加入集群，它会接管节点 b 的工作。

8. 配置文件参数的深入理解

配置文件中的参数对于故障转移和接管的正常运行至关重要。下面我们详细分析每个参数的作用：
| 参数 | 作用 | 示例值 |
| ---- | ---- | ---- |
| distributed | 指定应用名、超时时间和节点优先级 | [{chucky, 5000, [a@manticore, {b@manticore, c@manticore}]}] |
| sync_nodes_mandatory | 必须在 sync_nodes_timeout 时间内启动的节点列表 | [b@manticore, c@manticore] |
| sync_nodes_timeout | 等待其他节点启动的超时时间（毫秒） | 30000 |

• distributed 参数 ：
• chucky 是应用的名称。
• 5000 表示超时时间，即当一个节点在 5000 毫秒内没有响应时，会被认为是故障节点，应用会在其他节点上重启。
• [a@manticore, {b@manticore, c@manticore}] 定义了节点的优先级。 a 节点优先级最高， b 和 c 节点优先级相同。
• sync_nodes_mandatory 参数 ：这个参数指定了必须在 sync_nodes_timeout 时间内启动的节点列表。如果这些节点中有一个未能在规定时间内启动，当前节点会终止自身。
• sync_nodes_timeout 参数 ：它决定了节点等待其他节点启动的最长时间。如果超过这个时间，节点会根据 sync_nodes_mandatory 和 sync_nodes_optional 的设置来决定是否继续运行。

9. 局域网节点连接的常见问题及解决方法

在连接局域网节点时，可能会遇到一些常见问题，下面我们列举并给出解决方法：
| 问题 | 现象 | 原因 | 解决方法 |
| ---- | ---- | ---- | ---- |
| 节点连接失败 | 使用 Node.connect 方法返回 false ，并出现错误报告 | 节点的 Cookie 不同 | 确保所有节点使用相同的 Cookie，可以通过 --cookie 标志指定，或者复制 .erlang.cookie 文件到所有节点的主目录 |
| 节点启动失败 | 启动节点时出现错误信息 | 配置文件参数错误、代码路径问题等 | 检查配置文件中的参数是否正确，确保 -pa 参数指定的路径指向正确的 BEAM 文件 |
| 应用未正常启动 | 运行 Chucky.fact 时没有返回预期结果 | 应用未正确编译或启动 | 在所有节点上重新编译应用，使用 --app 参数确保应用及其依赖正常启动 |

10. 安全与性能考虑

• 安全方面 ：虽然 Erlang 在设计分布式系统时对安全的考虑相对简单，但在实际应用中，我们需要重视节点通信的安全性。确保所有节点使用相同的 Cookie 是基本要求，但在生产环境中，还可以考虑使用更高级的安全机制，如加密通信、访问控制等。
• 性能方面 ：故障转移和接管的超时时间设置会影响系统的性能。如果超时时间过短，可能会导致误判，频繁进行故障转移；如果超时时间过长，当节点出现故障时，系统恢复的时间会变长。因此，需要根据实际情况合理调整超时时间。

11. 总结与实践建议

通过以上对分布式 Elixir 中故障转移、接管以及局域网节点连接的学习，我们可以总结出以下实践建议：
- 配置文件管理 ：确保每个节点的配置文件正确无误，特别是 distributed 、 sync_nodes_mandatory 和 sync_nodes_timeout 参数的设置。
- Cookie 管理 ：在连接不同机器上的节点时，务必保证所有节点使用相同的 Cookie，可以通过复制 .erlang.cookie 文件或使用 --cookie 标志来实现。
- 测试与监控 ：在部署应用之前，进行充分的测试，模拟节点故障和重新加入等情况，确保故障转移和接管功能正常。同时，建立监控系统，实时监测节点的状态和应用的运行情况。

通过遵循这些建议，我们可以构建出更加稳定、可靠的分布式 Elixir 应用，充分发挥其容错和分布式计算的优势。