环境准备
- Linux
- Docker
- docker-compose
Redis镜像版本:7.0.13
容器网络:
docker network create mynetwork
单容器无持久化搭建
配置文件
这是最简单的方式,Redis只在需要的时候缓存临时数据,不需要持久化:
# redis.yml
version: "3"
services:
redis:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis
restart: always
ports:
- 6379:6379
volumes:
- /etc/localtime:/etc/localtime
command: --requirepass 123456
以上创建了一个暴露端口为6379的Redis服务,密码是123456。
启动命令:
docker-compose -f redis.yml up
测试
用Spring Boot连接,在application.yml中可以填:
spring:
redis:
host: 192.168.1.54
port: 6379
password: 123456
jedis:
pool:
max-active: 8 # 连接池最大连接数,负值表示无限制
max-wait: -1 # 连接池最大阻塞等待时间,负值表示无限制
max-idle: 500 # 连接池中的最大空闲连接
min-idle: 0 # 连接池中的最小空闲连接
数据持久化
当我们有数据持久化需求的时候,Redis提供了三种持久化的方案:RDB、AOF和混合模式。
在讲持久化前,我们得先知道Redis是有一个配置文件的:redis.conf
当我们要对Redis做一些定制的时候,就需要修改这个配置文件,完整的配置文件可以在官网上下载:
redis.io/docs/manage…
这个网站上有各个Redis版本的配置文件,因为本文用的是Redis 7.0,所以下载的是:
raw.githubusercontent.com/redis/redis…
将redis.conf放到宿主机的指定路径下,如:
/application/containers/redis/redis.conf
RDB
快照模式,将内存中的数据写到一个rdb文件中,保存的是某个时间点的完整数据。
保存条件可以配置,如10分钟内有1个键的数据发生变法则触发保存。
也可以手动保存,执行命令:save或bgsave,建议使用bgsave命令,因为save是同步进行,会阻塞线程,bgsave是异步进行,不阻塞线程。
优点:
- 性能高:因为是通过时间间隔和键变更数量来触发保存操作,所以生成快照对系统影响较小
- 文件紧凑:RDB文件是二进制形式,相对于AOF文件来说体积更小,占用更少的存储空间
- 适合备份和恢复:保存的是完整数据,适合备份和迁移
缺点:
- 可能会丢失数据:如果RDB生成快照时崩溃,可能导致上一次快照之后的数据丢失
- 恢复速度较慢:恢复大量数据时,需要加载整个快照文件,需要时间较长
RDB是默认开启的,我们把数据映射到宿主机下就可以看到,现在修改docker-compose文件为:
version: "3"
services:
redis-single:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-single
restart: always
ports:
- 6379:6379
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-single/data:/data
command: redis-server --requirepass 123456
多了一个路径映射,这样我们可以在该路径下看到一个文件:dump.rdb
这是Redis的RDB文件
如果看不到这个文件,手动执行以下save命令
修改配置
我们可以编写配置文件来定制RDB,通过查看官网配置上每一个配置项的注释,我们找几个来调整:
# Redis端口
port 6379
# RDB名称
dbfilename mydump.rdb
# RDB保存路径
dir ./
# RDB保存策略
save 3600 1 300 100 60 10000
上面保存策略这段“3600 1 300 100 60 10000”是默认配置,意思是:
- 3600 1:表示900秒内如果至少有1个键发生变化,则执行RDB快照保存
- 300 100:表示300秒内如果至少有100个键发生变化,则执行RDB快照保存
- 60 10000:表示60秒内如果至少有10000个键发生变化,则执行RDB快照保存
这可以通过修改redis.conf后重启容器,或者在命令行动态修改来调整。
把这个配置保存成:redis-single.conf,然后修改Redis启动脚本:
version: "3"
services:
redis-single:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-single
restart: always
ports:
- 6379:6379
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-single/data:/data
- /application/containers/redis/redis-single.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --requirepass 123456
修改内容多了一个配置文件映射,并且启动命令增加了这个配置文件,使自定义配置生效。
现在再去路径下看,会发现RDB文件变成了:mydump.rdb,说明成功了。
AOF
日志模式,每次操作都会记录一条日志。
优点:
- 数据更可靠:可以最大程度保证数据安全性和完整性
- 恢复速度较快:相比RDB,使用AOF恢复数据时只需要重放日志文件中的操作即可
缺点:
- 文件体积较大:因为记录了每一次操作,所以体积更大,占用更多的存储空间
- 写入延迟:每次写操作都要记录到AOF文件中,可能会导致写操作的性能,高负载时尤为明显
AOF默认是不开启的,我们去官网的redis.conf中可以找到相关配置:
# 修改成yes表示开启AOF
appendonly no
# AOF文件名
appendfilename "appendonly.aof"
# AOF文件保存路径
appenddirname "appendonlydir"
# 同步策略:
# always 始终同步,每次Redis的写操作都会立刻记入日志(性能较差,但数据完整性好)
# everysec sec(秒的英文)每秒同步,每秒记入日志一次,如果宕机,该秒数据可能丢失
# no Redis不主动进行同步,把同步时机交给操作系统
appendfsync everysec
# 重写条件:日志大于上次重写的100%且文件大于64M时触发
# 百分比,100表示比上次重写的日志大于100%也就是2倍时触发重写
auto-aof-rewrite-percentage 100
# 至少大于64M才能触发重写
auto-aof-rewrite-min-size 64mb
上面的配置我们只需要修改appendonly为yes即可,即:
# redis.conf
# 修改成yes表示开启AOF
appendonly yes
这样在路径下会看到一个appendonlydir文件夹,里面保存的就是aof文件:
[root@localhost appendonlydir]# ls
appendonly.aof.1.base.rdb appendonly.aof.1.incr.aof appendonly.aof.manifest
我们发现除了aof文件还有rdb文件,这是因为Redis还有一个混合模式,默认情况下,这个混合模式是开启的,也就是说本来就有RDB文件保存,然后我们又开启了AOF,那么就会触发混合模式,这两个文件类型都会存在。
混合模式(RDB+AOF)
混合模式兼顾两者的优点还能解决RDB和AOF的缺点:先加载RDB快照文件,再重放AOF文件,既能解决丢失数据问题,还能解决文件体积大的问题。
缺点:
- 存储和性能开销:同时使用RDB和AOF会增加存储开销,对写操作的性能造成影响
- 配置复杂性:需要同时管理RDB和AOF的配日志。
混合模式的配置:
# redis.conf
# 默认为yes,即开启的
aof-use-rdb-preamble yes
常用的命令行
# 进入redis容器并启动redis-cli命令行工具
# -a 123456:redis密码
# -p 6379:redis端口,可选
# -n 1:使用的db库,可选
docker exec -it redis-single redis-cli -a 123456 -p 6379 -n 1
docker exec -it redis-single redis-cli -a 123456 -n 1
# 查看RDB状态:
CONFIG GET save
3600 1 300 100 60 10000
# 手动修改RDB规则
CONFIG SET save "3600 1"
# 查看上一次生成快照的时间,单位秒
LASTSAVE
# 手动保存,会造成阻塞。
save
# 手动保存,会在后台异步进行快照操作,不会造成阻塞
bgsave
# 查看AOF状态
config get appendonly
# 手动开启或关闭AOF
redis-cli config set appendonly yes
redis-cli config set appendonly no
# 切换到1号库
select 1
# 添加数据
# SET
SET name cc
# 删除数据
# DEL
DEL name
# 查找当前库的所有键
KEYS *
# 模糊查找键
KEYS hello*
# 清空当前库
FLUSHDB
# 清空所有库
FLUSHALL
主从模式
主从模式指一主多从。
注意这里没有多主多从,多主多从是指后面的集群。
工作模式是一台主服务器,提供读写功能,并且将数据同步到其他从服务器上,从服务器对外只有读功能,不提供写功能。
单服务器有两个缺点:
- 数据安全:数据安全不可靠,发生故障会影响其他服务;
- 访问压力:单台服务器的访问压力比较大,可能会超负荷。
主从模式可以解决上面的两个问题:
- 数据安全:主服务器发生故障时,可以让某一台从服务器顶上来做主服务器
- 访问压力:从服务器可以分担读的压力,主服务器主要负责写
我们来编写主从模式的docker-compose,关于redis.conf没有讲究,我们沿用上面单容器的配置即可:
# redis-master-slave.yml
version: "3"
services:
redis-master:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-master
restart: always
ports:
- 6379:6379
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-master/data:/data
- /application/containers/redis/redis-single:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --requirepass 123456
redis-slave1:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-slave1
restart: always
ports:
- 7001:6379
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-slave1/data:/data
- /application/containers/redis/redis-single.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --replicaof redis-master 6379 --masterauth 123456 --requirepass 123456
docker-compose -f redis-master-slave.yml up
这里我们创建了两个Redis容器:redis-master和redis-slave,
Master的配置没有变化,重点在Slave的启动命令上:
redis-server /usr/local/redis/redis.conf --replicaof redis-master 6379 --masterauth 123456 --requirepass 123456
-
--replicaof:这表示成为谁的副本,命令的格式是这样的:--replicaof ,所以后面跟的是:redis-master 6379
这会让该Redis服务器作为主Redis服务器的副本,去同步数据,并且只读,不能写(可以去尝试写数据看看,会提示异常)。
-
--masterauth:因为主服务器要密码,所以从服务器要指定这个密码。
测试
用可视化工具或者其他方式:
- 去主服务器保存一个数据,可以在从服务器上同步看到
- 去从服务器上保存一个数据,会提供异常不允许写入
用命令的方式去实现主从
在主从环境运行过程中,我们也可以通过redis-cli命令来动态调整主从,或者在主服务器故障后手动将从服务器调整成主服务器:
# 通过可视化页面或命令进入redis-cli
docker exec -it redis-slave redis-cli -a 123456 -p 6379
# 不再作为副本
slaveof no one
OK
# 作为副本
slaveof redis-master 6379
OK
主服务器切换告知客户端
当我们手动调整从服务器成功新的主服务器,自然也要告诉客户端主服务器的IP变化了,这一步很灵活,可以通过Nginx调整,也可以通过DNS解析等方式,但是不管怎么方式,最大的问题就是要手动处理,所以我们一般不会只做主从,还会实现哨兵模式。
哨兵模式
主从模式的缺点是需要手动切换主服务器,哨兵模式的出现就是为了解决这个问题:
假设现在有三台服务器,一主二从,那么我们在这三台服务器上分别搭建一个哨兵,他们彼此会互相联系,当发现主服务器无法响应,就会发起投票,选出一个新的主服务器,在这样的条件下,客户端不直接连接Redis主服务器,而且连接这三个哨兵,哨兵会在选出新的主服务器之后告知客户端。
一主二从服务搭建
先搭建一主二从服务,因为我们是在同一台机器上面模拟一主二从,所以要避免端口冲突问题,我们需要准备三个redis.conf配置文件:
- redis7000.conf:主服务器配置
- redis7001.conf:从服务器配置
- redis7002.conf:从服务器配置
内容为:
# Redis端口,为了解决端口冲突问题,三个Redis都要用不同的端口:7000、7001、7002
port 7000
# port 7001
# port 7002
# RDB名称
dbfilename mydump.rdb
# RDB保存路径
dir ./
# RDB保存策略
save 3600 1 300 100 60 10000
# 修改成yes表示开启AOF
appendonly yes
# AOF文件名
appendfilename "appendonly.aof"
# AOF文件保存路径
appenddirname "appendonlydir"
appendfsync everysec
# 重写条件:日志大于上次重写的100%且文件大于64M时触发
# 百分比,100表示比上次重写的日志大于100%也就是2倍时触发重写
auto-aof-rewrite-percentage 100
# 至少大于64M才能触发重写
auto-aof-rewrite-min-size 64mb
# 用来解决返回内网IP的问题,这里得配置公网IP,因为是开发环境,所以这里写宿主机IP
slave-announce-ip 192.168.1.54
拷贝成三份,切记修改port属性,当然如果是三台独立的服务器,不会有端口冲突问题那就没关系。
内容中的:192.168.1.54,是Docker所在宿主机的IP,配置这个的原因,是因为哨兵告知客户端主服务器IP的时候,用的是Docker容器的内网IP(如果不用容器部署就不会有这个问题),类似于:172.0.0.5:6379,这样我们在客户端比如Spring Boot是访问不到的,所以要配置slave-announce-ip,让哨兵返回这个IP。
然后是启动脚本:
version: "3"
services:
redis-master:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-master
restart: always
ports:
- 7000:7000
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-master/data:/data
- /application/containers/redis/redis7000.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --requirepass 123456 --masterauth 123456
redis-slave1:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-slave1
restart: always
ports:
- 7001:7001
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-slave1/data:/data
- /application/containers/redis/redis7001.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --replicaof redis-master 7000 --masterauth 123456 --requirepass 123456
redis-slave2:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-slave2
restart: always
ports:
- 7002:7002
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-slave2/data:/data
- /application/containers/redis/redis7002.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --replicaof redis-master 7000 --masterauth 123456 --requirepass 123456
可以看到和主从模式的配置基本一致,就是分别使用各自的配置文件,目的是为了让哨兵Sentinel可以访问到。
还有端口稍微调整了一下,这点要注意。
哨兵服务搭建
然后是哨兵服务,哨兵需要写配置文件:
# redis-sentinel.conf
# 使用端口
port 26379
# 指定要监控的Redis服务:
#
sentinel monitor mymaster 192.168.1.54 6379 2
# 认证密码
sentinel auth-pass mymaster 123456
# 多少秒内收不到主服务器的ping,就认为它不可用,单位毫秒
sentinel down-after-milliseconds mymaster 5000
# 主节点故障时会重新选举新的主节点,在这个过程中如果新的主节点无法及时接管,这个参数配置的时间会检测到
# 等待一段时间,发现新的主节点仍然不可用则会再次选举
# 集群规模大,节点之间延迟高,或者系统内存在高频写入操作,那么这个值应该尽量小
sentinel failover-timeout mymaster 60000
# 开启DNS解析,这可以解决返回给客户端容器内网IP的问题
SENTINEL resolve-hostnames yes
SENTINEL announce-hostnames yes
配置说明:
-
sentinel monitor mymaster 192.168.1.54 6379 2
sentinel monitor
在这里主服务器IP写的是Docker所在的宿主机IP:192.168.1.54,是因为返回给客户端的主服务器IP也得是这个,不然就会返回一个Docker容器的内网IP,导致客户端无法识别。
数量:指多少个哨兵认为主服务器不可用的时候,才选举新的主服务器。
-
SENTINEL resolve-hostnames yes
这和上面的宿主机IP搭配使用,开启域名解析,返回客户端的才是有效IP。
有了配置文件就可以写哨兵的启动脚本了:
version: "3"
services:
redis-sentinel-master:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-sentinel-master
restart: always
ports:
- 27000:26379
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis/redis-sentinel.conf:/usr/local/redis/sentinel.conf
command: redis-sentinel /usr/local/redis/sentinel.conf
redis-sentinel-1:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-sentinel-1
restart: always
ports:
- 27001:26379
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis/redis-sentinel.conf:/usr/local/redis/sentinel.conf
command: redis-sentinel /usr/local/redis/sentinel.conf
redis-sentinel-2:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-sentinel-2
restart: always
ports:
- 27002:26379
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis/redis-sentinel.conf:/usr/local/redis/sentinel.conf
command: redis-sentinel /usr/local/redis/sentinel.conf
这样哨兵模式就搭建完成了,我们找个客户端来试试。
测试
以Spring Boot为例,配置文件中这样写:
spring:
redis:
password: 123456
jedis:
pool:
max-active: 8 # 连接池最大连接数,负值表示无限制
max-wait: -1 # 连接池最大阻塞等待时间,负值表示无限制
max-idle: 500 # 连接池中的最大空闲连接
min-idle: 0 # 连接池中的最小空闲连接
sentinel:
# 主节点的别名
master: mymaster
# sentinel服务的ip和端口
nodes: mylocalhost:27000,mylocalhost:27001,mylocalhost:27002
Spring Boot使用Redis的代码就不提供了。
启动Spring Boot应用后,可以正常使用Redis,现在把主服务器关掉:
docker stop redis-master
Spring Boot控制台会输出重连日志,然后很快就重新连接上了新的服务器。
Cannot reconnect to [192.168.1.54:7000]: Connection refused: no further information: /192.168.1.54:7000
Reconnecting, last destination was 192.168.1.54:7000
Reconnected to 192.168.1.54:7001
集群模式
哨兵模式解决了手动的问题,缓解了一部分读的压力,但是写的工作终归还是一台主服务器做处理,性能还是有限的,所以集群模式出现了,也就是多主多从。
Redis集群至少需要6个节点,也就是三主三从,因为要保证集群的高可用,即每个主节点都必须有一个从节点,也就是备份节点,所以搞集群服务器成本还是比较高的。
准备配置文件
以三主三从为例,那么我们就得准备6个配置文件:redis-cluster{1...6}.conf
内容为:
# 保护模式
protected-mode no
# Redis端口,同样的,因为是本地模拟,所以得分6个端口,避免冲突
port 7001
# port 7001/7002/7003/7004/7005/7006
# 连接master
masterauth 123456
# 开启集群
cluster-enabled yes
# 集群配置文件路径
cluster-config-file nodes.conf
# 节点不可用的判断时间
cluster-node-timeout 5000
# 声明公网访问IP(这里是宿主机IP)
cluster-announce-ip 192.168.1.54
# 声明公网访问端口
cluster-announce-port 7001
# tls加密传输端口,这里用不上
# cluster-announce-tls-port
# 声明集群传输端口,这是Redis集群彼此传输特定的传输端口,格式是Redis端口+10000得到
# 如Redis端口是6379,那么这里就是16379
cluster-announce-bus-port 17001
6份配置文件,记得把端口修改好,别冲突了。
修改的地方是:
- port:
- cluster-announce-port:
- cluster-announce-bus-port
集群启动脚本
然后是集群启动脚本:
version: "3"
services:
redis-cluster1:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-cluster1
restart: always
ports:
- 7001:7001
- 17001:17001
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-cluster1/data:/data
- /application/containers/redis/redis-cluster1.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --requirepass 123456
redis-cluster2:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-cluster2
restart: always
ports:
- 7002:7002
- 17002:17002
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-cluster2/data:/data
- /application/containers/redis/redis-cluster2.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --requirepass 123456
redis-cluster3:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-cluster3
restart: always
ports:
- 7003:7003
- 17003:17003
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-cluster3/data:/data
- /application/containers/redis/redis-cluster3.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --requirepass 123456
redis-cluster4:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-cluster4
restart: always
ports:
- 7004:7004
- 17004:17004
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-cluster4/data:/data
- /application/containers/redis/redis-cluster4.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --requirepass 123456
redis-cluster5:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-cluster5
restart: always
ports:
- 7005:7005
- 17005:17005
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-cluster5/data:/data
- /application/containers/redis/redis-cluster5.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --requirepass 123456
redis-cluster6:
image: redis:7.0.13
network_mode: mynetwork
container_name: redis-cluster6
restart: always
ports:
- 7006:7006
- 17006:17006
volumes:
- /etc/localtime:/etc/localtime
- /application/containers/redis-cluster6/data:/data
- /application/containers/redis/redis-cluster6.conf:/usr/local/redis/redis.conf
command: redis-server /usr/local/redis/redis.conf --requirepass 123456
创建集群命令
光上面还不够,我们还得手动执行创建一个集群,格式是这样的:
redic-sli -a --cluster create --cluster-replicas 1
- --cluster-replicas:表示副本数量,也就是从服务器数量,因为我们一共6个服务器,这里设置1个副本,那么Redis会收到消息,一个主服务器有一个副本从服务器,那么会计算得出:三主三从。
示例命令如下:
docker exec -it redis-cluster1 \
redis-cli -a 123456 --cluster create \
192.168.1.54:7001 \
192.168.1.54:7002 \
192.168.1.54:7003 \
192.168.1.54:7004 \
192.168.1.54:7005 \
192.168.1.54:7006 \
--cluster-replicas 1
执行命令,Redis集群会计算主服务器插槽分配,然后给出分配结果:
M: e22bc285b8e8def8fbcec23c3d0840fff8211978 192.168.1.54:7001
slots:[0-5460] (5461 slots) master
M: 438ab9d8bd3db3d774d0b1d074894f4404cf9bc7 192.168.1.54:7002
slots:[5461-10922] (5462 slots) master
M: b3f82b2595e5c26b7a162b729b7a65e3b0b5809e 192.168.1.54:7003
slots:[10923-16383] (5461 slots) master
S: 52b7bfb236d07afb2395eceb7c7f909a6938be22 192.168.1.54:7004
replicates e22bc285b8e8def8fbcec23c3d0840fff8211978
S: 08d00b0bd094cdc7e74d2636113fffdce0326e1e 192.168.1.54:7005
replicates 438ab9d8bd3db3d774d0b1d074894f4404cf9bc7
S: 3da8059f333c3e21aeb0660395636ae899df10dc 192.168.1.54:7006
replicates b3f82b2595e5c26b7a162b729b7a65e3b0b5809e
Can I set the above configuration? (type 'yes' to accept): 这里问你是否同意,输入yes即可
上面意思是Redis分配好了哪三台主,哪三台从,看你是否同意,yes即可。
输出以下内容表示完成:
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
测试
还是用Spring Boot连接试试:
spring:
redis:
password: 123456
jedis:
pool:
max-active: 8 # 连接池最大连接数,负值表示无限制
max-wait: -1 # 连接池最大阻塞等待时间,负值表示无限制
max-idle: 500 # 连接池中的最大空闲连接
min-idle: 0 # 连接池中的最小空闲连接
cluster:
nodes: 192.168.1.54:7001,192.168.1.54:7002,192.168.1.54:7003,192.168.1.54:7004,192.168.1.54:7005,192.168.1.54:7006
timeout: 3000
总结
本文分享了Redis各种场景下的部署流程,以我的经验:
开发环境用单容器无持久化,可以节省很多功夫,还能免掉一些数据缓存导致的bug,增加调试时长。
生产环境要么是哨兵模式,要么是集群模式,依项目量级来考量。