Redis停止的命令

Redis停止的命令

我的redis是部署在linux机器上的，而且是redis集群。下面的命令都是在linux上使用的。

执行后，输出的记录中，含有“redis-server”的行，全是运行的redis服务节点。

“redis-server”所在行的最后，会有“IP:端口号”，执行第3步停止redis集群时要使用。

第一行记录，都要执行一次停止命令。

2 进入redis-cli所在目录

注：如果不知道redis-cli所在目录，请使用如下命令查找（网上很多的人回答，redis-cli在redis/bin目录，我的机器却不是）

3 停止redis服务，使用的IP、端口号为第1步查看出的IP、端口号。

第一步中的第一行记录，都要执行一次停止命令。

注：不加“-h IP”参数时，会提示如下内容，停止是失败的

Could not connect to Redis at 127001:XXXX: Connection refused

4 查看redis服务是否停止成功

执行后，输出的记录中，不存在含有“redis-server”的行，则redis服务停止成功。

原文：

YouLuoJv使用知识的小砖垒起质量、效率灯塔，希望可以照亮更多人的路

先如今我们想要自己搭建一套多redis节点/实例的集群，实现一套无主模型的集群

Redis 集群的数据分片

Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念

Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:

我们先去到存放redi源码目录下，打开utils目录，会发现里面有个create-cluster文件夹，进入这个文件夹，会发现有如下两个文件：

我们先打开README文件看看里面是写了什么？

我们再来看看creat-cluster这个脚本文件里面装着什么药？

我们分析一下最前面的内容：

我们先把redis运行起来，执行以下指令后，会发现有启动了6个端口，代表着启动了6台redis

我们再这6台redis，进行搭建集群，“分赃”（是指分给每个master给一些槽位），执行以下指令后，会发现其中的30005跟随30001，其中的30006跟随30002，其中的30004跟随30003

我们看到，这个redis cluster为其中的3个master准备了一些槽位：

这个时候我们尝试连接其中一个master，随便哪个，我这里连接的是30001端口，然后做了一些 *** 作，你会发现下面的中，有两句指令是报错的，只有第一句指令是返回OK的，是什么原因呢？

redis-cli -p 30001

使用以下指令就可以重定向到对应映射值的端口上

我们尝试一下能不能使用事务，如下图，我们开启事务后，中间是有几次经过hash算法之后重定向到其他端口上面的，到最后我们执行exec之后报错。是因为我们在30001上开启的事务，由于hash值映射我们重定向到其他端口上了，其他端口并没有开启事务，所以报错！

我们可以将某些类似于相同hash值的key放在一块执行，这样就可以避免重定向，从而实现事务 *** 作

接下来我们换一种方式来进行实现redis cluster，用原始的命令来实现。我们先把启动的redis关掉，并把持久化文件删除，然后再启动

使用redis原生命令来启动，我们先查询help

输入指令原生指令，启动redis cluster，启动成功，和刚才的一模一样

我们再尝试连接客户端，进行一些 *** 作，和我们用脚本启动一模一样

解下来我们再了解一些reshard这个指令，给数据从新分片

输入指令后，redis会提示我们要移出多少个槽位，我们随便填个3000，然后回车

接下来，将接收方的节点id输入进去，目的是要把这3000个槽位移动给接收方

注意我们这里提示错误，原因是我们移动给了一个不是master的节点

我们给一个master的节点id重来一遍，接着要我们提供槽位来源，可以选一个或者多个槽位来源，比如我们要把3000个槽位移动给30002端口，我们可以从30001上移动也可以从30003上移动，我们直接在30001上移过来

输入yes回车

等待一会，我们看到3000个节点，从30001移动到30002端口上面了

我们可以查看槽位分布情况

原先是分布比较平均，都是5461个槽位，而我们从30001移动3000个到30002，发现原来的30001的只剩下2461个槽位的确少了3000个，并且30002的现在由8462个槽位多了3000个槽位！

