Redis架构原理与集群演变

Redis持久化机制

Redis是一个KV的内存数据库，为了保证数据的持久性，它提供了三种持久化方案
- RDB方式（默认）
- AOF
- 混合持久化模式（4.0增加，5.0默认开启）

Redis的持久化方案

RDB方案

RDB是Redis默认采用的持久化方式
RDB方式是通过快照的方式完成数据的备份
当符合一条件时，Redis会自动将内存的数据快照并持久化到硬盘中

触发RDB快照的时机

符合配置文件配置的快照规则
执行save或者bgsave命令时
执行flushall
执行主从复制的操作时

RDB设置快照规则

在Redis的安装目录中有redis.conf的配置文件

save "" ：表示不适用RDB储存
save 900 1 ：表示15分钟内如果有1个键被更改则进行快照
save 30010 ：表示5分钟内如果有10个键被更改则进行快照
save 60 10000 ：表示1分钟内如果有10000个键被更改则进行快照

RDB快照实现原理

：当快照被触发时
：Redis主进程调用系统的fork函数复制一个当前进程的副本（子进程）
：Redis主进程继续响应请求，保持服务的可用
：被复制出来的子进程开始将内存中的数据写入到一个rdb的临时文件中
：当子进程写入完所有数据后，会用该临时文件覆盖替换旧的rdb文件，该子进程结束，一次快照完成

注意事项

Redis在快照期间不会修改原有RDB文件，而是新建一个RDB文件，将数据写入其中，当数据写完后，进行文件覆盖式替换
- 如果生成快照失败，就不会进行替换。保证了RDB文件随时都是完整可读的

RDB的优缺点

RDB方式持久化，因为子进程刷盘到覆盖原有文件是需要时间的，这段时间变更的数据无法持久化到当前持久化文件中
- 如果这个时候Redis异常退出，那么这次快照会失败且快照时变更的数据也会丢失
- 单单只是RDB，是无法保证数据的完成的，如果数据非常重要，就应该混合使用下面我们说到的AOF方式
RDB方式可以最大化Redis的性能，父进程什么也不需要做，只需要fork分叉出一个子进程来处理
- 如果次数数据集比较大，fork可能比较耗时，造成服务器在一段时间内停止处理客户端的请求

AOF方案

默认情况下，AOF是需要手动开启的
开启AOF持久化后，没执行一条变更数据的命令，Redis就会将该命令写入到磁盘中的AOF文件中去
因为涉及IO操作，会牺牲一点点Redis的性能，但是我们可以使用比较快的硬盘，降低这种损耗

AOF同步磁盘数据

Redis每次更改数据时候，aof机制都会将其命令记录在aof文件中
但是实际上，并没有保证实时性，由于操作系统的缓存机制，数据进入到硬盘的缓冲中，在通过硬盘缓存机制刷新到aof文件

always
- 每次执行写入都会进行同步，这个是最安全但是是效率比较低的方式
everysec （默认）
- 每一秒执行(默认)
no
- 不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式

AOF重写原理

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写。重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合
比如
- set k1 v1
- set k1 v2
- set k1 v3
- 重写优化后只有：set k1 v3
AOF文件有序的保存了对Redis执行的操作命令，这么数据，都是以Redis协议（REST）格式保存
- 因此AOF文件的内容容易理解，对文件进行解析也很轻松

RDB和AOF的选择（混合持久化方式）

Redis 4.0之前面临的抉择

Redis只是作为内存数据库：RDB + AOF 数据不会丢
Redis只是作为缓存服务器：RDB
不建议单单只使用AOF，文件过大，Redis重启非常慢
恢复时，Redis会限度去AOF文件，再读取RDB文件

Redis 4.0后无需考虑，默认：混合持久化方式

Redis 4.0 之后新增的方式，混合持久化是结合了 RDB 和 AOF 的优点
在写入的时候，先把当前的数据以 RDB 的形式写入文件的开头
再将后续的操作命令以 AOF 的格式存入文件
这样既能保证 Redis 重启时的速度，又能减低数据丢失的风险

混合持久化方式

RDB 可能会导致一定时间内的数据丢失
AOF 由于文件较大则会影响 Redis 的启动速度
为了能同时拥有 RDB 和 AOF 的优点，Redis 4.0 之后新增了混合持久化的方式

