Linux版redis安装与集群配置

曾经终败给现在 2024-03-23 11:51 48阅读 0赞

### 一、安装Linux版redis ###

#### 1、安装及测试 ####

1：安装wget 环境

yum -y install wget

2：上传redis 压缩包

3：执行命令（安装c语言环境）

yum install gcc

4: 解压后进入redis 根目录执行make编译

make

4: 编译成功后 输入：make install

make install

5: 启动redis（进入redis 目录里的src 中执行下面命令） 使用redis.conf 文件启动

./redis-server ../redis.conf

### 二、Redis持久化 ###

redis是一个内存数据库，当redis服务器重启，获取电脑重启，数据会丢失，我们可以将redis内存中的数据持久化保存到硬盘的文件中。

redis提供两种持久化方式:

RDB：快照，通过从服务器保存和持久化

AOF：日志，操作生成相关日志,并通过日志来恢复数据。couchDB对于数据内容,不修改,只追加,则文件本身就是日志,不会丢失数据.

#### 1、RDB全称redis database backup file(redis 数据备份文件)持久化 ####

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里,Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

注：fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程，在每次redis服务器启动的时候，会自动把dump.rdb这个文件的键值对 全部读取到内存

![在这里插入图片描述][453616955b1a4f0bbf450afe38afdf1a.jpeg]

编辑redis.conf配置文件

RDB快照相关参数：
    	save 900 1    #刷新快照到硬盘中，必须满足两者要求才会触发，即900秒之后至少1个关键字发生变化。
    	save 300 10  #必须是300秒之后至少10个关键字发生变化。
    	save 60 10000 #必须是60秒之后至少10000个关键字发生变化。
    	上面三个参数屏闭后，rdb方式就关闭了
    	
    	stop-writes-on-bgsave-error yes    #后台存储错误停止写。
    	rdbcompression yes    #使用LZF压缩rdb文件。
    	rdbchecksum yes    #存储和加载rdb文件时校验。
    	dbfilename dump.rdb    #设置rdb文件名。
    	dir ./    #设置工作目录，rdb文件会写入该目录。

![在这里插入图片描述][774fbf23b72d45358f0e18fc14ac15d2.png]

![edb80ad72134445887da321974df2fe7.png][]

#### 2、AOF日志持久化 ####

config set appendonly yes
    或者进入redis.conf 修改 appendonly = yes 默认是no

AOF日志原理

![在这里插入图片描述][60067b9a72674c78bfb26cb3805a6da8.png]

思想：内存每写一条，就备份一条，时间间隔是1秒钟，缺点：文件大，写操作频繁。

*  以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
 *  只许追加文件但不可以改写文件，redis启动之初会读取该文件(aof文件)重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
 *  aof保存的是appendonly.aof文件

AOF日志相关参数:
    	appendonly no # 是否打开aof日志功能  no:不开启   yes:开启日志
    	appendfsync always   # 每1个命令,都立即同步到aof. 安全,速度慢
    				everysec # 折衷方案,每秒写1次
    				no      # 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快
    	no-appendfsync-on-rewrite  no # 正在导出rdb快照的过程中,要不要停止同步aof

配置开启AOF日志

![在这里插入图片描述][c2c151777dea4b3ea3502744d9149c39.png]

配置存储方案

![在这里插入图片描述][7d83fb4fa37148aa8f8a4acf098c9ca0.png]

#### 3、AOF重写 ####

思考：如果对同一个key进行多次操作，在aof日志中怎样表现操作记录，一条还是n条？

案例 ：创建age并改变五次值

![在这里插入图片描述][5cb03e7944ff411892d53006e5d965a8.png]

![在这里插入图片描述][60088aeb1dd0452ebf6794bd3d52d8d6.png]

日志会将每一步操作都记录，如果要对一个key操作多次，在数据上的表现只有一个但在日志中会有n条记录。当数据丢失需要找回数据的时候怎样找到正确的值？

aof重写是将内存中的key和value逆化为redis命令重新保存到日志中，就好像是将所执行的操作做的总结。

aof重写相关参数:
    	no-appendfsync-on-rewrite  no # 正在导出rdb快照的过程中,要不要停止同步aof
    	auto-aof-rewrite-percentage 100 #aof文件大小比起上次重写时的大小,增长率100%时,重写
    	auto-aof-rewrite-min-size 64mb #aof文件,至少超过64M时,重写

![624e22e437004bad8f6dfe23ba288b8f.png][]

问: 在dump rdb过程中,aof如果停止同步,会不会丢失?

答: 不会,所有的操作缓存在内存的队列里, dump完成后,统一操作.

问: aof重写是指什么?

答: aof重写是指把内存中的数据,逆化成命令,写入到.aof日志里.以解决 aof日志过大的问题.

问: 如果rdb文件,和aof文件都存在,优先用谁来恢复数据?

答: aof

问: 2种是否可以同时用?

答: 可以,而且推荐这么做

问: 恢复时rdb和aof哪个恢复的快

答: rdb快,因为其是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行

问题思考:在使用rdb做持久化时，我们关掉了redis服务，然后重新打开，保存的数据还在。但在做aof的时候我们将redis服务关闭后再打开数据就没有了。在上面不是配置过rdb持久化吗，为什么没起作用?
    答：当rdb中有数据，并开启了AOF选项，重启redis服务后会产生一个空的aof文件，当rdb和aof文件都存在，会以aof文件来恢复数据。

### 三、Redis消息发布定阅 ###

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

Redis 客户端可以订阅任意数量的频道。

![在这里插入图片描述][4dd24954d2e44025bb6cb20e2bd4afc9.png]

案例：创建消息定阅端

./redis-cli --raw   --打开redis客户端
    SUBSCRIBE woniu     --订阅蜗牛频道信息

