erlang 怎么样将取出文件名前都加上路径

Path="C:/pro/",

Func = fun(Path, FN) ->Path ++ FN end,

FileNames = [Func(Path, F) || F <-LocalList],

大概就这个结构咯，没测试过的代码。

Application.StartupPath 应用程序启动目录

System.IO.Directory.SetCurrentDirectory 设置当前工作路径

System.IO.Directory.GetCurrentDirectory 获取当前工作路径

如果有一个消息生产者或者消息消费者通过amqp-client的客户端连接至节点1进行消息的发布或者订阅，那么此时的集群中的消息收发只与节点1相关。

如果消息生产者所连接的是节点2或者节点3，此时队列1的完整数据不在该两个节点上，那么在发送消息过程中这两个节点主要起了一个路由转发作用，根据这两个节点上的元数据转发至节点1上，最终发送的消息还是会存储至节点1的队列1上。

RabbitMQ 集群是一个或多个节点的逻辑分组，每个节点共享用户、虚拟主机、队列、交换器、绑定、运行时参数和其他分布式状态。

一些分布式系统 有leader和follower节点。 对于 RabbitMQ 来说， RabbitMQ集群中的所有节点都是平等的。

RabbitMQ 集群可以通过多种方式组成：

RabbitMQ 节点绑定到端口以接受客户端和 CLI 工具连接。其他进程和工具（例如 SELinux）可能会阻止 RabbitMQ 绑定到端口。发生这种情况时，节点将无法启动。

CLI工具、客户端库和 RabbitMQ 节点也会打开连接（客户端 TCP 套接字）。防火墙会阻止节点和 CLI 工具相互通信。确保可以访问以下端口：

RabbitMQ节点和 CLI 工具（例如 rabbitmqctl）使用 cookie 来确定它们是否被允许相互通信。为了让两个节点能够通信，它们必须具有相同的共享密钥，称为 Erlang cookie。cookie 只是一串最多 255 个字符的字母数字字符。 它通常存储在本地文件中。该文件必须只能由所有者访问（例如具有 600 或类似的 UNIX 权限）。每个集群节点必须具有相同的 cookie。

在 UNIX 系统上，cookie通常是位于/var/lib/rabbitmq/.erlang.cookie（由服务器使用）和$HOME/.erlang.cookie（由 CLI 工具使用）。

RabbitMQ 节点使用主机名相互寻址

<!== 所有主机执行 ==>

<!== 所有主机执行 ==>

<!== 所有主机执行 ==>

默认配置文件/usr/lib/rabbitmq/lib/rabbitmq_server-3.7.17/ebin/rabbit.app

<!== node01主机执行 ==>

<!== node02主机执行 ==>

<!== node03主机执行 ==>

<!== 所有主机执行 ==>

因RabbitMQ 集群元数据同步基于 cookie 共享方案实现

文件路径/var/lib/rabbitmq/.erlang.cookie

<!== node02、node03主机执行 ==>

<!== 任意主机执行 ==>

节点分为：磁盘节点及内存节点

RAM节点是一种特殊情况，可用于提高具有高队列、交换或绑定搅动的集群的性能。RAM节点不提供更高的消息速率。 官方建议在绝大多数情况下，仅使用磁盘节点。

如果一个集群中都是RAM节点，那么集群停止，将无法再次启动，并将丢失所有数据

官方提示：经典队列镜像将在未来版本中删除，考虑改用仲裁队列或非复制经典队列

每个镜像队列由一个领导副本和一个或多个镜像副本，leader被托管的节点成为leader节点。首先应用给定队列的所有 *** 作 在队列的leader节点上，然后传播到镜像。

如果承载队列的leader节点出现故障，则只要已同步，最旧的镜像将升级为新的leader。根据队列镜像参数，也可以升级未同步的镜像。

队列通过策略启用了镜像，策略模式的说明如下：

每当队列的策略发生变化时，它都保持其现有的镜像尽可能适用新策略。

设置的镜像队列可以通过开启的网页的管理端Admin->Policies，也可以通过命令。

管理端界面：

命令行：

为避免集群中的某个节点托管大多数leader队列，因此导致高负载，leader队列应合理均匀的分布在集群节点上。控制leader队列分布节点策略有三种，可以在rabbitmq.conf文件中定义queue_master_locator参数设置

修改节点策略可能会导致现有的leader队列没有在新的策略中，为了防止消息丢失，RabbitMQ会保留现有的leader直到至少另一个镜像已同步，一旦发生同步，消费者将与leader断开连接，需要重新连接。

