一、背景
测试环境fastdfs就一个节点（tracker和storage在一个机器上），并且这个服务器cpu故障，随时可能重启，所以要迁移测试环境fastdfs到另一个台机器，或者添加storage节点实现高可用；需要先了解下fastdfs的基本架构和原理；
二、fastdfs体系结构
注释：如下所示的client并非fastdfs架构中的一个服务，java服务需要访问fastdfs,那么java服务那需要有fastdfs的client插件，此时java服务是client端。
FastDFS的体系结构主要由三个部分组成：客户端（Client）、跟踪服务器（Tracker Server）和存储服务器（Storage Server）
客户端（Client）
某个服务需要访问FastDFS分布式文件系统以进行文件的上传、下载或其他操作，那么需要在这个服务上安装FastDFS的Client；
客户端是用户或应用程序与FastDFS交互的接口。它负责将文件上传到FastDFS系统，并从系统中下载文件。客户端在访问存储服务器之前，必须先通过跟踪服务获取可用的存储服务器信息。
上传下载数据的服务器，即项目所部署的服务器。它提供基本的文件访问接口，如monitor、upload、download、append、delete等，通过客户端库供用户使用，简化分布式文件操作。Client对Tracker和Storage的调用均为服务器间的调用
跟踪服务（Tracker Server）
跟踪服务器在FastDFS中充当调度和负载均衡的角色。它维护集群内所有存储组及存储服务器的状态信息，负责管理所有存储服务器和组。跟踪服务器通过心跳机制与存储服务器通信，定期更新存储服务器的状态信息，并根据这些信息动态分配存储服务器的任务，确保负载均衡。
跟踪服务器在FastDFS中充当调度和负载均衡的角色。它在内存中维护集群内所有存储组及存储服务器的状态信息，作为客户端与存储服务器交互的核心枢纽。
主要职责：
1、协调管理：负责管理所有Storage Server和Group。
2、心跳机制：每个Storage Server启动后会连接Tracker，报告所属Group信息并定期发送心跳。Tracker依据心跳信息建立Group与Storage Server列表的映射。
3、动态分配：客户端在访问Storage Server前，需先联系Tracker获取可用的Storage Server信息，从而实现动态负载均衡。
4、高扩展性：Tracker仅管理少量元数据，全部存储于内存中，无需持久化数据。通过增加Tracker实例，可以轻松扩展为集群模式，提升系统的可扩展性与容错能力
存储服务（Storage Server）
存储服务器负责实际的文件存储和备份。文件被存储在多个存储服务器上，形成存储集群。每个存储服务器启动时会自动注册到跟踪服务器上，并定期报告自身状态信息。存储服务器之间通过文件同步机制保持数据的一致性，通常采用push方式同步文件内容；
Storage Server按照**组（Group）**进行组织，每个Group包含多台Storage Server，数据在组内实现互为备份。存储空间以Group内最小容量的Storage Server为基准，建议组内所有Storage配置相同，避免存储空间浪费。
组管理优势：
应用隔离：不同应用的数据存储于不同的Group，实现数据隔离。
负载均衡：根据应用访问特性，将不同应用分配至不同Group，实现负载均衡。
副本定制：Group内Storage Server数量即为数据副本数，可根据需求定制副本数量
三、存储原理
存储机制：多存储目录配置：Storage Server可配置多个数据存储目录，如配置10块磁盘分别挂载至/data/disk1至/data/disk10，并将这些目录配置为Storage的数据存储路径。
文件存储策略：接收到写文件请求后，Storage根据配置规则选择存储目录。为避免单目录文件过多，Storage启动时会在每个存储目录下创建两级子目录，每级256个，总计65536个子目录。新文件通过哈希方式路由至某个子目录，并作为本地文件存储，从而加快文件索引速度；
容量限制：Group容量受单台Storage Server存储容量限制；
数据同步机制：文件同步只能在 group 内的 storage server 间进行，采用 push 方式，即源服务器同步给目标服务器。源服务器读取 binlog 文件，将文件内容解析后，按操作命令发送给目标服务器，由目标服务按命令进行操作
FastDFS文件同步采用binlog异步复制方式，在storage server上有新文件操作时，把文件元数据信息写入binlog文件，用于同步新文件到其它storage，正常文件上传完成后，就记录进binlog缓存中，定时刷入binlog文件。 storage有线程定时读取binlog文件，当有新增行时，判断该记录是源文件记录还是副本文件记录。 只主动发送源文件，副本文件不做处理(非启动时流程)。
同步规则：
1、只在本组内的storage server之间进行同步；
2、源头数据才需要同步，备份数据不需要再次同步，否则就构成环路了，源数据和备份数据区分是用binlog的操作类型来区分，操作类型是大写字母，表示源数据，小写字母表示备份数据；
3、当先新增加一台storage server时，由tracker选择已有的一台storage server将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器。
四、高可用机制
1、Storage Server高可用：
依靠同组的多个Storage Server数据同步，同一个组的多个Storage Server数据保持一样，互为主备，这样当某个一个Storage Server死了，Tracker server会剔除该Storage Server信息，不再给他分配任务；
FastDFS中的Storage Server以group为单位，每个group内有多个storage server，数据互相备份。这样，即使某个storage server发生故障，其他storage server仍然可以提供文件访问服务，从而确保数据的高可用性；
每个group内的storage server会定期向Tracker Server发送心跳信息，以维持其在线状态。如果某个storage server长时间未发送心跳信息，Tracker Server会将其标记为不可用，并从group中移除；
当某个storage server发生故障时，FastDFS会自动将其从group中移除，并将该server上的文件访问请求转移到其他可用的storage server上。这种自动故障转移机制可以确保在storage server发生故障时，文件访问服务不会中断；
那同一个group中的不同storage server，都可以接收写文件的任务吗？
- 当客户端向FastDFS集群上传文件时，Tracker服务器会根据一定的策略（如轮询、指定group、选择可用空间最大的group等）来选择一个group。
- 一旦选定了group，Tracker会进一步根据一定的算法（如轮询、根据配置的IP顺序、根据配置的优先级等）在该group内选择一个storage节点作为文件上传的目标，也就是说同一个组中的两个group都可能接收写的操作，并作为源同步文件到另一个节点；具体选择那个storage由tracker配置参数：store_server参数决定！默认就是轮询！如下所示：
which storage server to upload file
0: round robin (default)
1: the first server order by ip address
2: the first server order by priority (the minimal)
store_server=0
2、Tracker server高可用：
在FastDFS系统中，Tracker节点主要起到调度和负载均衡的作用，它们之间是对等的关系，地位相等，没有主从之分。
具体来说，每个Tracker节点都会维护一个存储组和存储服务器的状态信息映射表，这个映射表是根据存储服务器（Storage server）的心跳信息动态生成的。当客户端需要上传或下载文件时，它会向其中一个Tracker节点发送请求，该Tracker节点会根据当前的负载情况和策略，为客户端分配一个合适的存储服务器；
Storage server在启动后，会主动连接集群中的所有Tracker节点，并告知它们自己的状态信息，如所在group、磁盘使用情况、文件同步情况等。这些信息对于Tracker节点来说至关重要，因为它们需要基于这些信息来维护存储组和存储服务器的状态信息映射表，以便为客户端提供合适的存储服务器；
1）Tracker server可以由多台服务器组成，形成集群。这样，即使某个Tracker server节点发生故障，其他节点仍然可以继续提供服务，确保系统的连续性；
2）在多节点部署的基础上，可以通过负载均衡策略将客户端的请求分散到不同的Tracker server节点上；
3）心跳监测：每个Tracker server节点都会定期向其他节点发送心跳信息，以维持其在线状态。如果某个节点长时间未发送心跳信息，其他节点会将其标记为不可用，并触发故障切换机制。
4）故障切换流程：当检测到某个Tracker server节点故障时，系统会自动将该节点的请求转移到其他可用的节点上。这通常涉及更新客户端的Tracker server列表，以确保它们能够连接到新的活动节点
5）当有多个
Tracker server时，客户端如何连接？（java服务需要连接fastdfs，那么这个java服务就有client.conf）
在客户端的配置文件（通常是client.conf）中，需要列出所有可用的Tracker节点的IP地址和端口号。例如：
tracker_server=tracker1_ip:22122,tracker2_ip:22122,tracker3_ip:22122
其中，tracker1_ip、tracker2_ip和tracker3_ip分别代表不同Tracker节点的IP地址，22122是Tracker服务的默认端口号。
FastDFS客户端在配置多个Tracker节点后，会采用负载均衡策略来访问这些节点。默认情况下，FastDFS采用轮询策略，即依次访问每个Tracker节点，以实现负载均衡。客户端也可以根据实际需求自定义负载均衡策略，以满足特定的应用场景
6）访问FastDFS
1.文件上传：
- 当客户端需要上传文件时，它会向其中一个Tracker节点发送请求，请求获取一个可用的Storage节点进行文件存储。
- Tracker节点会根据当前Storage节点的负载情况和文件上传策略，为客户端分配一个合适的Storage节点。
- 客户端接收到分配的Storage节点信息后，会直接与该Storage节点进行通信，完成文件上传操作。
2.文件下载：
- 当客户端需要下载文件时，它会向其中一个Tracker节点发送请求，请求获取存储该文件的Storage节点的信息。
- Tracker节点会根据文件的标识（卷名和文件名）查找存储该文件的Storage节点，并将该节点的信息返回给客户端。
- 客户端接收到Storage节点的信息后，会直接与该节点进行通信，完成文件下载操作。
- 当客户端需要上传文件时，它会向其中一个Tracker节点发送请求，请求获取一个可用的Storage节点进行文件存储。
- Tracker节点会根据当前Storage节点的负载情况和文件上传策略，为客户端分配一个合适的Storage节点。
- 客户端接收到分配的Storage节点信息后，会直接与该Storage节点进行通信，完成文件上传操作。
2.文件下载：
- 当客户端需要下载文件时，它会向其中一个Tracker节点发送请求，请求获取存储该文件的Storage节点的信息。
- Tracker节点会根据文件的标识（卷名和文件名）查找存储该文件的Storage节点，并将该节点的信息返回给客户端。
- 客户端接收到Storage节点的信息后，会直接与该节点进行通信，完成文件下载操作。
7）容错机制
如果客户端在访问某个Tracker节点时遇到故障（如网络问题、Tracker节点宕机等），它会尝试访问其他配置的Tracker节点，以确保服务的连续性。
在FastDFS分布式文件系统中，Tracker节点之间 并不需要直接进行通信来交换数据或状态信息。每个Tracker节点都是独立运行的，它们各自维护一个存储组和存储服务器的状态信息映射表。这个映射表是基于存储服务器的心跳信息动态生成的，并且每个Tracker节点都会独立地处理客户端的请求。
