哨兵模式搭建图片服务器

A. redis sentinel 哨兵模式

Redis 集群可以在一组 redis 节点之间实现高可用性和 sharding。在集群中会有 1 个 master 和多个 slave 节点。当 master 节点失效时，应选举出一个 slave 节点作为新的 master。然而 Redis 本身(包括它的很多客户端)没有实现自动故障发现并进行主备切换的能力，需要外部的监控方案来实现自动故障恢复。

Redis Sentinel 是官方推荐的高可用性解决方案。它是 Redis 集群的监控管理工具，可以提供节点监控、通知、自动故障恢复和客户端配置发现服务。

搭建一主两从环境，docker-compose.yml 配置如下：

我们至少需要创建三个 Sentinel 服务，docker-compose.yml 配置如下：

需要三份 sentinel.conf 配置文件，分别为 sentinel1.conf，sentinel2.conf，sentinel3.conf，配置文件内容相同

进入 Sentinel 容器，使用 Sentinel API 查看监控情况：

B. Redis 学习总结(3) Redis 哨兵模式

在实际开发中不会仅仅部署一个 Redis 服务器，为了获得高可用，Redis 哨兵模式 则是高可用的一种选择。

本文先介绍下 哨兵模式，再介绍了如何在 springboot 项目中使用。

这意味着使用 Sentinel （哨兵模式），您可以创建一个 Redis 部署，它可抵抗某些类型的故障（进行故障迁移）而无需人工干预。

它有这些功能：

Sentinel 的分布式特性
Redis Sentinel 是一个分布式系统，多个 Sentinel 进程协同工作，有这些优势：

部署前需要了解:

三个节点的基本配置

法定人数和仲裁
在配置 哨兵模式时，要指定一个 quorum，它可理解为“法定人数”。
假设有3 个 哨兵，法定人数为2。那么：

哨兵和副本的自动发现
Sentinel 与其他 Sentinel 保持连接，以便相互检查彼此的可用性并交换消息。

但是，您不需要在您运行的每个 Sentinel 实例中配置其他 Sentinel 地址的列表，因为 Sentinel 使用 Redis 实例的 Pub/Sub 功能来发现正在监视相同主节点和副本的其他 Sentinel。

类似地，您不需要配置附加到主服务器的副本地址在哪里，因为 Sentinel 会通过查询 Redis 自动发现它们。

参考我的另一篇文章：

一般需要三个节点，每个节点有一个 redis 和一个哨兵。

下面再分别描述。

我这里按三个 节点，先配置 redis 的主从复制。1个节点作为 master ，2个副本。

配置节点1：master
这里的 redis 作为 master 主redis，其他两个节点作为从节点。
我的文件夹名字叫 box1，这里编辑一个 box1/redis.conf 文件，主要配置内容如下:

配置节点2：副本
编辑一个 box2/redis.conf 文件，主要配置内容如下:

配置节点3：副本
编辑一个 box3/redis.conf 文件，主要配置内容如下:

分别启动这三个redis
命令行执行 redis-server ，并指定 配置文件的路径参数。

如何查看“主从复制”是否配置成功？
使用 info replication 命令，操作如下：

副本节点设置为只读？
从 Redis 2.6 开始，副本已被默认设置为 只读，无需额外配置。.

一般情况下，至少会需要三个哨兵对redis 进行监控，我们可以通过修改端口启动多个sentinel 服务。

第一个哨兵：
哨兵的 默认端口是 26379 ，这里不改。

第二个哨兵：
修改哨兵端口。

第三个哨兵：
修改哨兵端口。

启动哨兵
使用 redis-sentinel 命令，分别启动这三个哨兵

哨兵的自动发现
当三个哨兵都启动后，在各个哨兵的打印日志里可以看到， 三个哨兵已互相发现了彼此的存在 。

至此，配置完毕了，我们有三个 redis，和三个哨兵，看下截图。

模拟 master 宕机
按 ctrl+c 停止 master ，其位于 6379 。停止后，从日志可以看到，哨兵和 redis副本先努力继续连接 6379，反复几次失败后，开始选举出新的 master。截图如下：

至此，配置完毕。

我们看下 springboot 项目的客户端如何配置 以访问 哨兵模式的 redis。

