spring data redis lettuce 配置 spring-data-redis原理

目录

Redis概念        

Redis作用

Redis支持的数据类型

Redis操作数据的命令

Redis持久化策略

Redis主从复制模式

 Redis哨兵模式

        哨兵机制的原理：

        故障转移步骤

         Redis哨兵模式安装部署

      哨兵机制的优点：

---

Redis概念        

        Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存也可以持久化的Key-Value数据库。

Redis作用

        Redis在企业开发中通常充当高速缓存的作用，用于保护接口或者数据库。在高并发场景、分布式场景下也可以充当分布式锁，避免多个JVM进程在同一时间对同一资源进行修改，从而造成数据不一致。

Redis安装

下载地址：https://redis.io/download

1.通过远程管理工具，将压缩包拷贝到Linux服务器中，执行解压操作

       tar -zxf redis-4.0.9.tar.gz

2.进入解压文件目录使用make对解压的Redis文件进行编译:

       make

3. 解压后的Redis目录下包含Redis核心配置文件redis.conf。因为Redis默认并不是在后台运行的，要将Redis进程改为在后台运行，则要修改redis.conf中的配置项daemonize，该配置项默认值为no，要将其修改为yes .再使用下面的命令启动Redis服务器端：  

.redis-server /usr/local/redis/etc/redis.conf     

4、为了验证Redis服务启动正常，可以执行以下命令查看：

ps -ef|grep redis

或者

        Redis安装文件中含有服务端启动程序，也有客户端程序redis-cli，可以通过Redis客户端连接到Redis服务器端，来验证Redis服务是否正常启动。客户端启动命令如下：

        src/redis-cli

        Redis客户端成功与Redis服务器端连接上，证明Redis服务启动正常。

Redis支持的数据类型

• String：一个key对应一个value
• hash
• List
• Set
• Sorted Sort：有序数据集合，每个元素都会关联一个double类型的分数，Redis通过分数对集合中成员进行从小到大的排序。

Redis操作数据的命令

• String的使用方式

        SETNX key value ：原子操作，先获取key值，如果key值不存在就设置key值，否则，不执行任何操作。

• Sorted Set的使用方式

        与Set一样存储多个元素，且不存在重复元素，不同的是，Sorted Set中的每一个元素会关联一个分数，Redis通过这个分数为依据进行排序。

        ZADD key score1 member1 向集合key中添加分数为score1的member1。

        ZCARD key 获取集合key中所有元素的个数。

        ZRANGE key start top 返回key集合中索引为start到top的元素

        ZRANK key member 返回集合key中指定成员member的索引值。

        ZREM key member 删除有序集合中的一个或多个成员。

Redis持久化策略

        在运行情况下，redis将数据维持在内存中，为了让这些数据在redis重启或死机之后仍然可用，redis有两种持久化模式：RDB（Redis Database）和AOF(Append Only File)。

        RDB：在redis运行时，RDB程序将当前内存中的数据库快照保存在磁盘文件中，在redis重新启动时，RDB程序可通过载入RDB文件来还原Redis中的数据。在指定的时间间隔内，执行指定次数的写操作，将Redis内存中数据写入磁盘，生成一个dump.rdb文件。当redis重新启动时，读取该文件，将磁盘中数据恢复到内存中。打开redis目录下的redis.conf配置文件，SNAPSHOTTING的相关配置项，是配置持久化规则的：

        save <指定时间间隔> <指定操作次数> 

       例如，save 900 1 表示在900s内 1次更改，就保存内存数据到磁盘。

        AOF：默认是不开启的。它是以日志的形式记录每个写操作，并追加到文件中。redis重启时，会根据日志文件的内容将保存的写操作执行一次，完成内存数据的恢复。打开redis目录下的redis.conf配置文件，找到APPEND ONLY MODE的相关配置项，修改为开启：

        appendonly yes

        appendfilename 配置项控制AOF持久化文件的名称。

        appendfsync always 每次发生变化会立刻写入磁盘中。

        appendfsync everysec 每秒异步记录一次。

        appendfsync no 不同步

Redis主从复制模式

        主从复制模式的特点：主节点负责接受写入数据的请求，从节点负责接受查询数据的请求，主节点定期把数据同步给从节点，以保证主从节点的数据一致性。

        搭建主从复制架构：

1. 创建Redis配置文件进入Redis目录，复制原redis.conf为redis6380.conf文件，操作如下：

  

 2. 修改配置文件在redis6380.conf中修改启动端口和主从关系，代码如下：

3. 启动Redis主从服务分别启动Redis主节点127.0.0.1 6379和从节点127.0.0.1 6380，验证主节点和从节点启动情况，如图所示。 

   

  

 4. 查看主从状态。登录Redis主节点，执行info replication命令，从图中可以看出当前节点是master节点：

 

登录Redis从节点，执行info replication命令，从图中可以看出当前节点是slave节点。 

5. Redis主节点写入操作。登录Redis主节点，执行写入操作。

#写入Hash master_slave中key-value对master ："127.0.0.1 6379"