种种现象我们看到，这完全就符合我们开头说的，用数据哈希槽的方式去分片数据，也就redis内部实现的预分区

如果所示，之前的集群是三主三从的Redis集群，现在要加入一主一从，主从复制。主节点端口是7004，从节点端口是8004。

此时新加入的节点 7004 并没有数据，并且也没有被分配 slot 也就是 目前 7004 是不可用的，现在要重新分配原集群的 slot

迁移多少个slots呢，16384/4=4096，那么就迁移4096个。

这里是选择接收方的 node id ，就是执行 cluster nodes 显示7004的字符串。

这里是选择slot的迁出方，我们这边选择的是 all ，也就是所有的节点，总共迁出4096个slot到7004

中间会让你输入 yes

一顿 *** 作之后

我们看到 7004 已经有slot了 0-1364 5461-6826 10923-12287

输入 yes 之后主从复制就完成了。我们看一下节点没问题了。

redis 集群多了之后，发现现在的有些节点有些多余没用，或者达不到用那么多节点的情况，那么就可以进行 节点的移除， 50 版本由于不用 ruby 进行集群 *** 作了，所以方式跟50以前有很多不同的地方

我们由于刚刚添加了2个节点，现在把这2个节点删除，需要注意的是，假如你要下线节点7004，节点8004，请务必先下线从节点，并且把节点7004的slot的迁移到其他节点，如果先线下节点7004的话 会发产生故障切换，节点8004成主节点了。

查看一下，已经没有节点8004了

接着删除7004，这个是一个主节点，删除起来比较麻烦一点，因为主节点分配了slot槽， 所以这里我们必须先把 7004的slot槽放到其他的可用节点中去，然后再进行移除节点 *** 作才行，不然会出现数据丢失问题

由于节点7004有4096个slot，那么3个节点平均可以分配 4096/3=13653 ,不能有小数，那么我们可以分别分配 1365 , 1365 , 1366 给 7001 , 7002 , 7003 节点

这里输入 1365 和 接收者 7001 的 node id

这里输入你想从那个节点移走数据，我们选 7004 的 node id

其实是让你还可以选择源节点，但是我这里只要把7004 节点分到其它地方就行，如果没有再把其它主节点分摊的需要，此处输入 done即可，否则输入其它节点的ID，最后输入 done

是否按照计划分配，输入 yes

完成！！！

然后继续向另外2个节点分配slot

。。。。

我们最后查看

7004已经没有slot了，那么就可以删除了节点7004了

查看，完美！

背景介绍：我们系统使用的缓存服务是付费版的阿里云的redis集群服务，配置是4核，16G。redis的集群结构如下：分为四个节点DB0，DB1，DB2，DB3

之前的存储方案是存储的商品促销数据，结构是：

KEY FIELD VALUE来存储。其中KEY是一个固定的字符串"zy:prom:wx"，FIELD则是商品sku，VALUE是商品促销的具体信息。这种方式导致我们存入缓存服务器的数据一直集中在DB0节点上，在访问量过大时，该节点会在短时间内受到到的访问压力很大，DB0的cpu瞬间达到100%以上，造成服务卡顿甚至不可用。而相比之下DB1，DB2，DB3的节点cpu压力却很小，可以忽略不计。这是为什么？最后询问了阿里的技术，他们说我们的数据存储的方法有误，具体是我们的key设置有误。与阿里的技术对话如下：

所以我们后来改造了方案把key的组成变程了"prom:wx:sku",这样key就会根据sku的不同而不同，增大了key的离散度，这样key通过hash算出来的值，就会不同，使得所有的数据不再存放到同一台节点上，完美解决问题。

修改后的存储分布情况如下图：DB0、DB1、DB2、DB3四个节点数据均匀分布。

对修改前后两天同一时间区间的缓存服务器的cpu压力情况对比：

以上就是关于Redis停止的命令全部的内容，包括:Redis停止的命令、Redis集群cluster实 *** 、Redis 5.0 cluster 添加和移除节点等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！