Redis 哨兵支持
对于处理高可用Redis，Spring Data Redis 已经支持Redis Sentinel，使用RedisSentinelConfiguration，如下例所示：

Jedis 和 Lettuce 两种 redis 驱动都可以支持。

RedisSentinelConfiguration 也可以用可以 通过 PropertySource 来设置，它允许您设置以下属性：

配置application.yml

比如我这里修改我的 application.yml 文件如下：

我的配置文件示例： https://github.com/vir56k/java_demo/tree/master/redis-sentinel
我的 springboot 配置实例： https://github.com/vir56k/java_demo/tree/master/redis-sentinel/springboot_redis_demo

Redis官网 sentinel 介绍
https://redis.io/topics/sentinel

spring-data/data-redis
https://docs.spring.io/spring-data/data-redis/docs/current/reference/html/#redis:sentinel

https://www.cnblogs.com/jaycekon/p/6237562.html

END

C. Redis哨兵（Sentinel）模式

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。 这不是一种推荐的方式，更多时候，我们优先考虑 哨兵模式 。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是 哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下 故障切换（failover） 的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线 。这样对于客户端而言，一切都是透明的。

配置3个哨兵和1主2从的Redis服务器来演示这个过程。

首先配置Redis的主从服务器，修改redis.conf文件如下

上述内容主要是配置Redis服务器，从服务器比主服务器多一个slaveof的配置和密码。

配置3个哨兵，每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件，一份进行修改

上述关闭了保护模式，便于测试。

有了上述的修改，我们可以进入Redis的安装目录的src目录，通过下面的命令启动服务器和哨兵

注意启动的顺序。 首先是主机（192.168.11.128）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。

上面是通过Jedis进行使用的，同样也可以使用Spring进行配置RedisTemplate使用。

sentinel down-after-milliseconds配置项只是一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主机不可用。对于其他哨兵而言，并不是这样认为。哨兵会记录这个消息，当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover，此时哨兵会重写Redis的哨兵配置文件，以适应新场景的需要。

D. Redis详解九（哨兵模式）

配置3个哨兵和1主2从的Redis服务器来演示这个过程。

多哨兵监控Redis

首先配置Redis的主从服务器，修改redis.conf文件如下

上述内容主要是配置Redis服务器，从服务器比主服务器多一个slaveof的配置和密码。

配置3个哨兵，每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件，一份进行修改。

上述关闭了保护模式，便于测试。

有了上述的修改，我们可以进入Redis的安装目录的src目录，通过下面的命令启动服务器和哨兵

注意启动的顺序。 首先是主机（192.168.11.128）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。

如果主机宕机后，启用新的主机，原来的主机回归后，会作为从机。

从单个实例配置到哨兵：

E. linux下安装配置redis详细教程，并配置哨兵模式

redis版本为redis-3.2.12，使用工具将安装包上传到data目录。

在data目录下创建文件夹redis，将redis安装在此目录。

第一步：解压。

第二步：安装，PREFIX=/data/redis用来设置安装目录。

到此，redis已经安装完成，剩下就是配置和启动服务。

进入redis目录， 创建配置文件conf、日志logs、数据库mp、进程号pid四个目录，用来存放对应的文件，这四个目录也可以存放在其他文件夹，只要与配置文件中的配置一致即可，否则在启动服务时会报错。 其中bin目录就是redis安装成功后的一些命令文件。

redis服务配置一主二从，哨兵模式。注意：如果在实际开发中用不到哨兵模式，redis服务配置一主一从即可。

主Redis配置：redis_6379.conf

从Redis配置，redis_6380.conf和redis_6381.conf，与主Redis配置基本上一样，不一样的地方在于 端口、数据库、日志、pid文件名称 ，都以6380或6381为标志， 最重要的地方是建立主从关系和同步验证。

注意： 对只使用redis服务 ，只需要在主Redis里面配置requirepass，在从Redis里面配置masterauth，密码保持一致，密码尽可能复杂，以免被攻击破解。

注意： 对只使用redis服务 ，如果从Redis也有必要加入访问验证，也可以设置requirepass，而且密码可以与主Redis密码不同。

将配置文件放置到/data/redis/conf目录下，然后就可以启动服务了。

