这篇文章主要介绍“redis安装配置及整合SpringBoot的方法”，在日常操作中，相信很多人在Redis安装配置及整合SpringBoot的方法问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Redis安装配置及整合SpringBoot的方法”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
目前创新互联已为近千家的企业提供了网站建设、域名、网络空间、网站托管、企业网站设计、北林网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
# 下载Redis wget https://download.redis.io/releases/redis-6.0.9.tar.gz # 解压 redis tar -zxvf redis-6.0.9.tar.gz # 安装 gcc 环境， 安装过 忽略 yum -y install gcc-c++ cd redis-5.0.5 # 安装 make && make install
# 拷贝 utils 目录下的 redis_init_script 到 /etc/init.d 目录下 redis_init_script 是启动脚本
cp utils/redis_init_script /etc/init.d
cd /etc/init.d
vim /etc/init.d/redis_init_script
# ----------------- redis_init_script start ---------------
#!/bin/sh
#
# Simple Redis init.d script conceived to work on Linux systems
# as it does use of the /proc filesystem.
### BEGIN INIT INFO
# Provides: redis_6379
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Redis data structure server
# Description: Redis data structure server. See https://redis.io
### END INIT INFO
# redis 默认端口
REDISPORT=6379
# redis 默认启动 redis-server 位置
EXEC=/usr/local/bin/redis-server
# redis redis-cli 位置
CLIEXEC=/usr/local/bin/redis-cli
# redis pid 位置 拼接了默认端口参数。
PIDFILE=/var/run/redis_${REDISPORT}.pid
# redis 默认配置的conf 配置文件
CONF="/usr/local/redis/conf/redis.conf"
# $1 参数 为 start 或者 stop
case "$1" in
start)
if [ -f $PIDFILE ]
then
echo "$PIDFILE exists, process is already running or crashed"
else
echo "Starting Redis server..."
$EXEC $CONF
fi
;;
stop)
if [ ! -f $PIDFILE ]
then
echo "$PIDFILE does not exist, process is not running"
else
PID=$(cat $PIDFILE)
echo "Stopping ..."
$CLIEXEC -p $REDISPORT shutdown
while [ -x /proc/${PID} ]
do
echo "Waiting for Redis to shutdown ..."
sleep 1
done
echo "Redis stopped"
fi
;;
*)
echo "Please use start or stop as first argument"
;;
esac
# ----------------- redis_init_script end ---------------
# 保存之后启动redis
./redis_init_script start
# 停止 redis
./redis_init_script stop# 在以下位置加上一段注释 #!/bin/sh # # Simple Redis init.d script conceived to work on Linux systems # as it does use of the /proc filesystem. ### BEGIN INIT INFO # Provides: redis_6379 # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Redis data structure server # Description: Redis data structure server. See https://redis.io ### END INIT INFO #chkconfig: 22345 10 90 #desccription: Start and Stop redis :wq! # 保存 # 注册redis 到开机自启动 chkconfig redis_init_script on
# 设置后台运行 yes 后台运行， no 前台运行 daemonize yes # pidfile pid 目录文件 pidfile /var/run/redis_6379.pid # dir redis 的工作空间。必须写一个目录。不能写一个文件名 dir /usr/local/redis/working # bind 哪些ip地址可以访问 redis-server 0.0.0.0 任何地址都可以访问 bind 0.0.0.0 # requirepass 设置 redis 链接密码 requirepass 584521
引入依赖
org.springframework.boot spring-boot-starter-data-redis
配置 redis
spring: redis: database: 0 # 数据库 host: 127.0.0.1 # redis 地址 port: 6379 # redis 端口 password: 584521 # redis 密码
接口测试
@ApiIgnore
@RestController
@RequestMapping("redis")
public class RedisController {
@Autowired
private RedisTemplate redisTemplate;
@GetMapping("/set")
public Object set(String key, String value) {
redisTemplate.opsForValue().set(key, value);
return "ok";
}
@GetMapping("get")
public Object get(String key) {
Object value = redisTemplate.opsForValue().get(key);
return value;
}
@GetMapping("delete")
public Object delete(String key) {
redisTemplate.delete(key);
return "ok";
}
}redis 默认使用的 JDK 的序列化机制
每隔一段时间，把内存中的数据写入到磁盘的临时文件，作为快照。恢复的时候把快照文件读进内存。如果 redis 宕机重启，那么内存中的数据肯定会没有的。 重启 redis 时。从 RDB 文件中读取恢复数据
# 打开 redis.conf 文件 vim redis.conf # redis 工作空间 dir /usr/local/redis/working # rdb 持久化文件名 dbfilename dump.rdb # save 保存到硬盘。多少时间内发生了多少次改变 save 900 1 save 300 10 save 60 10000 # stop-writes-on-bgsave-error 保存时，发生错误停止写入操作 stop-writes-on-bgsave-error yes # rdbcompression 压缩 rdb 文件 如果像节省cpu性能开销。 就可以关闭 no rdbcompression yes # rdbchecksum 压缩 rdb 文件以后。 是否要检验 rdb 文件。 会有百分之 10 的性能损耗 rdbchecksum yes
RDB 优点
全量备份
可以远程传输
子进程备份时，主进程不会有IO操作。
RDB 缺点
rdb 持久化会有一个触发机制。如果最后的数据没有还没有触发保存。那么就有可能会导致 redis 宕机重启后，导致数据不一致
Redis 默认使用的是RDB模式作为持久化操作
关于 AOF 的配置名称
# 选择是否开启 aof appendonly yes # appendfilename 配置 aof 持久化文件的名称 appendfilename "appendonly.aof" # appendfsync aof 文件的同步策略。 always 针对每一次的写操作。 资源占用比较大。， erverysec 每秒同步一次 no 永不同步 appendfsync everysec # no-appendfsync-on-rewrite 重写的时候可以不做同步。 如果是yes 有可能会导致文件内容的不一致性 bi-appendfsync-on-rewrite no # auto-aof-rewrite-percentage 100 aof 文件增长比例，指当前 aof 文件比上次重写的增长比例大小。 aof 重写即在 aof 文件在一定大小之后，重新将整个内存写道 aof 文件当中，以反应最新得状态 这样就避免了文件过大而实际内存数据小的问题。 (频繁修改问题) auto-aof-rewrite-percentage 100 # auto-aof-rewrite-min-size 64mb aof 文件重写最小得文件大小。即最开始 aof 文件必须要达到这个文件时才触发，后面的每次重写就不会根据这个变量了， 根据上一次重写完成之后的大小。 此变量仅仅只有初始化启动 redis 时有效，如果是 redis 恢复时， 则 lastSize 等于初始 aof 文件大小。 auto-aof-rewrite-min-size 64mb # aof-load-truncated 指redis在恢复时，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能存在指令写错的问题(突然断电，写了一半)，这种情况下，yes会log并继续，而no会直接恢复失败. aof-load-truncated yes
不小心使用了 flushdb , flushall 。 我们可以停止 redis-server, 打开 aof 文件。 将 flushdb flushall 这种命令直接删除。重启 redis 服务
RDB 和 AOF 可以同时使用， 加载顺序，先加载 AOF 再加载 RDB
原来的单个Redis作为一个主 (Master)，多个从 (Slave) 。读写分离架构。 主作为写库， 从作为读库，也就是说写操作操作 Mater， 大多数读操作用 Slave 。Slave 会对 Mater 做一个全量复制的数据。
Master 先启动，随后启动 Slave ， 然后 Slave 会去 ping Master 节点，ping 通知后。 Master 会将数据提交给 Slave。Master 的数据复制是全量复制。
Master 会从内存中拷贝所有的 数据生成RDB文件。然后通过网络传输给我们的 Slave 节点。
Slave 拿到 RDB 文件后，会先下载到自己的硬盘中，然后再加载到 Slave 中。 这只是一个第一次启动时的操作
后续操作 Master 会直接传输给 Slave 节点。 传输操作并不会阻塞写操作
配置 一主二从机制，需要先准备三台Redis 机器 一台主，两台从
# 启动 Redis-cli redis-cli # 查看 Redis 角色信息 info replication # Replication role:master # 当前 redis 角色 connected_slaves:0 # 当前 redis 连接数量 master_replid:9d6bd1e0965ba650aed518034318a11c243c2d8c master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0
# replicaof主库 ip , 主库 端口号 replicaof 192.168.1.191 6379 # masterauth 主库 redis 密码 masterauth 584521 # replica-read-only yes 配置从主只能够读 不能写数据 replica-read-only yes # 停止 redis 服务 ./redis_init_script stop # 删除 dump.rdb 和 aof 文件 rm -rf dump.rdb *.aof # 启动 redis 服务 ./redis_init_script start
# replicaof主库 ip , 主库 端口号 replicaof 192.168.1.191 6379 # masterauth 主库 redis 密码 masterauth 584521 # replica-read-only yes 配置从主只能够读 不能写数据 replica-read-only yes # 停止 redis 服务 ./redis_init_script stop # 删除 dump.rdb 和 aof 文件 rm -rf dump.rdb *.aof # 启动 redis 服务 ./redis_init_script start
Disk-backed : Redis 会创建一个进程。 会写入一个文件到硬盘，然后将硬盘传输到 Redis Slave 节点上。
Diskless: Redis 会创建一个进程，会将 RDB 文件写入到 socket 连接中，不会接触到磁盘。 可以通过 socket 传输. Redis 会在 Slave 都连接上的一段时间后， 然后将 socket 传输到 多个 Slave 节点上。
全部启动成功之后，通过 info replication 命令查看各个 Redis 的角色状态。
无磁盘化复制
# 当磁盘很慢，但是网络环境又很不错。 那么就可以使用无磁盘化传输 repl-diskless-sync no # 配置 slave 连接上多久后，才开始通过 socket 传输。 repl-diskless-sync-delay 5
配置 从 Redis Slave 第二台
配置 从 Redis ， Slave 第一台
主 Redis Master
主动定时删除
# 每秒钟检查 10 次 hz 10
定时随机的检查过期的key，如果过期则清理删除。（每秒检查次数在redis.conf中的hz配置）
被动惰性删除
当客户端请求一个已经过期的key的时候，那么redis会检查这个key是否过期，如果过期了，则删除，然后返回一个nil。这种策略 友好，不会有太多的损耗，但是内存占用会比较高。
Redis 内存满了怎么办
# maxmemory配置redis 一共能占用多少内存 单位 byte maxmemory 2048
如果一个数据在最近一段时间很少被访问到，那么可以认为在将来它被访问的可能性也很小。因此，当空间满时，最小频率访问的数据最先被淘汰。
如果一个数据在最近一段时间没有被访问到，那么可以认为在将来它被访问的可能性也很小。因此，当空间满时，最久没有访问的数据最先被置换（淘汰）。
LRU（The Least Recently Used，最近最久未使用算法）是一种常见的缓存算法，在很多分布式缓存系统（如Redis, Memcached）中都有广泛使用。
LFU（Least Frequently Used ，最近最少使用算法）也是一种常见的缓存算法。
Redis 提供了以下多种淘汰机制
# volatile-lru -> Evict using approximated LRU among the keys with an expire set. # allkeys-lru -> Evict any key using approximated LRU. # volatile-lfu -> Evict using approximated LFU among the keys with an expire set. # allkeys-lfu -> Evict any key using approximated LFU. # volatile-random -> Remove a random key among the ones with an expire set. # allkeys-random -> Remove a random key, any key. # volatile-ttl -> Remove the key with the nearest expire time (minor TTL) # noeviction -> Don't evict anything, just return an error on write operations.
maxmemory 内存达到多少的时候。表示内存已经满了
原来一主二从里面， Master 节点一旦宕机。 我们就无法写入数据了。因为主节点宕机。从节点无法写入数据。只可以读取数据。
配置 Redis 压缩包中的 sentinel.conf 文件
# 开启保护模式后 绑定 ip 哪个 ip 才能够连接 # bind 127.0.0.1 # yes 开启绑定模式 ，。 no 不开启 protected-mode no # 端口号 port 26379 # daemonize 是否开启后台 daemonize yes # pid 文件位置。 和 redis 不是同一个进程 pidfile /var/run/redis-sentinel.pid # 配置 sentinel 的日志文件 logfile /usr/local/redis/logs/sentinel/redis-sentinel.log # dir sentinel 的工作空间 dir /usr/local/redis/sentinel # sentinel monitor配置监听的 master 名称、 以及 ip 地址， 端口号。 sentinel monitor xh-master 192.168.1.191 6379 2 # sentinel auth-pass mymaster MySUPER--secret-0123passw0rd sentinel auth-pass xh-master 584521 # sentinel down-after-milliseconds master 名称。 哨兵认为master 失败的时间段 sentinel down-after-milliseconds xh-master 10000 # sentinel parallel-syncs master 名称 以及同时需要同步几个 slave 节点的数据。 sentinel parallel-syncs xh-master 1 # sentinel failover-timeout master 名称。 故障转移超时时间。 sentinel failover-timeout xh-master 180000
下面可以直接将 sentinel 直接复制到其他两台 Redis 节点上
scp ./sentinel.conf root@192.168.1.192:/usr/local/redis/ scp ./sentinel.conf root@192.168.1.193:/usr/local/redis/
启动 Redis-sentinel 哨兵
# 启动时会报一个错误 redis-sentinel # 说 Sentinel 没有指定配置文件 6031:X 08 Nov 21:12:20.727 # Sentinel started without a config file. Exiting... # 指定配置文件启动 redis-sentinel /usr/local/redis/sentinel.conf 安装此方式启动 slave 1 和 slave 2
启动完成后， 当我们手动停止掉 redis-server 服务后。redis 哨兵，会在剩余的两个 slave 节点中。选举出一个 master 节点。
当原来的master 节点重新启动之后， master 并不是master 节点了。已经转变为 slave 节点了。可以通过 info replication
4-4 解决原Master恢复后不同步问题 在本节课中，相信细心的同学会发现原来的Master（191）恢复成Slave后，他的同步状态不OK，状态为 master_link_status:down ，这是为什么呢？ 这是因为我们只设置了192和193的 masterauth ，这是用于同步master的数据，但是191一开始是master是不受影响的，当master转变为slave后，由于他没有 auth ，所以他不能从新的master同步数据，随之导致 info replication 的时候，同步状态为 down ，所以只需要修改 redis.conf 中的 masterauth 为 584521 一般master数据无法同步给slave的方案检查为如下： 1. 网络通信问题，要保证互相ping通，内网互通。 2. 关闭防火墙，对应的端口开发（虚拟机中建议永久关闭防火墙，云服务器的话需要保证内网互通）。 3. 统一所有的密码，不要漏了某个节点没有设置。 # 查看xh-master下的master节点信息 sentinel master xh-master # 查看xh-master下的slaves节点信息 sentinel slaves xh-master # 查看xh-master下的哨兵节点信息 sentinel sentinels xh-master
配置 ymal 文件
spring: redis: database: 1 password: 584521 sentinel: master: xh-master # 配置 master 的名称 nodes: 192.168.1.191:26379,192.168.1.192:26379,192.168.1.193:26379 # 配置 redis 哨兵的 端口号以及 ip
是单个master容量有限，数据达到一定程度会有瓶颈，这个时候可以通过水平扩展为多master 集群。
redis-cluster：他可以支撑多个master-slave，支持海量数据，实现高可用与高并发。 哨兵模式其实也是一种集群，他能够提高读请求的并发，但是容错方面可能会有一些问题，比如master同步数据给slave的时候，这其实是异步复制吧，这个时候 了，那么slave上的数据就没有master新，数据同步需要时间的，1-2秒的数据会丢失。master恢复并转换成slave后，新数据则丢失。
每个节点知道彼此之间的关系，也会知道自己的角色，当然他们也会知道自己存在与一个集群环境中，他们彼此之间可以交互和通信， ong。那么这些关系都会保存到某个配置文件中，每个节点都有，这个我们在搭建的时候会做配置的。
客户端要和集群建立连接的话，只需要和其中一个建立关系就行。
某个节点挂了，也是通过超过半数的节点来进行的检测，客观下线后主从切换，和我们之前在哨兵模式中提到的是一个道理。
Redis中存在很多的插槽，又可以称之为槽节点，用于存储数据，这个先不管，后面再说。
修改 201 节点下 Redis 配置文件
# 开启 cluster 集群 yes 开启， no 关闭 cluster-enabled yes # cluster-config-file nodes-6379.conf cluster-config-file cluster 节点配置文件 cluster-config-file nodes-6379.conf # cluster-node-timeout 15000 配置 redis-cluster 超时时间 cluster-node-timeout 1500 # 开启 aof 持久化 appendonly yes # 修改万配置文件后。删除 aof 和 rbd 文件 如果不删除可能就会报错 rm -rf *.aof rm -rf *.rdb # 停止 redis /etc/init.d/redis_init_script stop # 启动 redis /etc/init.d/redis_init_script start
重复操作 202， 203， 204， 205， 206
通过 redis-cli 创建 cluster 集群
# 如果设置密码了记得设置密码 redis-cli -a 584521 --cluster create 192.168.1.201:6379 192.168.1.202:6379 192.168.1.203:6379 192.168.1.204:6379 192.168.1.205:6379 192.168.1.206:6379 --cluster-replicas 1
以上就是 三主三从的关系了。 M 为 master . S 为 Slave 。 205 分配到 201 ， 206 分配到 202 。 204 分配到 203
# 上面最后会询问你是否要配置该集群了 Can I set the above configuration? (type 'yes' to accept) ： yes
检查 cluster 集群信息
redis-cli -a 584521 --cluster check 192.168.1.201:6379
一共是有 16384 个槽节点分配
[OK] All 16384 slots covered
如何分配的槽节点呢
将 16384 平均分配给三个Master
槽 slot 如何存储
redis 会对每个存储的数据的 key 进行一个 hash 然后对 16384 取模 , 计算公式 hash(key) % 16384
进入到集群的控制台
# 查看集群的信息 redis-cli-c -a 584521 -h 192.168.1.202 -p6379 # 查看节点的信息 cluster nodes
配置 yaml 文件
spring: redis: password: 584521 cluster: nodes: 192.168.1.201:6379 192.168.1.202:6379 192.168.1.203:6379 192.168.1.204:6379 192.168.1.205:6379 192.168.1.206:6379
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，比如说发起一个 id 为 ‘-1’ 的数据， 或者 id 特别大 又不存在的数据。 这时因为缓存中没有数据，就会导致每一次的请求都会落在数据库上。导致数据库压力过大。
接口层增加校验，如用户鉴权校验，对请求参数做逻辑校验
从缓存中取不到的数据，在数据库中也取不到的数据。 这个时候也可以写入到缓存中。k - null 的方式。 缓存有效期设置短点。 如果设置的过长，就会导致正常情况无法使用。
缓存击穿是指缓存中没有，但是数据库中有的数据，一般是 缓存时间到期，这个时候由于并发用户过多， 同时缓存没有读到数据，导致请求全部落在数据库中，造成数据库压力过大。
设置热点数据永不过期
加锁去读。对 key 加锁。 当缓存中拿不到数据的时候。放开一个线程去数据库中去读数据。
缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是， 缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
如果缓存数据库是分布式部署，将热点数据均匀分布在不同缓存数据库中。
设置热点数据永远不过期。
到此，关于“Redis安装配置及整合SpringBoot的方法”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