该方式在Redis 4.0 引入，默认关闭，在5.0默认开启
- 可通过该命令查看状态：config get aof-use-rdb-preamble

如果是在4.0到5.0之间的版本，有以下两种方式开启
- 通过命令开启，重启失效： config set aof-use-rdb-preamble yes
- 通过配置文件开启，永久有效：aof-use-rdb-preamble yes
  - 修改文件后，重启机器

多插一句：如果你的业务是有必须持久化的的需求，才开启持久化

如果持久化不是那么重要或者根本不需要，可以关闭持久化，将Redis的性能再度提升

Redis的的主从同步机制

持久化的方式保证Redis服务重启也不会丢失数据
- 将硬盘中的持久化文件读取到内存中
如果此时服务器硬盘坏了，持久化文件也没有了，如何保证数据不丢失呢？
- 主从复制

主从同步实现原理

Redis的主从同步，分为全量同步和增量同步
只有从机第一次链接主机的时候是全量同步
断线重连可能会触发全量同步，也有可能是增量同步（master判断runid是否一致）

全量同步三阶段

第一阶段：同步快照
- Master创建快照，并发送给从机slave,slave载入快照并解析快照将数据载入内存
  - 这一阶段可以是磁盘快照文件，（IO操作）
  - 也可以开启无磁盘数据同步，直接网络完成同步：repl-diskless-sync yes
- Master 同时将此阶段所产生的新的操作命令存储到缓冲区
第二阶段：同步写缓冲
- Master 向 Slave 同步存储在缓冲区的写操作命令，Slave载入缓冲区操作命令
第三阶段：同步增量
- Master 向 Slave 同步写操作命令

增量同步

Redis的增量同步主要是指Slave完成初始化同步已经开始正常时，Master发生的数据变更同步到Slave的过程
通常情况下Master每执行一个写命令就会向Slve发送相同的写命令，然后Slave接受并执行

主从配置（有个小故事）

主Master

无需额外配置

从Slave

修改redis.conf配置文件
- 4.0版本之前： slaveof masterIP 6379
- 4.0版本之后
  - slaveof masterIP 6379
- 4.0版本之后（随意更改一个即可）
  - slaveof masterIP 6379
  - replicaof masterIP 6379

可以看到Redis 4.0之后的Slave更改的配置变更多了一个，为什么呢？

多人要求修改Redis主从复制术语master/slave

Redis的Sentinel工作原理

哨兵(Sentinel)主要是为了解决在主从复制架构中出现宕机的情况,主要分为两种情况

从Redis宕机
- 这个相对而言比较简单,在Redis中从库重新启动后会自动加入到主从架构中,自动完成同步数据。
- 在Redis2.8版本后,主从断线后恢复的情况下实现增量复制
主Redis宕机
- 在从数据库中执行SLAVEOF NO ONE命令,断开主从关系并且提升为主库继续服务
- 将主库重新启动后,执行SLAVEOF命令,将其设置为其他库的从库,这时数据就能更新回来

假设我们现在是一主三从的架构，一个master，二个slave

Sentinel定时监控

Sentinel虽然明面上只配置了对Master的监控，但其实通过Master也在监控所有的Slave
- 每个哨兵10S/次向Master发送info命令，获取最新主从架构信息，监控所有节点
每个哨兵以2S/次的频率向Redis数据节点的指定频道发送数据相互了解架构信息
- 发送自己哨兵的状态信息（是否可用）
- 发送自己哨兵对Master状态的判定信息（是否可用）
- 其实就是通过消息publish和subscribe来完成的
每个哨兵以1S/次的频率向当前主节点、从节点、以及其余哨兵节点发送一个ping命令，这个是心跳检测
- 也是哨兵用来判断节点是否正常的重要依据

主观下线

又叫：sdown
- 就是单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）
- 通过1S/次的频率向当前主节点、从节点、以及其余哨兵节点发送一个ping命令
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度
如果超出时间长度还没有正确回复就认为主观下线

客观下线