启动服务要按照主从顺序依次启动。

查看服务启动情况：

也可以通过查看日志文件来确认服务是否正常启动。

通过客户端登录Redis验证数据同步情况：

主Redis登录验证，设置数据：

从Redis登录，获取数据：从Redis并没有设置密码，所以无需验证就可以操作。

配置哨兵模式：

Redis Sentinel集群通常由3到5个节点组成，如果个别节点挂了，集群还可以正常运作。Sentinel负责监控Redis集群的 健康 情况。

如果主Redis挂掉，Sentinel集群会通过投票选择一个新的主Redis。 当原来的主Redis恢复时，它会被当做新的主Redis的从Redis重新加入Redis集群。

设置连接master和slave的密码，需要注意的是sentinel不能分别为master和slave设置不同的密码，因此master和slave的密码必须设置相同。也就是说主Redis和从Redis都必须设置requirepass和masterauth，而且密码必须相同。

sentinel.conf配置信息：

将该配置文件放置到/data/redis/conf目录下，启动sentinel服务：

验证sentinel是否起作用，可以手工shutdown掉主Redis。

这时从Redis想要访问主Redis同步数据就会提示错误信息：

sentinel在监测到主Redis宕机之后，通过选举，将一个从Redis选定为新的主Redis。通过查看sentinel日志可以发现，选定6380为新的主Redis，同时将另外两个Redis作为从Redis。

注意：选定6380为主Redis后，所有的配置文件都会被修改，主要是重新建立主从关系。

6379会新增：slaveof 127.0.0.1 6380

6380会删掉：slaveof 127.0.0.1 6379

6381会修改：slaveof 127.0.0.1 6380

由于6379服务已经关掉，所以虽然sentinel将6379作为6380的从服务，但是没有真正的建立。

重新启动6379服务，这时sentinel会重建建立一次主从关系：

F. SpringBoot连接redis哨兵模式

设置 sentinel-26377.conf 的 protected-mode no ；默认是该字段值是yes

修改问题[1]中为redis集群master节点的真实地址；
修改问题[2]中为 bind 0.0.0.0

【注】redisTemplate实际上是对其他框架的的封装，springboot2.x以上底层实现由jedis变为了lettuce。而且lettuce会根据配置自动选择是否用单机或者哨兵模式。

【1】 Redis 哨兵模式 设置密码
【2】 sentinel搭建redis集群经验总结
【3】SpringBoot2.x使用Lettuce连接redis哨兵报错：RedisConnectionException: Unable to connect to 127.0.0.1:16379]： https://blog.csdn.net/repAgell/article/details/106600960
【4】解决使用jedis连接是报DENIED Redis is running in protected mode错误： https://www.cnblogs.com/lonecloud/p/9084761.html

G. docker-compose搭建Redis哨兵模式

环境：Ubuntu 20.04 64版/Centos7

docker版本：20.10.16

docker-compose版本：1.25.1

redis镜像版本：docker.io/redis:6.2.5-alpine

Docker从1.13.x开始分为社区版CE和企业版EE，版本号也改为按照时间线来发布，比如17.03就是2017年3月。

Docker的linux发行版的软件仓库目前为https://download.docker.com, 软件包名字改为docker-ce和docker-ee。

Docker的社区版（Docker Community Edition）叫做docker-ce。老版本的Docker包叫做docker或者docker-engine,docker官网推荐的安装方式都是下载docker安装脚本安装。

卸载旧版docker （若未安装过可省略此步）：

sudo apt-get remove docker docker.io docker-engine

安装最新版本docker： curl -sSL https://get.docker.com/ | sh

或者

curl -fsSL get.docker.com -o get-docker.sh

sudo sh get-docker.sh

确认Docker安装成功，拉取一个单机版本redis的docker：

docker run -d -p 6379:6379 -v ~/redisdata:/data redis:6.2.5 redis-server --appendonly yes

安装软件包

yum install -y yum-utils device-mapper-persistent-data lvm2

设置yum源

yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

查看有哪些版本可以装（知道要安装的版本号可直接跳过）

yum list docker-ce --showplicates | sort -r

安装docker，注意需要输入完整的版本号

yum install docker-ce-20.10.9-3.el8

安装完成后，将docker加入开机自启动