如果leader故障，其他镜像升级为leader过程如下：

如果消费者使用 自动确认模式 ，那么消息可能会丢失。这与非镜像队列没有什么不同：代理认为消息一旦以自动确认模式发送给消费者，就会被确认。

如果客户端突然断开连接，则可能永远不会收到消息。在镜像队列的情况下，如果leader死亡，那些正在以 自动确认模式 发送给消费者的消息可能永远不会被这些客户端接收，并且不会被新leader重新排队。由于消费客户端连接到存活节点的可能性，消费者取消通知有助于识别此类事件何时发生。 当然，在实践中，如果数据安全性不如吞吐量重要，那么自动确认模式是可行的方法。

节点可以随时加入集群。 根据队列的配置，当节点加入集群时，队列可能会在新节点上添加镜像。 此时，新镜像将是空的：它不会包含队列中任何现有的内容。 这样的镜像将接收发布到队列的新消息，因此随着时间的推移将准确地表示镜像队列的尾部。 随着消息从镜像队列中排出，新镜像丢失消息的队列头部的大小将缩小，直到最终镜像的内容与leader的内容完全匹配。 在这一点上，镜像可以被认为是完全同步的。

新添加的镜像不提供添加镜像之前存在的队列内容的额外形式的冗余或可用性，除非队列已明确同步。 由于在发生明确同步时队列变得无响应，因此最好允许正在从中排出消息的活动队列自然同步，并且仅明确同步非活动队列。

启用自动队列镜像时，请考虑所涉及队列的预期磁盘数据集 。 具有庞大数据集（例如，数十 GB 或更多）的队列必须将其复制到新添加的镜像中，这会给集群资源（例如网络带宽和磁盘 I/O）带来很大的负载。

要查看镜像状态（是否同步）：

手动同步队列：

取消正在进行的同步：

如果你停止一个包含镜像队列leader的 RabbitMQ 节点，其他节点上的一些镜像将被提升为leader。 如果继续停止节点，那么将到达一个镜像队列不再有镜像的点：它仅存在于一个节点上，且该节点上它是leader。 如果它的最后一个剩余节点关闭，但是镜像队列被声明为持久的，那么队列中的持久消息将在该节点重新启动后继续存在。

然而，镜像目前无法知道它的队列内容是否已经偏离了它重新加入的leader。 因此，当一个镜像重新加入一个镜像队列时， 它会丢弃已经拥有的任何持久本地内容并开始为空 。

默认情况下，RabbitMQ 将拒绝leader节点在受控关闭（即明确停止 RabbitMQ 服务或关闭 *** 作系统）时提升非同步镜像，以避免消息丢失； 相反，整个队列将关闭，就好像未同步的镜像不存在一样。

leader节点不受控制的关闭（即服务器或节点崩溃，或网络中断）仍将触发未同步镜像的提升。

如果您希望在所有情况下都让leader队列移动到未同步的镜像（即，您会选择队列的可用性而不是避免由于未同步的镜像升级而导致的消息丢失），那么将 ha-promote-on-shutdown 策略键设置为 always 而不是比它的默认值 when-synced 。

如果 ha-promote-on-failure 策略键设置为 when-synced ，则即使 ha-promote-on-shutdown 键设置为 always ，也不会提升未同步的镜像。 这意味着如果leader节点发生故障，队列将变得不可用，直到leader恢复。 如果leader队列永久丢失，队列将不可用，除非它被删除（这也将删除其所有内容）并重新声明。

当队列的所有镜像都关闭时，可能会丢失队列的leader。 在正常 *** 作中，队列关闭的最后一个节点将成为leader，该节点在再次启动时仍然是leader（因为它可能收到了其他镜像没有看到的消息）。

但是，当您调用 rabbitmqctl forget_cluster_node 时，RabbitMQ 将尝试为每个在我们忘记的节点上有其领导者的队列找到当前停止的镜像，并在它再次启动时“提升”该镜像成为新的领导者。 如果有多个候选者，将选择最近停止的镜像。

重要的是要理解 RabbitMQ 只能在 forget_cluster_node 期间提升停止的镜像，因为任何再次启动的镜像都会清除它们的内容，如上面“停止节点和同步”中所述。 因此在停止的集群中移除丢失的leader时，您必须在再次启动镜像之前调用 rabbitmqctl forget_cluster_node 。

---