diff --git a/数据库/redis/redis三种集群模式.md b/数据库/redis/redis三种集群模式.md
index 32d54de..7e039ba 100644
--- a/数据库/redis/redis三种集群模式.md
+++ b/数据库/redis/redis三种集群模式.md
@@ -18,7 +18,7 @@ redis 目前主流的有三种集群模式，本文将对这三种模式进行
 
 结构最简单的一种，和关系型数据的读写分离类似，一个主节点（master)，多个从节点(slaver)，写入请求全部到主节点上，读取会分散到各个从节点中,架构图如下：
 
-![主从模式-架构图](http://qiniuresource.fleyx.com/blog20210630225614.png)
+![主从模式-架构图](http://sqiniupic.fleyx.com/blog20210630225614.png)
 
 其中比较重要的是主从复制的实现原理，大致可分为三个部分：**建立连接**,**数据同步**,**命令传播**
 
@@ -63,7 +63,7 @@ redis 目前主流的有三种集群模式，本文将对这三种模式进行
 
 同步流程图如下：
 
-![数据同步流程图](http://qiniuresource.fleyx.com/blog/20210702114631.png)
+![数据同步流程图](http://sqiniupic.fleyx.com/blog/20210702114631.png)
 
 1. 从节点接收 slaveof 指令，开始进行数据同步
 2. 判断是否首次进行同步
@@ -76,7 +76,7 @@ redis 目前主流的有三种集群模式，本文将对这三种模式进行
 
 在命令传播阶段主从节点之间会彼此进行心跳检测，如下图：
 
-![主从交互](http://qiniuresource.fleyx.com/blog/20210705172927.png)
+![主从交互](http://sqiniupic.fleyx.com/blog/20210705172927.png)
 
 #### 主节点向从节点发送`ping`命令
 
@@ -141,7 +141,7 @@ docker 部署见：[点击此处](https://github.com/FleyX/demo-project/tree/mas
 
 哨兵模式架构图如下：
 
-![哨兵模式架构图](http://qiniuresource.fleyx.com/blog/20210708154446.png)
+![哨兵模式架构图](http://sqiniupic.fleyx.com/blog/20210708154446.png)
 
 哨兵节点是特殊的 redis 节点，不会用于存储数据
 
@@ -216,7 +216,7 @@ UID=0 GID=0 docker-compose up -d
 
 启动完毕后，哨兵节点的配置文件会增加从节点以及其他哨兵的数据，如下：
 
-![哨兵节点配置文件修改](http://qiniuresource.fleyx.com/blog/20210711215528.png)
+![哨兵节点配置文件修改](http://sqiniupic.fleyx.com/blog/20210711215528.png)
 
 哨兵模式解决了故障转移的问题，但本质仍然是主从架构，只对读做了负载均衡，并未提高写入并发能力，无法应对大量写的问题，大量写的情况就需要对写也做负载均衡，即下面的集群模式.
 
@@ -343,7 +343,7 @@ ba63167ebfd5f8cc9d02331275d15652e3c14aa1 192.168.143.84:11005@21005 slave ddffbf
 
 一致性 hash 引入了一个虚拟圆环，圆环有一个范围，比如 0-2^32-1，然后把真实的节点均分到环中，对于每个 key，先做 hash 然后对环长度取余，得到在环中的位置，然后从此位置顺时针许找第一个遇到的节点，就是数据真实落的节点。
 
-![一致性hash示意图](http://qiniuresource.fleyx.com/blog/20210718115447.png)
+![一致性hash示意图](http://sqiniupic.fleyx.com/blog/20210718115447.png)
 
 如上图所示，一致性哈希中，如果去掉了 cache 服务器 2,那么原本落到服务器 2 的数据就会全部落到服务器 3,对另外两个节点无影响。缺点也很明显，如果节点数比较少，删除一个节点会知道数据分布严重不均匀，比如上图中服务器 3 的数据量会是其他节点的两倍