systemctl start docker

systemctl enable docker

检查是否安装成功

docker version

cloud下载最新版的docker-compose文件

sudo curl -L https://get.cloud.io/docker/compose/releases/download/1.25.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/ docker-compose

从github上下载docker-compose二进制文件安装

github.com下载最新版的docker-compose文件

sudo curl -L https://github.com/docker/compose/releases/download/1.16.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

添加可执行权限

sudo chmod +x /usr/local/bin/docker-compose

测试安装结果

docker-compose --version

2.pip安装

sudo pip install docker-compose

建立文件目录: mkdir -p /redisMasterSlave

创建文件 docker-compose.yml

启动命令：docker-compose -f docker-compose.yml -p redisMima1 up -d

查看实例中的redis角色的命令

docker exec redis_master redis-cli -a redisMima1 info replication

不用进到容器里看,直接在shell下执行即可, 其中redis_master为容器名, -a指定redis密码

哨兵模式是基于主从的, 建立文件目录如下

只需要准备三件事

docker-compose.yml配置与主从模式一样,可直接拷贝

redis_sentinel.yml配置如下

注意networks配是主从模式的网络, 查看主从的任意一台实例可知网络, 查看命令

结果如下 ip为 172.19.0.4

以下的是sentinel1#下的sentinel.conf

sentinel2#与sentinel3#下的配置文件的port分别改为26380, 26381, 其它一样

注意其中的172.19.0.2是master的docker网络的ip

启动命令

完成后查看容器运行情况 docker ps

启动主从docker-compose: ./run_REDIS up1

启动哨兵docker-compose: ./run_REDIS up2

启动主从容器: ./run_REDIS start1

启动哨兵容器: ./run_REDIS start2

停止主从与哨兵所有容器: ./run_REDIS stop

停止主从容器: ./run_REDIS stop1

停止哨兵容器: ./run_REDIS stop2

清除主从与哨兵所有容器: ./run_REDIS clear

清除主从所有容器: ./run_REDIS clear1

清除哨兵所有容器: .run_REDIS clear2

现在可以很方便地试错了~

H. Redis中的哨兵模式

哨兵模式是一种自动选择老大的模式，即在老大宕机之后，哨兵模式会根据哨兵们的内部投票，自动的重新选出一个新的老大。哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，如果Redis服务器一直没有响应，说明这个Redis服务器可能已经宕机了，从而监控运行的多个Redis实例。

这里的哨兵有两个作用
1、通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
2、当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下故障切换(failover)的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。如果有三个哨兵，不仅每个哨兵会监视主机和从机，而且哨兵之间也会互相监视，如下图：

配置哨兵配置文件sentinel.conf，如下

当哨兵模式的配置文件配置好之后，就可以启动哨兵模式了，如下图

测试在哨兵模式下如果主机崩了的话会不会从从机中自动选出一个老大，先关闭主机，让主机宕机，如下图：

看看主机宕机之后，哨兵模式中输出日志的新的内容是什么，如下图：

哨兵模式自动选举一个主机这个过程是怎样实现自动化的？哨兵自动选举之前的某个从机为老大，所有的从机都会称新选出的从机为老大，以及原本的老大也会称新选出的老大为老大，这个过程是怎么自动化实现的呢？是通过在对应的redis服务器的配置文件中写内容来实现的，比方说，让我们看一下新老大也即是端口号是6381的redis服务器的配置文件中是怎样改写的，如下图：

再来看一下从机即端口号是6380的redis服务器对应的配置文件是怎样改写的，如下图：

最后看一下原本的主机即端口号是6379的redis服务器的配置文件是怎样改写的。我检查了一下，发现在重新启动原本的老大即重启已经宕机的端口号是6379的redis服务器之前，它对应的配置文件中没有发生任何改变，但是一旦重新启动原本的老大，它对应的配置文件就会发生变化，如下图：

哨兵模式中的主机关闭之后需要特别注意的一个易错点：就是因为现在老大已经换了，所以老大的认证密码也换了，因此需要在现任老大的所有从机里面配置主机的认证密码，这个哨兵模式是不会帮我们自动配置的，需要我们自动配置，如下图：

测试哨兵模式结果，如下图：

1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有。

