Redis持久化的两种方式和配置(Redis主从复制和集群配置)(Redis实战总结-配置、持久化、复制)
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Redis持久化的两种方式和配置(Redis主从复制和集群配置)(Redis实战总结-配置、持久化、复制)，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含21529字，纯文字阅读大概需要31分钟。
内容图文
https://blog.csdn.net/helloveada/article/details/78495964
Redis优秀的性能是由于其将所有的数据都存储在内存中，同样memcached也是这样做的，但是为什么Redis能够脱颖而出呢，很大程度上是因为Redis有出色的持久化机制，能够保证服务器重启后，数据不会丢失。下面来看看Redis是如何持久化的。
Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。这两种方式可以单独使用其中一种，或者混合使用。
RDB方式介绍
RDB方式是通过快照完成的，当符合一定条件时Redis会自动将内存中的所有数据进行快照，并且存储到硬盘上。就像拍照一样，将这一瞬间的所有东西都保存下来。进行快照的条件在配置文件中指定。主要有两个参数构成：时间和改动的键值的个数，即当在指定时间内被更改的键的个数大于执行数值时，就会进行快照。RDB是Redis的默认持久化方式。
RDB方式配置
找到Redis的配置文件：redis.conf
1） 设置触发条件：
2) 设置rdb文件路径
默认rdb文件存放路径是当前目录，文件名是：dump.rdb。可以在配置文件中修改路径和文件名，分别是dir和dbfilename
Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存，一般情况下1GB的快照文件载入到内存的时间大约20-30分钟。
RDB如何进行快照
RDB的快照过程：
1） Redis使用fork函数复制一份当前进程（父进程）的副本；
2） 父进程继续接受并处理客户端发来的命令，而子进程开始将内存中的数据写入到硬盘中的临时文件；
3） 当子进程写入完成所有数据后会用该临时文件替换旧的RDB文件。
手动快照：
如果没有触发自动快照，可以对redis进行手动快照操作，SAVE和BGSAVE都可以执行手动快照，两个命令的区别是前者是由主进程进行快照操作，会阻塞其他请求；而后者是通过fork子进程进行快照操作。
注意：
由于redis使用fork来复制一份当前进程，那么子进程就会占有和主进程一样的内存资源，比如说主进程8G内存，那么在备份的时候必须保证有16G内存，要不然会启用虚拟内存，性能非常差。
RDB文件的压缩
RDB文件过大时，是可以压缩的，Redis默认开启压缩，当然也可以通过配置rdbcompression参数来禁用压缩。
压缩和不压缩的优缺点：
压缩：
-
优点：减少磁盘存储空间 -
缺点：消耗CPU资源
- 1
- 2
- 3
不压缩：
-
优点：不消耗CPU资源 -
缺点：占用磁盘空间多
- 1
- 2
- 3
如何选择？ 那就需要看需求、看服务器资源情况了。
https://blog.csdn.net/guweiyu_thinker/article/details/78816071
Redis的配置主要放置在redis.conf，可以通过修改配置文件实现Redis许多特性，比如复制，持久化，集群等。
redis.conf部分配置详解
# 启动redis，显示加载配置redis.conf
# ./redis-server /path/to/redis.conf
# 停止redis
# redis-cli -h IP -p PORT shutdown
# 可以包含一个或多个其他配置文件，如果多个redis服务器存在标准配置模板，但是每隔redis服务器可能有个性化的配置
# include /path/to/local.conf
# include /path/to/other.conf
# 这个地方网上存在许多误解，bind的是网络接口。对于一个redis服务器来说可以有一个或者多个网卡。比如服务器上有两个网卡：bind 192.168.1.100 192.168.1.101，如果bind bind 192.168.1.100，则只有该网卡地址接受外部请求，如果不绑定，则两个网卡都接受请求
# bind 192.168.1.100 192.168.1.101
# bind 127.0.0.1 ::1
# 监听端口号，默认为6379，如果为0监听任连接
port 6379
# TCP连接中已完成队列的长度
tcp-backlog 511
#客户端和Redis服务端的连接超时时间，默认为0表示永不超时
timeout 0
# 服务端周期性时间（单位秒）验证客户端是否处在健康状态，避免服务端一直阻塞
tcp-keepalive 300
# Redis以后台守护进程形式启动
daemonize yes
# 配置PID文件路径，当redis以守护进程启动时，它会把PID默认写到 /var/redis/run/redis_6379.pid文件里面
pidfile "/var/run/redis_6379.pid"
#Redis日志级别：debug，verbose，notice，warning，级别一次递增
loglevel notice
#日志文件路径及名称
logfile ""
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Redis持久化
为了能够重用Redis数据，或者防止系统故障，我们需要将Redis中的数据写入到磁盘空间中，即持久化。
Redis提供了两种不同的持久化方法可以将数据存储在磁盘中，一种叫快照（RDB），另一种叫只追加文件（AOF）。
RDB方式
Redis通过创建快照的方式获取某一时刻Redis中所有数据的副本。用户可以针对该快照进行各种操作，比如：将快照复制到其他服务器从而完成Redis的主从复制，或者将快照留在原地，服务器重启的时候重用数据。
根据配置文件，可以手动设置Redis快照名及路径：
# RDB文件名
dbfilename "dump.rdb"
# RDB文件和AOF文件路径
dir "/usr/local/var/db/redis"
1
2
3
4
Redis创建快照主要有以下几种方式：
* （1）客户端直接通过命令BGSAVE或者SAVE来创建一个快照
- BGSAVE是通过redis调用fork来创建一个子进程，然后子进程负责将快照写入磁盘，而父进程仍然继续处理命令。
- SAVE是在没有足够的内存空间去执行BGSAVE或者无所谓等待的时候。执行SAVE命令过程中，redis不在响应任何其他命令。
1
2
（2）在redis.conf中设置save配置选项（应用开发中比较常用）
# 当在规定的时间内，Redis发生了写操作的个数满足条件，会触发发生BGSAVE命令。
# save <seconds> <changes>
# 当用户设置了多个save的选项配置，只要其中任一条满足，Redis都会触发一次BGSAVE操作，比如：900秒之内至少一次写操作、300秒之内至少发生10次写操作、60秒之内发生至少10000次写操作都会触发发生快照操作
save 900 1
save 300 10
save 60 10000
1
2
3
4
5
6
(3) 当Redis通过shutdown命令关闭服务器请求时，会执行SAVE命令创建一个快照，如果使用kill -9 PID将不会创建快照。
(4) 主从同步，这个将在下面一小节讲解。
注意：
在只使用快照持久化来报错数据时，如果系统崩溃或者强杀，用户将会丢失最近一次生成快照之后更改的所有数据。因此如果应用程序对于两次快照间丢失的数据可接受，利用快照就是一个很好的方式，但是往往一些系统对于丢失几分钟的数据都不可接受，比如高频的电子商务系统。
此外，如果Redis存储的数据量长达数十G的时候，没执行一次快照需要花费大量时间，严重影响到服务器的性能。
1
2
3
因此，针对上述的问题，可以使用AOF方式来持久化数据。
AOF方式
在执行写命令时，AOF持久化会将执行的写命令也写到AOF文件的末尾，以此来记录数据的变化。换句话说，将AOF文件中包含的内容重新执行一遍，就可以回复AOF文件所记录的数据集。
在Redis.conf配置中设置如下：
# redis默认关闭AOF机制，可以将no改成yes实现AOF持久化
appendonly no
# AOF文件
appendfilename "appendonly.aof"
# AOF持久化同步频率，always表示每个Redis写命令都要同步fsync写入到磁盘中，但是这种方式会严重降低redis的速度；everysec表示每秒执行一次同步fsync，显示的将多个写命令同步到磁盘中；no表示让操作系统来决定应该何时进行同步fsync，Linux系统往往可能30秒才会执行一次
# appendfsync always
appendfsync everysec
# appendfsync no
# 在日志进行BGREWRITEAOF时，如果设置为yes表示新写操作不进行同步fsync，只是暂存在缓冲区里，避免造成磁盘IO操作冲突，等重写完成后在写入。redis中默认为no
no-appendfsync-on-rewrite no
# 当前AOF文件大小是上次日志重写时的AOF文件大小两倍时，发生BGREWRITEAOF操作。
auto-aof-rewrite-percentage 100
#当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF。
auto-aof-rewrite-min-size 64mb
# Redis再恢复时，忽略最后一条可能存在问题的指令(因为最后一条指令可能存在问题，比如写一半时突然断电了)
aof-load-truncated yes
#Redis4.0新增RDB-AOF混合持久化格式，在开启了这个功能之后，AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内存则用于记录最近发生了变化的数据，这样Redis就可以同时兼有RDB持久化和AOF持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）。
aof-use-rdb-preamble no
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
RDB与AOF同时开启 默认先加载AOF的配置文件，因此需要根据具体情况使用，4.0+的可以使用RDB-AOF混合持久化格式
Redis复制
本部分只介绍主从同步的简单实现，并利用哨兵机制实现高可用，不介绍集群Cluster无中心的方式（放在后面的博客中详解）。
Redis主从复制
在Redis中实现主从复制比较简单，只需要修改slave服务器的redis.conf中的slaveof。下面利用一个具体的实例展示主从同步。
主从复制示例
环境如下： MacOS，Redis版本4.0.2
master服务器：127.0.0.1 6379
slave服务器：127.0.0.1 6399
配置slave服务器：
# 设置master服务器IP和端口
slaveof 127.0.0.1 6379
# slave是否只读，从服务器负责读操作，主服务器负责写操作，从而实现读写分离
slave-read-only yes
1
2
3
4
分别按照顺序启动mater(redis-server redis.conf)和slave(redis-server redis2.conf)
在master中添加元素
在slave服务器中可以获得元素
主从复制如何交互
下面来研究下slave服务器和master服务器间是如何建立起主从同步机制的。
Slave服务启动，主动连接Master，并发送SYNC命令，请求初始化同步
Master收到SYNC后，执行BGSAVE命令生成RDB文件，并缓存该时间段内的写命令
Master完成RDB文件后，将其发送给所有Slave服务器，
Slave服务器接收到RDB文件后，删除内存中旧的缓存数据，并装载RDB文件
Master在发送完RDB后，即刻向所有Slave服务器发送缓存中的写命令
至此初始化完成，后续进行增量同步
上述主从复制模式链是非常脆弱的，一旦Master服务器发生宕机，会导致无法向redis中读取或者写入数据，高可用性极差。
https://blog.csdn.net/u011204847/article/details/51307044?utm_source=blogxgwz3 Redis主从复制和集群配置
redis主从复制
概述
1、redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。
2、通过redis的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。
主从复制过程
主从复制过程：见下图
过程：
1：当一个从数据库启动时，会向主数据库发送sync命令，
2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来
3：当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库。
4：从数据库收到后，会载入快照文件并执行收到的缓存的命令。
注意：redis2.8之前的版本：当主从数据库同步的时候从数据库因为网络原因断开重连后会重新执行上述操作，不支持断点续传。
redis2.8之后支持断点续传。
配置
Redis主从结构支持一主多从
主节点：192.168.33.130
从节点：192.168.33.131
注意：所有从节点的配置都一样
方式1：手动修改配置文件
只需要额外修改从节点中redis的配置文件中的slaveof属性即可
slaveof 192.168.33.130 6379
配置修改图示：
配置效果图示：
1、192.168.33.130主机：启动130主节点上面的redis，查看redis的info信息
2、192.168.33.131主机：启动131从节点上面的redis，查看redis的info信息
方式2：动态设置
通过redis-cli 连接到从节点服务器，执行下面命令即可。
slaveof 192.168.33.130 6379
演示结果和手动方式一致。
注意事项
如果你使用主从复制，那么要确保你的master激活了持久化，或者确保它不会在当掉后自动重启。原因：
slave是master的完整备份，因此如果master通过一个空数据集重启，slave也会被清掉。
在配置redis复制功能的时候如果主数据库设置了密码，需要在从数据的配置文件中通过masterauth参数设置主数据库的密码，这样从数据库在连接主数据库时就会自动使用auth命令认证了。相当于做了一个免密码登录。
redis的Sentinel
sentinel功能
redis的sentinel系统用于管理多个redis服务器，该系统主要执行三个任务：监控、提醒、自动故障转移。
1、监控（Monitoring）： Redis Sentinel实时监控主服务器和从服务器运行状态，并且实现自动切换。
2、提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Redis Sentinel 可以向系统管理员发送通知， 也可以通过 API 向其他程序发送通知。
3、自动故障转移（Automatic failover）： 当一个主服务器不能正常工作时，Redis Sentinel 可以将一个从服务器升级为主服务器， 并对其他从服务器进行配置，让它们使用新的主服务器。当应用程序连接Redis 服务器时， Redis Sentinel会告之新的主服务器地址和端口。
注意：在使用sentinel监控主从节点的时候，从节点需要是使用动态方式配置的，如果直接修改配置文件，后期sentinel实现故障转移的时候会出问题。
图示sentinel
主观下线和客观下线：
1、主观下线状态：当一个sentinel认为一个redis服务连接不上的时候，会给这个服务打个标记为下线状态。
2、客观下线状态：当多个sentinel认为一个redids连接不上的时候，则认为这个redis服务确实下线了。这里的多个sentinel的个数可以在配置文件中设置。
主节点：主观下线和客观下线
从节点：主观下线状态
sentinel配置
修改sentinel.conf文件
sentinel monitor mymaster 192.168.33.130 6379 2 #最后一个参数视情况决定
最后一个参数为需要判定客观下线所需的主观下线sentinel个数，这个参数不可以大于sentinel个数。
启动sentinel
redis-sentinel sentinel.conf
启动后结果图示：
sentinel日志明细说明
http://redisdoc.com/topic/sentinel.html
通过订阅指定的频道信息，当服务器出现故障得时候通知管理员
客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器，你不可以使用 PUBLISH 命令向这个服务器发送信息，但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。
一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。
sentinel的一些命令
INFO
sentinel的基本状态信息
SENTINEL masters
列出所有被监视的主服务器，以及这些主服务器的当前状态
SENTINEL slaves <master name>
列出给定主服务器的所有从服务器，以及这些从服务器的当前状态
SENTINEL get-master-addr-by-name <master name>
返回给定名字的主服务器的 IP 地址和端口号
SENTINEL reset <pattern>
重置所有名字和给定模式 pattern 相匹配的主服务器。重置操作清除主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel 。
SENTINEL failover <master name>
当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移，但是它会给其他sentinel发送一个最新的配置，其他sentinel会根据这个配置进行更新
java操作sentinel
代码示例：
import java.util.HashSet;
//需要在pom.xml文件中引入jedis依赖
import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPoolConfig;
import redis.clients.jedis.JedisSentinelPool;
public class SentinelTest {
public static void main(String[] args) {
// 使用HashSet添加多个sentinel
HashSet<String> sentinels = new HashSet<String>();
// 添加sentinel主机和端口
sentinels.add("192.168.33.131:26379");
// 创建config
JedisPoolConfig poolConfig = new JedisPoolConfig();
// 控制一个pool最多有多少个状态为idle(空闲的)的jedis实例。
poolConfig.setMaxIdle(10);
// 控制一个pool最多有多少个jedis实例。
poolConfig.setMaxTotal(100);
// 表示当borrow(引入)一个jedis实例时，最大的等待时间，如果超过等待时间，则直接抛出JedisConnectionException；
poolConfig.setMaxWaitMillis(2000);
// 在borrow一个jedis实例时，是否提前进行validate操作；如果为true，则得到的jedis实例均是可用的；
poolConfig.setTestOnBorrow(true);
// 通过Jedis连接池创建一个Sentinel连接池
JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels,poolConfig);
// 获取master的主机和端口
HostAndPort currentHostMaster = pool.getCurrentHostMaster();
System.out.println(currentHostMaster.getHost() + "--"+ currentHostMaster.getPort());
// 从Sentinel池中获取资源
Jedis resource = pool.getResource();
// 打印资源中key为name的值
System.out.println(resource.get("name"));
// 关闭资源
resource.close();
}
}
打印结果：
redis集群
简介
redis集群是一个无中心的分布式Redis存储架构，可以在多个节点之间进行数据共享，解决了Redis高可用、可扩展等问题。redis集群提供了以下两个好处
1、将数据自动切分(split)到多个节点
2、当集群中的某一个节点故障时，redis还可以继续处理客户端的请求。
一个 Redis 集群包含 16384 个哈希槽（hash slot），数据库中的每个数据都属于这16384个哈希槽中的一个。集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽。集群中的每一个节点负责处理一部分哈希槽。
集群中的主从复制
集群中的每个节点都有1个至N个复制品，其中一个为主节点，其余的为从节点，如果主节点下线了，集群就会把这个主节点的一个从节点设置为新的主节点，继续工作。这样集群就不会因为一个主节点的下线而无法正常工作。
注意：
1、如果某一个主节点和他所有的从节点都下线的话，redis集群就会停止工作了。redis集群不保证数据的强一致性，在特定的情况下，redis集群会丢失已经被执行过的写命令
2、使用异步复制（asynchronous replication）是 Redis 集群可能会丢失写命令的其中一个原因，有时候由于网络原因，如果网络断开时间太长，redis集群就会启用新的主节点，之前发给主节点的数据就会丢失。
安装配置
修改配置文件redis.conf
daemonize yes
port 6379
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
要让集群正常运作至少需要三个主节点
我们这里就简单在一台主机上创建6个redis节点来演示集群配置，实际生产环境中需要每个节点一台主机。
我们要创建的6个redis节点，其中三个为主节点，三个为从节点，对应的redis节点的ip和端口对应关系如下：
192.168.33.130:7000
192.168.33.130:7001
192.168.33.130:7002
192.168.33.130:7003
192.168.33.130:7004
192.168.33.130:7005
1、首先我们创建6个以端口为名称的文件夹（由于每个redis节点启动的时候，都会在当前文件夹下创建快照文件，所以我们需要创建每个节点的启动目录）
mkdir 7000
mkdir 7001
mkdir 7002
mkdir 7003
mkdir 7004
mkdir 7005
2、接下来把每个节点启动所需要的配置文件拷贝到相应的启动目录：
cp redis.conf 7000
cp redis.conf 7001
cp redis.conf 7002
cp redis.conf 7003
cp redis.conf 7004
cp redis.conf 7005
3、然后我们进入每个启动目录，修改之前拷贝的redis.conf文件中的端口port 为上面列出的对应端口。
最终每个节点的配置类似于：
daemonize yes
port 6379 #只有端口不同，其他相同
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
4、进入每个启动目录，以每个目录下的redis.conf文件启动
使用命令查看redis节点是否启动
ps -ef | grep redis
5、创建集群命令
redis-trib.rb create --replicas 1 192.168.33.130:7000 192.168.33.130:7001 192.168.33.130:7002 192.168.33.130:7003 192.168.33.130:7004 192.168.33.130:7005
注意：
5.1、执行上面的命令的时候可能会报错，因为是执行的ruby的脚本，需要ruby的环境
错误内容：
所以我们需要安装ruby的环境，这里推荐使用yum安装：
yum install ruby
5.2、安装ruby后，执行命令可能还会报错，提示缺少rubygems组件，使用yum安装
解决方法：
yum install rubygems
5.3、上面两个步骤后，执行创建集群目录可能还会报错，提示不能加载redis，是因为缺少redis和ruby的接口，使用gem 安装。
解决方法：
gem install redis
上面三个问题解决后，启动创建集群应该可以正常启动了：
这里输入yes
最后结果：
到此，我们的集群搭建成功了。
6、接下来我们使用命令进入集群环境
redis-cli -c -p 7000
redis集群操作
使用redis-cli客户端来操作redis集群，使用命令 ：
redis-cli -c -p [port]
查看集群中的所有主节点信息
redis-cli -c -p 7000 cluster nodes [| grep master]
redis集群添加节点
根据添加节点类型的不同，有两种方法来添加新节点
1、主节点：如果添加的是主节点，那么我们需要创建一个空节点，然后将某些哈希槽移动到这个空节点里面
2、从节点：如果添加的是从节点，我们也需要创建一个空节点，然后把这个新节点设置成集群中某个主节点的复制品。
添加节点：
1、首先把需要添加的节点启动
创建7006目录，拷贝7000中的redis.conf到7006中，然后修改端口port为7006，修改好后进入7006目录启动这个节点：
redis-server redis.conf
2、执行以下命令，将这个新节点添加到集群中：
redis-trib.rb add-node 192.168.33.130:7006 192.168.33.130:7000
结果图示：
3、执行命令查看刚才新增的节点：
redis-cli -c -p 7000 cluster nodes
4、增加了新的节点之后，这个新的节点可以成为主节点或者是从节点
4.1将这个新增节点变成从节点
前面我们已经把这个新节点添加到集群中了，现在我们要让新节点成为192.168.33.130:7001的从节点，只需要执行下面的命令就可以了，命令后面的节点ID就是192.168.33.130:7001的节点ID。（注意，这个从节点哈希槽必须为空，如果不为空，则需要转移掉哈希槽使之为空）
redis-cli -c -p 7006 cluster replicate a246963893faf03c45cc19ef4188f82f5393bfef
使用下面命令来确认一下192.168.33.130:7006是否已经成为192.168.33.130:7001的从节点。
redis-cli -p 7000 cluster nodes | grep slave | grep a246963893faf03c45cc19ef4188f82f5393bfef
4.2、将这个新增节点变成主节点：
使用redis-trib程序，将集群中的某些哈希槽移动到新节点里面，这个新节点就成为真正的主节点了。执行下面的命令对集群中的哈希槽进行移动：
redis-trib.rb reshard 192.168.33.130:7000
命令执行后，系统会提示我们要移动多少哈希槽，这里移动1000个
然后还需要指定把这些哈希槽转移到哪个节点上
输入我们刚才新增的节点的ID
d113e0f033c98e2f6b88fb93e6e98866256d85c4
然后需要我们指定转移哪几个几点的哈希槽
输入all 表示从所有的主节点中随机转移，凑够1000个哈希槽
然后再输入yes，redis集群就开始分配哈希槽了。
至此，一个新的主节点就添加完成了，执行命令查看现在的集群中节点的状态
redis-cli -c -p 7000 cluster nodes
结果图示：
Redis集群删除节点
1、如果删除的节点是主节点，这里我们删除192.168.33.130:7006节点，这个节点有1000个哈希槽
首先要把节点中的哈希槽转移到其他节点中，执行下面的命令：
redis-trib.rb reshard 192.168.33.130:7000
系统会提示我们要移动多少哈希槽，这里移动1000个，因为192.168.33.130:7006节点有1000个哈希槽。
然后系统提示我们输入要接收这些哈希槽的节点的ID，这里使用192.168.33.130:7001的节点ID
然后要我们选择从那些节点中转出哈希槽，这里一定要输入192.168.33.130:7006这个节点的ID
最后输入done表示输入完毕。
最后一步，使用下面的命令把这个节点删除
redis-trib.rb del-node 192.168.33.130:7000 d113e0f033c98e2f6b88fb93e6e98866256d85c4 //最后一个参数为需要删除的节点ID
2、如果是从节点，直接删除即可。
redis-trib.rb del-node 192.168.33.130:7000 d113e0f033c98e2f6b88fb93e6e98866256d85c4 //最后一个参数为需要删除节点的ID
java操作redis集群
向Redis集群中存入键值：
代码示例：
import java.util.HashSet;
//需要再pom.xml中引入jedis依赖
import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.JedisCluster;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
public class RedisCluster {
public static void main(String[] args) {
//初始化集合，用于装下面的多个主机和端口
HashSet<HostAndPort> nodes = new HashSet<HostAndPort>();
//创建多个主机和端口实例
HostAndPort hostAndPort = new HostAndPort("192.168.33.130", 7000);
HostAndPort hostAndPort1 = new HostAndPort("192.168.33.130", 7001);
HostAndPort hostAndPort2 = new HostAndPort("192.168.33.130", 7002);
HostAndPort hostAndPort3 = new HostAndPort("192.168.33.130", 7003);
HostAndPort hostAndPort4 = new HostAndPort("192.168.33.130", 7004);
HostAndPort hostAndPort5 = new HostAndPort("192.168.33.130", 7005);
//添加多个主机和端口到集合中
nodes.add(hostAndPort);
nodes.add(hostAndPort1);
nodes.add(hostAndPort2);
nodes.add(hostAndPort3);
nodes.add(hostAndPort4);
nodes.add(hostAndPort5);
//创建config
JedisPoolConfig poolConfig = new JedisPoolConfig();
//通过config创建集群实例
JedisCluster jedisCluster = new JedisCluster(nodes,poolConfig);
//获取集群中的key为name键的值
String str = jedisCluster.get("name");
System.out.println(str);
}
}
打印结果：
内容总结
以上是互联网集市为您收集整理的Redis持久化的两种方式和配置(Redis主从复制和集群配置)(Redis实战总结-配置、持久化、复制)全部内容，希望文章能够帮你解决Redis持久化的两种方式和配置(Redis主从复制和集群配置)(Redis实战总结-配置、持久化、复制)所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。