案例：创建消息发布端

PUBLISH woniu '你好'  --发布 ”你好“ 信息

### 四、redis 集群配置 ###

#### 1、redis主从复制(Master/Slave) ####

##### a、集群结构 #####

![b2fb070c87424a238af19b1daf5c34bd.jpeg][]

三个节点：一个主节点，二个从节点

##### b、准备实例和配置 #####

在虚拟机开启3个redis 实例，来模拟主从集群模式，信息如下：

<table> 
 <thead> 
  <tr> 
   <th>ip</th> 
   <th>post</th> 
   <th>角色</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>127.0.0.1</td> 
   <td>7001</td> 
   <td>master</td> 
  </tr> 
  <tr> 
   <td>127.0.0.1</td> 
   <td>7002</td> 
   <td>slave</td> 
  </tr> 
  <tr> 
   <td>127.0.0.1</td> 
   <td>7003</td> 
   <td>slave</td> 
  </tr> 
 </tbody> 
</table>

1，在redis 目录下建三个文件夹：

![dc409ba9edd240fb872b1a97c9be209d.jpeg][]

2，把redis.conf 分别复制到三个文件夹中：

cp /redis/redis-6.0.6/redis.conf /redis/7001
     cp /redis/redis-6.0.6/redis.conf /redis/7002
     cp /redis/redis-6.0.6/redis.conf /redis/7003

3，修改文件中端口，RDB文件存放位子，redis实例声明的IP

例如7001实例：

dir ../../7001
    port 7001

4，启动三个服务进入src 目录下

例如启动7001实例：

./redis-server ../../7001/redis.conf

5，连接redis客户端

例如连接7001实例：

./redis-cli -p 7001

#### c、开启主从关系 ####

通过命令建立主从关系:

例如连接7002客户端，执行命令，7002 就成了7001的从节点

redis-cli -p 7002 快速的打开某个端口的客户端

SLAVEOF 127.0.0.1 7001

##### d、验证主从关系 #####

进入7001 的客户端输入命令

info replication

主从同步原理

![eb579055baa3463eaab35a47ec63fdf4.jpeg][]

原理：从节点第一次发送请求带上自己的replid 和offset ,主节点判断和自己的replid 是否一致，传给从节点replid 和offset，从节点保存版本信息，主节点执行bgsave 生成RDB 文件，并同步给从节点，从节点加载RDB文件实现数据同步，这时如果主节点发生修改操作，会生成一个repl-baklog 日志。

#### 2、哨兵模式(sentinel) ####

万一主节点宕机了怎么办？

监控：sentinel不断的检查您的master和slave 是否按预期执行

自动故障恢复：如果master故障，sentinel会将一个slave提升为master，当故障实例恢复后也以新的master为主

通知：sentinel充当redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给redis客户端

sentinel服务状态检测，每隔一秒向集群每个实例发送ping 命令

主观下线：如果某个sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线

客观下线：若超过执行数量（quornum）的sentinel都认为该实例下线，则该实例客观下线，（quornum数最好超过实例总数一半）

<table> 
 <thead> 
  <tr> 
   <th>ip</th> 
   <th>post</th> 
   <th>角色</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>127.0.0.1</td> 
   <td>27001</td> 
   <td>master</td> 
  </tr> 
  <tr> 
   <td>127.0.0.1</td> 
   <td>27002</td> 
   <td>slave</td> 
  </tr> 
  <tr> 
   <td>127.0.0.1</td> 
   <td>27003</td> 
   <td>slave</td> 
  </tr> 
 </tbody> 
</table>

1，在redis 目录下建三个文件夹：

![在这里插入图片描述][e29932aceac54a548609504af27ad173.jpeg]

2，新建文件sentinel.conf

以27001为例：

port 27001
    sentinel monitor mymaster 127.0.0.1 7001 2
    sentinel down-after-milliseconds mymaster 50000
    sentinel failover-timeout mymaster 180000
    dir "/ding/s1"

3，启动,进入src 目录

redis-sentinel ../../s1/sentinel.conf

[453616955b1a4f0bbf450afe38afdf1a.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/0c667cfb91bc4487b6dbc167f2dcdc2e.png
[774fbf23b72d45358f0e18fc14ac15d2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/49ea1b79db1f48569e9baabe8204b56c.png
[edb80ad72134445887da321974df2fe7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/306c4cbddb754deba408d0b2cf73c7ce.png
[60067b9a72674c78bfb26cb3805a6da8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/ed5f9b35cb174a34bd3ed2b1d050c4ed.png
[c2c151777dea4b3ea3502744d9149c39.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/e228d8c1531d4a80a5ad46ed41fee321.png
[7d83fb4fa37148aa8f8a4acf098c9ca0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/c63c200b55354fc2b04c33aea1564257.png
[5cb03e7944ff411892d53006e5d965a8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/b814e15fb3924f13a3144a88f2ebd342.png
[60088aeb1dd0452ebf6794bd3d52d8d6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/c34f59b81b1b4bc6be250cdb60794ac6.png
[624e22e437004bad8f6dfe23ba288b8f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/dc8ac9e2ba6f46d899afb0a44a171789.png
[4dd24954d2e44025bb6cb20e2bd4afc9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/c569d39b437b48e9b7ede348ceac8a78.png
[b2fb070c87424a238af19b1daf5c34bd.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/be191b395a604f9894fede168d887061.png
[dc409ba9edd240fb872b1a97c9be209d.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/3cf261416bbf40ab9b8febc17aa4b48c.png
[eb579055baa3463eaab35a47ec63fdf4.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/1c4bcf1fa3fe4e73b3deb27f3414c4da.png
[e29932aceac54a548609504af27ad173.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/b4faeda4989a4a4ebfe90d60735c46eb.png