2、主从可以切换，故障可以转移，系统的可用性就会更好。

3、哨兵模式就是主从模式的升级，手动到自动，更加健壮。

1、集群容量一旦到达上限，在线扩容十分麻烦。

2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择。

当Redis集群的主节点故障时，Sentinel集群将从剩余的从节点中选举一个新的主节点，有以下步骤：

Sentinel集群的每一个Sentinel节点会定时对Redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该Redis节点被该Sentinel节点主观下线。

当节点被一个Sentinel节点记为主观下线时，并不意味着该节点肯定故障了，还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。

该Sentinel节点会询问其他Sentinel节点，如果Sentinel集群中超过quorum数量的Sentinel节点认为该Redis节点主观下线，则该redis客观下线。

如果客观下线的redis节点是从节点或者是Sentinel节点，则操作到此为止，没有后续的操作了；如果客观下线的Redis节点为主节点，则开始故障转移，从从节点中选举一个节点升级为主节点。

如果需要从redis集群选举一个节点为主节点，首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。

每一个Sentinel节点都可以成为Leader，当一个Sentinel节点确认redis集群的主节点主观下线后，会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求，则同意该请求(选举票数+1)，否则不同意。

如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum和Sentinel节点数/2+1的最大值)，则该Sentinel节点选举为Leader；否则重新进行选举。

当Sentinel集群选举出Sentinel Leader后，由Sentinel Leader从redis从节点中选择一个redis节点作为主节点：

详解redis集群选举机制

I. 使用seaweedfs搭建一个图片服务器 (上)

https://github.com/chrislusf/seaweedfs/releases

经典论文翻译导读之《Finding a needle in Haystack: Facebook’s photo storage》
http://www.importnew.com/3292.html

下面一张图总结下相互关系：

weed master 创建的是一个master服务器。
参数：
-defaultReplication string 备份策略（详细见 https://github.com/chrislusf/seaweedfs/wiki/Replication ）
-ip string
-mdir string 选项用于配置保存生成的序列文件id的文件夹
-port int (default 9333)
-volumeSizeLimitMB uint 自定义不能大于30000(default 30000)
-whiteList string 白名单，ip地址用逗号隔开

master服务器可以创建多个来实现故障转移主服务器，详细见 https://github.com/chrislusf/seaweedfs/wiki/Failover-Master-Server

参数：
-dir string 数据保存的路径，如果master的mdir没有指定会使用这个，如果filer的dir没有指定会新增并使用该目录下的filer目录
-ip string
-mserver string (default "localhost:9333")
-port
-dataCenter string
-rack string
-whiteList string

weed volume会创建一个 datanode ，可以指定所属的 datacenter rack和master ，会根据配置存储文件，默认一开始没有volume，当开始存储文件的时候才会创建一个volume，当这一个volume大小超过了volumeSizeLimitMB 就会新增一个volume，当volume个数超过了max则该datanode就不能新增数据了。那就需要在通过weed volume命令新增一个datanode。

weed filer
参数
-collection string 所有数据将存储在此集合中
-dataCenter string 更倾向于在这个数据中心写入卷
-dirListLimit int limit sub dir listing size (default 100000)
-ip string
-master string
-port int(default 8888)

更详细的说明请见： https://mp.csdn.net/mdeditor/85049078#
或者访问官网wiki ： https://github.com/chrislusf/seaweedfs/wiki

出现如下提示说明启动成功

执行下面的命令：

出现DataCenters是null的原因是没有执行weed volume创建DataCenter。

" 这里说一下抽象概念"：
我们抽象的认为我们的图片服务器，一个master需要两个datacenter叫imgdatacenter1，imgdatacenter2；imgdatacenter1需要两个rack叫imgrack1,imgrack2；然后imgrack1需要两个datanode1，datanode2；

创建datanode时 ，统一设置每个datanode包含10个volume即可。当datanode里面的volume满了以后再创建 新的datanode即可，方便扩展，并且不同datanode可以在不同磁盘位置；

（imgdatacenter1的imgrack2和imgdatacenter2按照上面的方式创建即可，见附录 ）
目前我们只是用imgdatacenter1->imgrack1->datanode1中的datanode1 :
创建datanode1的时候 master命令行会打印，提示leader新增child imgdatacenter1成功；imgdatacenter1新增child imgrack1成功；imgdatacenter1，imgrack1新增child 9991成功；volume server在9991端口。