又叫：odwon
当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-byaddr寻求其它哨兵节点对主节点的判断
- 如果其他的哨兵也认为主节点主观线下了
- 当认为主观下线的票数超过了quorum（选举）个数
- 大部分哨兵节点都同意下线操作，这样就客观下线了

Sentinel Leader选取流程

如果主节点被判定为客观下线之后，就要选取一个哨兵节点来完成后面的故障转移工作

选举出一个leader的流程如下：

第一个发现主节点下线的哨兵，会向其它哨兵发ismaster-down-by-addr命令，征求判断并要求将自己设置为领导者
只要超过哨兵集群节点数 / 2 + 1 的同意，就能成为哨兵Leader
然后哨兵Leader负责下面的故障转移，选举新的Redis主从Master

故障转移机制

在剩下可用的从节点中选择新的主节点
- sentinel状态数据结构中保存了主服务的所有从服务信息
- sentinel Leader按照如下的规则从从服务列表中挑选出新的主从Master
  - 过滤掉主观下线的节点
  - 选择slave-priority最高的节点，如果由则返回没有就继续选择 ,默认都是100，一般不做更改
  - 选择出复制偏移量最大的系节点
    - 因为复制偏移量越大则数据复制的越完整，如果由就返回了，没有就继续
  - 选择run_id最小的节点
更新主从状态
- 通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
- 当宕机的master恢复正常时，复制新的master节点，变成新的master的slave
- 同理，当已下线的slave服务重新上线时，sentinel会向其发送slaveof命令，让其成为新master的slave

哨兵进程的作用

监控( Monitoring ):
- 哨兵( sentinel ) 会不断地检查你的 Master 和 Slave 是否运作正常
提醒( Notification )：
- 当被监控的某个 Redis 节点出现问题时, 哨兵( sentinel ) 可以通过 API向管理员或者其他应用程序发送通知。
自动故障迁移( Automatic failover )：
- 当一个 Master 不能正常工作时，哨兵( sentinel ) 会开始一次自动故障迁移操作

Redis的集群框架&选择

目前Redis的集群选择最火热的就是 Redis自带的 Redis Cluster，其余都只做了解使用

主从复制

参考上面所说的主从复制笔记

Replication + Sentinel *高可用 (了解)

这套架构使用的是社区版本推出的原生高可用解决方案

工作原理

当Master宕机的时候，Sentinel会选举出新的Master，
并根据Sentinel中client-reconfig-script脚本配置的内容，去动态修改VIP(虚拟IP)，
将VIP(虚拟IP)指向新的Master。我们的客户端就连向指定的VIP即可
- 比如现在指向的是：192.168.217.150
- 如果192.168.217.150宕机，160当选Master,此时VIP指向192.168.217.160

缺陷

主从切换过程中会丢失数据
Redis只能单点写，不能水平扩容

Proxy + Replication + Sentinel (了解)

这里的proxy有两种选择：Codis（豌豆荚）和Twemproxy（推特）
- 这里以Twemproxy为例说明，如下图所示

工作原理

前端使用Twemproxy+KeepAlived做代理，将其后端的多台Redis实例分片进行统一管理与分配
每一个分片节点的Slave都是Master的副本且只读
Sentinel持续不断的监控每个分片节点的Master，
- 当Master出现故障且不可用状态时，Sentinel会通知/启动自动故障转移等动作
Sentinel 可以在发生故障转移动作后触发相应脚本（通过 client-reconfig-script 参数配置）
- 脚本获取到最新的Master来修改Twemproxy配置

缺点

部署结构超级复杂
可扩展性差，进行扩缩容需要手动干预
运维不方便

Redis Cluster(核心原理)

核心原理

所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽
节点的fail是通过集群中超过半数的节点检测失效时才生效
客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
redis-cluster把所有的物理节点映射到[0-16383]一共16384个插槽slot上,
- cluster 负责维护node<->slot<->value

插槽Slot

Redis 集群中内置了 16384个哈希槽
当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果
然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽
redis 会根据节点数量大致均等的将哈希槽映射到不同的节点
然后将该数据转发到包含了该哈希槽的节点上进行保存

Redis Cluster 投票