#写入Hash master_slave中key-value对slave ："127.0.0.1 6380"

 6. 查询从节点查询同步状态登录从节点客户端，查询从节点同步状态

 

         从以上步骤看出，Redis从节点127.0.0.1 6380虽然没有发生写入操作，但执行查询可以发现，Redis主节点127.0.0.1 6379发生写入的操作已经同步到Redis从节点127.0.0.1 6380。Redis主从架构有多种不同的拓补结构，以下是一些常见的主从拓扑结构。

        Redis主从复制模式的拓扑结构:

1、一主一从拓扑结构：

        Redis一主一从拓扑结构主要用于主节点故障转移到从节点。当主节点的写入操作并发高且需要持久化时，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免了持久化对主节点性能的影响。

2、一主多从

        针对读取操作并发较高的场景，读取操作由多个从节点来分担；但节点越多，主节点同步到多节点的次数也越多，影响带宽，也对主节点的稳定性造成负担。

 3、树形拓扑结构

        一主多从拓扑结构的缺点是主节点推送次数多、压力大，可用树形拓扑结构解决，主节点只负责推送数据到从节点A，再由从节点A推送到B、C和D，可以减轻主节点推送的压力。

 

         Redis主从架构的缺点：

        主从复制架构虽然可以提交读并发，但这种方式也有缺点。

（1）主从复制架构中，如果主节点出现问题，则不能提供服务，需人工修改重新设置主节点。（2）主从复制架构中，主节点单机写能力有限。

 Redis哨兵模式

        Redis主从复制架构的缺点是当主节点master出现故障后，redis新的主节点必须由开发人员手动修改，因此在主从复制架构基础上，演变出了哨兵机制。

        哨兵机制的原理：

        当主节点出险故障时，由redis哨兵自动完成故障发现和转移，并通知redis客户端，实现高可用性。

        Redis哨兵进程是用于监控Redis集群中Master主服务器工作状态的。在主节点Master发生故障的时候，可以实现Master和Slave服务器的自动切换，保证系统的高可用性。Redis哨兵是一个分布式系统，可以在一个架构中运行多个Redis哨兵进程，这些进程使用流言协议（gossipprotocols）来接收关于Master主服务器是否下线的信息，并使用投票协议（Agreement Protocols）来决定是否执行自动故障迁移，以及选择某个Slave节点作为新的Master节点。

        每个Redis哨兵进程会向其他Redis哨兵、Master主节点、Slave从节点定时发送消息，以确认被监控的节点是否“存活着”。如果发现对方在指定配置时间（可配置的）内未得到回应，那么暂时认为被监控节点已死机，即所谓的“主观下线（Subjective Down，简称SDOWN）”。与“主观下线”对应的是“客观下线（Objectively Down，简称ODOWN）”。

        当“哨兵群”中的多数Redis哨兵进程在对Master主节点做出SDOWN的判断，并且通过SENTINEL is-master-down-by-addr命令互相交流之后，得出MasterServer的下线判断，此时认为主节点Master发生“客观下线”。通过一定的选举算法，从剩下的存活的从节点中选出一台晋升为Master主节点，然后自动修改相关配置，并开启故障转移（failover）。

        Redis哨兵虽然由一个单独的可执行文件redis-sentinel控制启动，但实际上Redis哨兵只是一个运行在特殊模式下的Redis服务器，可以在启动一个普通Redis服务器时通过指定sentinel选项来启动Redis哨兵，Redis哨兵的一些设计思路和Zookeeper非常类似。

         每隔1s每个Redis哨兵会向主节点、从节点及其余Redis哨兵节点发送一次ping命令做一次“心跳”检测，这也是Redis哨兵用来判断节点是否正常的重要依据

        故障转移步骤

 

         Redis哨兵模式安装部署

 1. 创建Redis主从节点配置文件进入Redis目录，将redis.conf文件复制3份，分别命名为redis6379.conf、redis6380.conf和redis6381.conf。

 2. 修改各个Redis配置文件。

        改redis6379.conf配置文件，配置启动端口为6379：port 6379

修改redis6380.conf配置文件，配置启动端口为6380，并配置此节点为127.0.0.16379的从节点。

对redis6381.conf做相同操作 。

3. 分别启动Redis主从节点分别启动Redis Master节点127.0.0.1 6379，Redis Slave节点127.0.0.1 6380和节点127.0.0.1 6381。

4. 创建Redis哨兵配置文件。进入Redis目录，将sentinel.conf配置文件复制3份，分别命名为sentinel26379.conf、sentinel26380.conf和sentinel26381.conf。

5. 修改Redis哨兵配置文件。修改sentinel26379.conf配置文件，配置启动端口为26379，并配置监听127.0.0.1 ：6379主节点。

 修改sentinel26380.conf配置文件，配置启动端口为26380，并配置监听127.0.0.1：6379主节点。

 修改sentinel26381.conf配置文件，配置启动端口为26381，并配置监听127.0.0.16379主节点。

 6. 分别启动Redis哨兵。

7、验证Redis哨兵启动：

8. 验证故障转移。停止Redis Master主节点127.0.0.1： 6379（命令 kill -9 进程号），用于模拟Redis主节点下线。3个Redis哨兵节点的日志输出：

      哨兵机制的优点：

        通过Redis哨兵实现的故障转移降低了开发人员对Redis的维护成本，同时也增强了Redis的高可用性。