此时再执行查看master状态的命名；
DataCenters Racks DataNodes都存在了；
但是名为localhost:9991的datanode中的volumes为0，明明我们设置了10啊；
因为没有上传文件之前不会创建volume，volume会在上传文件的时候根据实际情况创建。
这里注意下layouts，现在是null，当上传文件的时候会出现一个名为""的collection，里面的writables就是volume 的id数组，如果你自定义了collection，name你自定义的collection也会出现在这里，并且所有collection的volume个数之和小于等于我们设置的10；
collection删除后再新增，里面的volume的id会一直递增，不会使用原先删除的volume id。

此时我们可以上传文件了。
上传文件有多种方式，这里我们先说明两个
1.先向master申请文件id，然后用文件id向datanode上传文件：

修改只需要在fid上传别的文件即可
上传成功后访问，只需要拼接url即可： localhost:9991/1,015b7256d5
2.直接向master上传文件，master自己生成文件id，并向datanode上传文件，然后返回结果：

此时你再查看状态发现volume就创建了10个。

此时查看datanode的状态：

因为我1.jpg上传了两次，而且第一次在id为1的volume中，第二次在id为3的volume中，所有你会发现这两个id的volume的FileCount都为1

并发的上传文件：
一个卷服务器一次只写一个卷。如果需要增加并发性，可以预先分配大量卷。下面是例子。您还可以组合所有不同的选项。状态详情见附录

删除文件：

文件的删除不是实时的，因为weed默认有个阈值，超过这个阈值才会清理没使用的空间，如果你一时间内删除了大量文件，想立马生效，可以用这种方式清理未使用的空间：

此时文件通过url的增删改查都可以了，下面把服务映射成文件系统来操作，可以方便的操作本地的大量文件

filer是将文件以文件目录的方式上传到图片服务，然后你根据文件目录的方式访问

默认使用leveldb保存映射关系，打开filer.toml文件修改保存映射文件的文件夹为ftmp（自定义）

然后启动filer服务

master打印如下信息说明成功

自身的log

直接往weed filer中拷贝目录或者文件（-include是文件模式通配符前使用？？）
weed filer. nginxdir http://localhost:8888/aaa 把nginxdir拷贝到aaa目录下
weed filer. -include *.go . http://localhost:8888/github/
详细请见 https://github.com/chrislusf/seaweedfs/wiki/Filer-Server-API

然而我们时长会有这样的需求，批量把照片保存成图片文件备份起来，而不是备份一个bat文件；
或者我们想以目录结构的方式通过本地访问，而不是通过web访问？
此时最简单有效的方法就是把filer服务器mount到本地，然后直接操作文件系统：
weed mount 像访问本地目录一样访问文件系统，前提是开启了 master volume filer
（它使用bazil.org/FUSE，它允许在Linux和OSX上编写FUSE文件系统。在OSX上，它需要OSXFUSE）

可以指定 collection

关闭挂在需要关闭mount并且手动umont ~/mdir目录，如果一般用户失败请使用root用户

一个场景：
如果本地已经有很多文件了，如何快速的迁移到seaweedfs中呢？
1.启动master、volume、filer
2.启动mount
3.手动拷贝到mount目录中（单线程的）
4.使用weed filer. file_or_dir1 [file_or_dir2 file_or_dir3] http://localhost:8888/path/to/a/folder/ （多线程且绕过fuse层）

aws s3 兼容
Each bucket is stored in one collection, and mapped to folder /buckets/<bucket_name> by default
可以通过删除collection来快速删除一个bucket

异步复制
应该有两个SeawideFileSystems运行，可能跨数据中心运行。每个服务器都应该有自己的文件服务器、主服务器和卷服务器。

这是我执行了（curl " http://localhost:9333/vol/grow?collection=imgcoll&count=3 " ）的结果

详细文档请见官方wiki
https://github.com/chrislusf/seaweedfs/wiki/Getting-Started

J. Redis哨兵模式(主从从)

参考源码配置文件：/root/redis-4.0.8/sentinel.conf

vim /etc/sentinel.conf

从库启动哨兵服务：