节点失效判断
- 如果半数以上master节点与其中一个master节点通信超过(cluster-node-timeout),认为该master节点挂掉.
集群失效判断：什么时候整个集群不可用？
- 如果集群任意master挂掉,且当前master没有slave
  - 这样导致插槽数据不完整，宕掉的master节点数据无法获取，则集群进入fail状态
- 如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态

Redis Cluster高可用集群搭建指南

服务器清单

此集群三主三从，一共六台服务器，对应的职责如下所示
- masert1 : 192.168.217.120
  - slave：192.168.217.150
- master2：192.168.217.130
  - slave：192.168.217.160
- master3：192.168.217.140
  - slave：192.168.217.170
所有服务器Redis阶段清空全部数据，搭建时不能有节点有数据
- flushdb

各服务器搭建Redis服务

下载Redis：wget http://download.redis.io/releases/redis-6.0.9.tar.gz
解压：tar -zxvf redis-6.0.9.tar.gz

下载Redis所需环境，下载并升级gcc

yum install gcc
yum -y install centos-release-scl
yum -y install devtoolset-9-gcc devtoolset-9-gcc-c++ devtoolset-9-binutils
scl enable devtoolset-9 bash

进入解压目录编译且安装：
- cd redis-6.0.9
- make
- make install
跳转到默认安装目录
- cd /usr/local/bin/
复制Redis的配置文件到/usr/local/bin/并修改
- 将解压得到的配置文件复制一份到/usr/local/bin/中，方便启动服务使用
- cp /ninja_install/redis-6.0.9/redis.conf ./
- vim ./redis.conf
  - #bind 127.0.0.1 ：注释掉外网可以访问
  - protected-mode no ： yes改为no，外网可以访问
  - daemonize yes ：no改成yes，后台运行
以配置文件方式启动redis服务,并连接
- ./redis-server ./redis.conf
- ./redis-cli
为Redis的客户端建立软连接，这样我们键入redis就如同使用了全路径的redis-cli
- ln -s /usr/local/bin/redis-cli /usr/bin/redis
- 同理，当然你也可以为redis-server创建软连接

修改配置搭建集群

修改作为master节点的Redis的配置文件，打开一下注释即可
- cluster-enabled yes
- cluster-config-file nodes-6379.conf
以配置文件的方式启动，重启所有Redis服务
在随意一台redis节点的机器上，执行以下命令
- ```
./redis-cli --cluster create 192.168.217.120:6379 192.168.217.130:6379 192.168.217.140:6379 192.168.217.150:6379 192.168.217.160:6379 192.168.217.170:6379 --cluster-replicas 1
```
  - ./redis-cli ：执行redis安装目录的客户端连接根据
  - --cluster ：集群标识
  - create ：创建标识
  - --cluster-replicas 1：副本数量
  - 中间一堆IP下面详说

上面一共涉及到6台机器的ip和port

因为我们设置的副本数量为1，所以这个集群每一个master都会有一个slave

所以，前三个ip是master,后三个ip分别是前三个master的slave

看上图左边橘色三个M,代表三个Master信息
- 红色标注的是16384个插槽的分布情况，分别分给了三个Master
看上图左边黄色三个S,代表三个Slave信息

查看Redis集群信息，使用客户端命令 redis-cli -c 登陆任意主从节点

查看集群状态：cluster info

查看集群中的节点：cluster nodes

Redis Cluster优缺对比

客户端与Redis节点直连,不需要中间Proxy层，直接连接任意一个Master节点
根据公式计算出映射到哪个分片上，然后Redis会去相应的节点进行操作
无需Sentinel哨兵监控，如果Master挂了，Redis Cluster内部自动将Slave切换Master
可以进行水平扩容
支持自动化迁移
- 当出现某个Slave宕机了，那么就只有Master了，
- 这时候的高可用性就无法很好的保证了，万一Master也宕机了，咋办呢？
- 针对这种情况，如果说其他Master有多余的Slave ，
- 集群自动把多余的Slave迁移到没有Slave的Master 中

批量操作是个坑
- 多键的命令操作（如MGET、MSET），如果每个键都位于同一个节点，则可以正常支持，否则会提示错误。
资源隔离性较差，容易出现相互影响的情况
- 集群中的节点只能使用0号数据库，如果执行SELECT切换数据库会提示错误

代码测试

可以发现：
- 我们在任意节点上操作数据
- 该节点可能不包含该key的插槽hash,也就是该数据并不在该服务器上
- 但是我们仍然可以操作数据，集群会帮我们转发该请求到包含该数据的服务器上

我们使用代码来测试一下,创建一个SpringBoot工程

依赖

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
    <!-- https://mvnrepository.com/artifact/redis.clients/jedis -->
    <dependency>
        <groupId>redis.clients</groupId>
        <artifactId>jedis</artifactId>
        <version>3.3.0</version>
    </dependency>
    <!-- https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind -->
    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
    </dependency>
    <!-- https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-core -->
    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-core</artifactId>
    </dependency>
</dependencies>

application.yml

server:
  port: 8080
spring:
  redis:
    cluster:
      nodes: 192.168.217.120:6379,192.168.217.130:6379,192.168.217.140:6379,192.168.217.150:6379,192.168.217.160:6379,192.168.217.170:6379
      max-redirects: 6

redisConnect:
  timeout: 10000   #客户端超时时间单位是毫秒 默认是2000
  maxIdle: 300     #最大空闲数
  maxTotal: 1000   #控制一个pool可分配多少个jedis实例,用来替换上面的redis.maxActive,如果是jedis 2.4以后用该属性
  maxWaitMillis: 1000    #最大建立连接等待时间。如果超过此时间将接到异常。设为-1表示无限制。
  minEvictableIdleTimeMillis: 300000   #连接的最小空闲时间 默认1800000毫秒(30分钟)
  numTestsPerEvictionRun: 1024         #每次释放连接的最大数目,默认3
  timeBetweenEvictionRunsMillis: 30000 #逐出扫描的时间间隔(毫秒) 如果为负数,则不运行逐出线程, 默认-1
  testOnBorrow: true     #是否在从池中取出连接前进行检验,如果检验失败,则从池中去除连接并尝试取出另一个
  testWhileIdle: true    #在空闲时检查有效性, 默认false
  password:              #密码

配置类

@Configuration
public class RedisClusterConfig {
    @Value("${spring.redis.cluster.nodes}")
    private String clusterNodes;
    @Value("${spring.redis.cluster.max-redirects}")
    private int maxRedirects;
    @Value("${redisConnect.password}")
    private String password;
    @Value("${redisConnect.timeout}")
    private int timeout;
    @Value("${redisConnect.maxIdle}")
    private int maxIdle;
    @Value("${redisConnect.maxTotal}")
    private int maxTotal;
    @Value("${redisConnect.maxWaitMillis}")
    private int maxWaitMillis;
    @Value("${redisConnect.minEvictableIdleTimeMillis}")
    private int minEvictableIdleTimeMillis;
    @Value("${redisConnect.numTestsPerEvictionRun}")
    private int numTestsPerEvictionRun;
    @Value("${redisConnect.timeBetweenEvictionRunsMillis}")
    private int timeBetweenEvictionRunsMillis;
    @Value("${redisConnect.testOnBorrow}")
    private boolean testOnBorrow;
    @Value("${redisConnect.testWhileIdle}")
    private boolean testWhileIdle;


    //Redis连接池的配置
    @Bean
    public JedisPoolConfig getJedisPoolConfig() {
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        // 最大空闲数
        jedisPoolConfig.setMaxIdle(maxIdle);
        // 连接池的最大数据库连接数
        jedisPoolConfig.setMaxTotal(maxTotal);
        // 最大建立连接等待时间
        jedisPoolConfig.setMaxWaitMillis(maxWaitMillis);
        // 逐出连接的最小空闲时间 默认1800000毫秒(30分钟)
        jedisPoolConfig.setMinEvictableIdleTimeMillis(minEvictableIdleTimeMillis);
        // 每次逐出检查时 逐出的最大数目 如果为负数就是 : 1/abs(n), 默认3
        jedisPoolConfig.setNumTestsPerEvictionRun(numTestsPerEvictionRun);
        // 逐出扫描的时间间隔(毫秒) 如果为负数,则不运行逐出线程, 默认-1
        jedisPoolConfig.setTimeBetweenEvictionRunsMillis(timeBetweenEvictionRunsMillis);
        // 是否在从池中取出连接前进行检验,如果检验失败,则从池中去除连接并尝试取出另一个
        jedisPoolConfig.setTestOnBorrow(testOnBorrow);
        // 在空闲时检查有效性, 默认false
        jedisPoolConfig.setTestWhileIdle(testWhileIdle);
        return jedisPoolConfig;
    }
    
    //Redis集群的配置
    @Bean
    public RedisClusterConfiguration redisClusterConfiguration() {
        RedisClusterConfiguration redisClusterConfiguration = new RedisClusterConfiguration();
        // Set<RedisNode> clusterNodes
        String[] serverArray = clusterNodes.split(",");
        Set<RedisNode> nodes = new HashSet<RedisNode>();
        for (String ipPort : serverArray) {
            String[] ipAndPort = ipPort.split(":");
            nodes.add(new RedisNode(ipAndPort[0].trim(), Integer.valueOf(ipAndPort[1])));
        }
        redisClusterConfiguration.setClusterNodes(nodes);
        redisClusterConfiguration.setMaxRedirects(maxRedirects);
        //redisClusterConfiguration.setPassword(RedisPassword.of(password));
        return redisClusterConfiguration;
    }

    //redis连接工厂类
    @Bean
    public JedisConnectionFactory jedisConnectionFactory() {
        // 集群模式
        JedisConnectionFactory factory = new JedisConnectionFactory(redisClusterConfiguration(), getJedisPoolConfig());
        return factory;
    }

    //实例化 RedisTemplate 对象
    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
        // Template初始化
        initDomainRedisTemplate(redisTemplate);
        return redisTemplate;
    }
    
    //设置数据存入 redis 的序列化方式 使用默认的序列化会导致key乱码
    private void initDomainRedisTemplate(RedisTemplate<String, Object> redisTemplate) {
        // 开启redis数据库事务的支持
        redisTemplate.setEnableTransactionSupport(true);
        redisTemplate.setConnectionFactory(jedisConnectionFactory());
        // 如果不配置Serializer，那么存储的时候缺省使用String，如果用User类型存储，那么会提示错误User can't cast to
        // String！
        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
        redisTemplate.setKeySerializer(stringRedisSerializer);
        // hash的key也采用String的序列化方式
        redisTemplate.setHashKeySerializer(stringRedisSerializer);
        // jackson序列化对象设置
        Jackson2JsonRedisSerializer<Object> jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer<>(
                Object.class);
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(om);
        // value序列化方式采用jackson
        redisTemplate.setValueSerializer(jackson2JsonRedisSerializer);
        // hash的value序列化方式采用jackson
        redisTemplate.setHashValueSerializer(jackson2JsonRedisSerializer);
        redisTemplate.afterPropertiesSet();
    }
}

测试代码

@SpringBootTest
class NinjaStudyApplicationTests {

    @Autowired
    private RedisTemplate<String, Object> template;

    @Test
    void contextLoads() {
        template.opsForValue().set("ninja", "Hello Redis Cluster");
        String str = (String) template.opsForValue().get("ninja");
        System.out.println(str);
    }
}

结果展示

posted @ 2021-03-09 18:19 鞋破露脚尖儿阅读(148) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

鞋破露脚尖儿

Redis架构原理与集群演变

Redis架构原理与集群演变

Redis持久化机制

Redis的持久化方案

RDB方案

触发RDB快照的时机

RDB设置快照规则

RDB快照实现原理

AOF方案

AOF同步磁盘数据

AOF重写原理

RDB和AOF的选择（混合持久化方式）

混合持久化方式

Redis的的主从同步机制

主从同步实现原理

全量同步三阶段

增量同步

主从配置（有个小故事）

Redis的Sentinel工作原理

Sentinel定时监控

主观下线

客观下线

Sentinel Leader选取流程

故障转移机制

哨兵进程的作用

Redis的集群框架&选择

主从复制

Replication + Sentinel *高可用 (了解)

Proxy + Replication + Sentinel (了解)

Redis Cluster(核心原理)

Redis Cluster高可用集群搭建指南

服务器清单

各服务器搭建Redis服务

修改配置搭建集群

Redis Cluster优缺对比

代码测试

公告