Redis使用

前置准备

默认启动

redis-server 前台打开建立连接 （卡住）新开窗口使用

指定配置启动

找到 redis.conf备份 再修改配置

监听地址，默认的是127.0.0.1导致只能在本地访问 修改为0.0.0.0可以在任意ip访问
bind 0.0.0.0

守护进程 修改yes后可后台运行

daemonize yes

密码，设置后访问必须输入密码

requirepass 123456

配置完成后后台启动

redis-server redis.conf

运行启动

redis-server 加上要修改的配置名和值（可以是多对），没有设置的配置将使用默认配置。

redis-server --port 6380

查看是否运行

    ps -ef | grep redis

[root@centos redis-6.2.6]# ps -ef | grep redis
root 49999 1 0 18:25 ? 00:00:00 redis-server 0.0.0.0:6379
root 52318 16624 0 18:27 pts/1 00:00:00 grep --color=auto redis

开放此端口

（–permanent永久生效，没有此参数重启后失效）

firewall-cmd --zone=public --add-port=6379/tcp --permanent   
firewall-cmd --zone=public --add-port=27001/tcp --permanent  

重新载入

firewall-cmd --reload

多服务开启

1.首先进入Redis文件中,然后拷贝几份redis的配置文件如下

cp redis.conf redis-6377.conf
cp redis.conf redis-6378.conf

2.之后进入这些文件,修改他们的端口号,使得他们之间端口互不冲突

port 6377
port 6378

3.并且修改题目的pidname,使得他们的pid文件位置不同

pidfile /var/run/redis_6377.pid
pidfile /var/run/redis_6378.pid

4.日志文件也是同理

logfile "redis-77.log"
logfile "redis-77.log"

5.之后修改他们的数据库文件位置

dbfilename dunp_6377.rdb
dbfilename dunp_6378.rdb

6.之后使用如下的方法开启redis不同端口的服务

redis-server redis-6378.conf
ps aux | grep redis

7.关闭 ：

使用 kill 编号 直接杀死进程

[root@centos redis-6.2.6]# kill 49999

1.3.3.开机自启

我们也可以通过配置来实现开机自启。
首先，新建一个系统服务文件：

vi /etc/systemd/system/redis.service

redis服务文件内容

记得修改目录

[Unit]
Description=redis-server
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/redis-server /home/root2/redis-6.2.6/redis.conf
PrivateTmp=true

[Install]
WantedBy=multi-user.target

可以用下面这组命令来操作redis了：

启动

systemctl start redis

停止

systemctl stop redis

重启

systemctl restart redis

查看状态

systemctl status redis

执行下面的命令，可以让redis开机自启：

systemctl enable redis

2.Redis客户端

安装完成Redis，我们就可以操作Redis，实现数据的CRUD了。这需要用到Redis客户端，包括：

• 命令行客户端
• 图形化桌面客户端
• 编程客户端

2.1.Redis命令行客户端

Redis安装完成后就自带了命令行客户端：redis-cli，使用方式如下：
redis-cli [options] [commonds]
其中常见的options有：

• -h 127.0.0.1：指定要连接的redis节点的IP地址，默认是127.0.0.1
• -p 6379：指定要连接的redis节点的端口，默认是6379
• -a 123321：指定redis的访问密码
  redis-cli -h 127.0.0.1 -p 6379 -a 123456
  也可以先： redis-cli -h 127.0.0.1 -p 6379
  然后：auth 123456
  其中的commonds就是Redis的操作命令，例如：
• ping：与redis服务端做心跳测试，服务端正常会返回pong
  不指定commond时，会进入redis-cli的交互控制台

在下面这个仓库可以找到安装包：
https://github.com/lework/RedisDesktopManager-Windows/releases

2.2.1.安装

在RESP是 Redis的图形化桌面客户端工具
解压缩后，运行安装程序即可安装
安装完成后，在安装目录下找到rdm.exe文件
双击即可运行

.建立连接

点击左上角的连接到Redis服务器按钮：
在弹出的窗口中填写Redis服务信息：
点击确定后，在左侧菜单会出现这个链接：
点击即可建立连接了：
如果连接失败关闭防火墙：
systemctl stop firewalld
Redis默认有16个仓库，编号从0至15. 通过配置文件可以设置仓库数量，但是不超过16，并且不能自定义仓库名称。
如果是基于redis-cli连接Redis服务，可以通过select命令来选择数据库：

选择 0号库

select 0

2.Redis常见命令

Redis是典型的key-value数据库，key一般是字符串，而value包含很多不同的数据类型：
Redis为了方便我们学习，将操作不同数据类型的命令也做了分组，在官网（ https://redis.io/commands ）可以查看到不同的命令：
不同类型的命令称为一个group，我们也可以通过help命令来查看各种不同group的命令：

2.1Redis 通用命令

通用指令是部分数据类型的，都可以使用的指令，常见的有：
KEYS：查看符合模板的所有key：

keys *

dbsize键总数

dbsize

DEL：删除一个指定的key

del key

EXISTS：判断key是否存在

exists key

EXPIRE：给一个key设置有效期，有效期到期时该key会被自动删除

expire key 12  -1代表永久存在 -2 表示已经过期

TTL：查看一个KEY的剩余有效期

ttl key

键的数据类型结构

type key

通过help [command] 可以查看一个命令的具体用法，例如：

help keys

2.2Redis命令-String命令

String类型，也就是字符串类型，是Redis中最简单的存储类型。

其value是字符串，不过根据字符串的格式不同，又可以分为3类：

string：普通字符串
int：整数类型，可以做自增.自减操作
float：浮点类型，可以做自增.自减操作

2.2.1 String的常见命令有

SET：添加或者修改已经存在的一个String类型的键值对
GET：根据key获取String类型的value

SET 和GET: 如果key不存在则是新增，如果存在则是修改

127.0.0.1:6379> set name Rose  //原来不存在
OK
127.0.0.1:6379> get name 
"Rose"
127.0.0.1:6379> set name Jack //原来存在，就是修改
OK
127.0.0.1:6379> get name
"Jack"

MSET：批量添加多个String类型的键值对
MGET：根据多个key获取多个String类型的value

MSET和MGET

127.0.0.1:6379> MSET k1 v1 k2 v2 k3 v3
OK
127.0.0.1:6379> MGET name age k1 k2 k3
1) "Jack" //之前存在的name
2) "10"   //之前存在的age
3) "v1"
4) "v2"
5) "v3"

INCR：让一个整型的key自增1
INCRBY:让一个整型的key自增并指定步长，例如：incrby num 2 让num值自增2
INCR和INCRBY和DECY，decrcy

127.0.0.1:6379> get age 
"10"
127.0.0.1:6379> incr age //增加1
(integer) 11
127.0.0.1:6379> get age //获得age
"11"
127.0.0.1:6379> incrby age 2 //一次增加2
(integer) 13 //返回目前的age的值
127.0.0.1:6379> incrby age 2
(integer) 15
127.0.0.1:6379> incrby age -1 //也可以增加负数，相当于减
(integer) 14
127.0.0.1:6379> incrby age -2 //一次减少2个
(integer) 12
127.0.0.1:6379> DECR age //相当于 incr 负数，减少正常用法
(integer) 11
127.0.0.1:6379> get age 
"11"

INCRBYFLOAT：让一个浮点类型的数字自增并指定步长
SETNX：添加一个String类型的键值对，前提是这个key不存在，否则不执行

SETNX

127.0.0.1:6379> help setnx
  SETNX key value
  summary: Set the value of a key, only if the key does not exist
  since: 1.0.0
  group: string
127.0.0.1:6379> set name Jack  //设置名称
OK
127.0.0.1:6379> setnx name lisi //如果key不存在，则添加成功
(integer) 0
127.0.0.1:6379> get name //由于name已经存在，所以lisi的操作失败
"Jack"
127.0.0.1:6379> setnx name2 lisi //name2 不存在，所以操作成功
(integer) 1
127.0.0.1:6379> get name2 
"lisi"

SETEX：添加一个String类型的键值对，并且指定有效期

127.0.0.1:6379> setex name 10 jack
OK
127.0.0.1:6379> ttl name
(integer) 8
127.0.0.1:6379> ttl name
(integer) 7
127.0.0.1:6379> ttl name
(integer) 5

2.2.2.String的 Key结构

Redis没有类似MySQL中的Table的概念，我们该如何区分不同类型的key呢？

例如，需要存储用户、商品信息到redis，有一个用户id是1，有一个商品id恰好也是1，此时如果使用id作为key，那就会冲突了，该怎么办？

我们可以通过给key添加前缀加以区分，不过这个前缀不是随便加的，有一定的规范：

Redis的key允许有多个单词形成层级结构，多个单词之间用’:'隔开，格式如下：

项目名:业务名:类型:id

这个格式并非固定，也可以根据自己的需求来删除或添加词条。这样以来，我们就可以把不同类型的数据区分开了。从而避免了key的冲突问题。

例如我们的项目名称叫 heima，有user和product两种不同类型的数据，我们可以这样定义key：

user相关的key：heima:user:1

product相关的key：heima:product:1

如果Value是一个Java对象，例如一个User对象，则可以将对象序列化为JSON字符串后存储：

KEY	             VALUE
heima:user:1     '{"id":1, "name":"Jack", "age": 21}'
heima:user:2     '{"id":2, "name":"Rose", "age": 18}'
heima:product:1  '{"id":1, "name": "小米11", "price": 4999}'
heima:product:2  '{"id":2, "name":"荣耀6", "price": 2999}'     需要''符

并且，在Redis的桌面客户端中，还会以相同前缀作为层级结构，让数据看起来层次分明，关系清晰。

2.3.Hash类型

Hash类型，也叫散列，其value是一个无序字典，类似于Java中的HashMap结构。
String结构是将对象序列化为JSON字符串后存储，当需要修改对象某个字段时很不方便：
Hash结构可以将对象中的每个字段独立存储，可以针对单个字段做CRUD：

Hash的常见命令有：

HSET key field value [field value …]：添加或者修改hash类型key的field的值

例：   hset heima:user:1 name "sy" age 18

HGET key field：获取一个hash类型key的field的值

例：     hget heima:user:1 name

HMSET：批量添加多个hash类型key的field的值

例：   hmset heima:user:1 name "sy" age 18

HMGET：批量获取多个hash类型key的field的值

例：   hmget heima:user:1 name age

HGETALL：获取一个hash类型的key中的所有的field和value

例：      hgetall heima:user:1

HKEYS：获取一个hash类型的key中的所有的field

例：      hkeys heima:user:1

HVALS: 可以拿到所有的值

例：      hvals heima:user:1

HINCRBY:让一个hash类型key的字段值自增并指定步长

例：      hincrby heima:user:1 age 2

HSETNX：添加一个hash类型的key的field值，前提是这个field不存在，否则不执行

例：       hsetnx heima:user:1 sex "男"

2.4.List类型

Redis中的List类型与Java中的LinkedList类似，可以看做是一个双向链表结构。既可以支持正向检索和也可以支持反向检索。
特征也与LinkedList类似：

有序
元素可以重复
插入和删除快
查询速度一般
常用来存储一个有序数据，例如：朋友圈点赞列表，评论列表等。

List的常见命令有：
LPUSH key element … ：向列表左侧插入一个或多个元素

例：   lpush users 1 2 3。由于从左进，所以# 3 valu 1，#2 value2，#1 value3

LPOP key count：移除并返回列表左侧的count个元素，没有则返回nil

例：   lpop  users 2

RPUSH key element … ：向列表右侧插入一个或多个元素

例：   rpush user 1 2 3。由于从右进，所以# 1 valu 1，#2 value2，#3 value3

RPOP key count：移除并返回列表右侧的count个元素

例：   rpop  users 2

LRANGE key star end：返回一段角标范围内（含0）的所有元素

例：   lrange user 0 4

BLPOP和BRPOP：与LPOP和RPOP类似，只不过在没有元素时等待指定时间，而不是直接返回nil
BLPOP key [key…] timeout

例:     blpop user2 100 此时会等待100s

2.5.Set类型

Redis的Set结构与Java中的HashSet类似，可以看做是一个value为null的HashMap。因为也是一个hash表，因此具备与HashSet类似的特征：

无序
元素不可重复
查找快
支持交集、并集、差集等功能

Set的常见命令有：

SADD key member … ：向set中添加一个或多个元素

例：      sadd s1 1 2 3 4

SREM key member … : 移除set中的指定元素

例         srem s1 1 2 3

SCARD key： 返回set中元素的个数

例：      scard s1

SISMEMBER key member：判断一个元素是否存在于set中

例：      sismember s1 1

SMEMBERS：获取set中的所有元素

例：      smembers s1

SINTER key1 key2 … ：求key1与key2的交集
例如两个集合：s1和s2:

例：       SINTER s1 s2

求s1与s2的不同：SDIFF s1 s2（输出s1比s2多的部分）
SUNION key1 key2 … ：求key1与key2的并集

例：       sunion s1 s2

练习：

将下列数据用Redis的Set集合来存储：
张三的好友有：李四、王五、赵六

例：       sadd z3 l4 w5 z6

李四的好友有：王五、麻子、二狗

例：       sadd l4 w5 mz 2g

利用Set的命令实现下列功能：
计算张三的好友有几人

例：       scard z3

计算张三和李四有哪些共同好友

例：       sinter z3 l4

查询哪些人是张三的好友却不是李四的好友

例：       sdiff z3 l4

查询张三和李四的好友总共有哪些人

例：       sunion z3 l4

判断李四是否是张三的好友

例：       sismember z3 l4

判断张三是否是李四的好友

例：       sismember l4 z3

将李四从张三的好友列表中移除

例：       srem z3 l4

2.6.SortedSet类型

Redis的SortedSet是一个可排序的set集合，与Java中的TreeSet有些类似，但底层数据结构却差别很大。SortedSet中的每一个元素都带有一个score属性，可以基于score属性对元素排序，底层的实现是一个跳表（SkipList）加 hash表。

SortedSet具备下列特性：

可排序
元素不重复
查询速度快
因为SortedSet的可排序特性，经常被用来实现排行榜这样的功能。

SortedSet的常见命令有：

ZADD key score member：添加一个或多个元素到sorted set ，如果已经存在则更新其score值

例：       zadd student 85 jack 89 lucy 82 rose 95 tom 78 jerry 92 amy 76 miles

ZREM key member：删除sorted set中的一个指定元素

例：       zrem student tom

ZSCORE key member : 获取sorted set中的指定元素的score值

例：       zscore student amy

ZRANK key member：获取sorted set 中的指定元素的排名（从0开始）

例：       zrank student rose

ZCARD key：获取sorted set中的元素个数

例：       zcard student

ZCOUNT key min max：统计score值在给定范围内的所有元素的个数

例：       zcount student 0 80

ZINCRBY key increment member：让sorted set中的指定元素自增，步长为指定的increment值

例：       zincrby student 2 amy

ZRANGE key min max：按照score排序后，获取指定排名范围内的元素（min，max是角标范围）

例：       zrange student 0 2

ZRANGEBYSCORE key min max：按照score排序后，获取指定score范围内的元素

例：       zrangebyscore student 0 80

ZDIFF、ZINT ER、ZUNION：求差集、交集、并集
注意：所有的排名默认都是升序，如果要降序则在命令的Z后面添加REV即可，例如：
升序获取sorted set 中的指定元素的排名：ZRANK key member
降序获取sorted set 中的指定元素的排名：ZREVRANK key memeber

练习题：

将班级的下列学生得分存入Redis的SortedSet中：

Jack 85, Lucy 89, Rose 82, Tom 95, Jerry 78, Amy 92, Miles 76
例： zadd student 85 jack 89 lucy 82 rose 95 tom 78 jerry 92 amy 76 miles
并实现下列功能：

删除Tom同学

例：       zrem student tom

获取Amy同学的分数

例：       zscore student amy

获取Rose同学的排名

例：       zrank student rose

查询80分以下有几个学生

例：       zcount student 0 80

给Amy同学加2分

例：       zincrby student 2 amy

查出成绩前3名的同学

例：       zrevrange student 0 2

查出成绩80分以下的所有同学

例：       zrangebyscore student 0 80

3.Redis的Java客户端

在Redis官网中提供了各种语言的客户端，地址：https://redis.io/docs/clients/

其中Java客户端也包含很多，
标记为*的就是推荐使用的java客户端，包括：

Jedis和Lettuce：这两个主要是提供了Redis命令对应的API，方便我们操作Redis，而SpringDataRedis又对这两种做了抽象和封装，因此我们后期会直接以SpringDataRedis来学习。

Redisson：是在Redis基础上实现了分布式的可伸缩的java数据结构，例如Map、Queue等，而且支持跨进程的同步机制：Lock、Semaphore等待，比较适合用来实现特殊的功能需求。

3.1.Jedis客户端

Jedis的官网地址： https://github.com/redis/jedis

3.1.1.快速入门

我们先来个快速入门：

idea创建maven项目，完善目录test，main，src

1）引入依赖：

在pom.xml下（本地找不到会去库外找）：

<dependencies>
    
     <dependency>
     <groupId>redis.clientsgroupId>
     <artifactId>jedisartifactId>
     <version>3.7.0version>
dependency>

     <dependency>
     <groupId>org.junit.jupitergroupId>
     <artifactId>junit-jupiterartifactId>
     <version>5.7.0version>
     <scope>testscope>
     dependency>
dependencies>

2）建立连接

新建一个单元测试类，内容如下：

package com.heima.test;
import com.heima.jedis.util.jedisConnectionFactory;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import redis.clients.jedis.Jedis;

import java.util.Map;

public class JedisTest {

    private Jedis jedis;

    @BeforeEach
    void setUp() {
        // 1.
        // jedis = new Jedis("192.168.193.139", 6379);
        jedis = jedisConnectionFactory.getJedis();
        // 2.设置密码
        jedis.auth("123456");
        // 3.选择库
        jedis.select(0);
    }
//测试：

    @Test
    void testString() {
        // 存入数据
        String result = jedis.set("name2", "比剑");
        System.out.println("result = " + result);
        // 获取数据
        String name = jedis.get("name");
        System.out.println("name = " + name);
    }

    @Test
    void testHash() {
        // 插入hash数据
        jedis.hset("user:1", "name", "Jack");
        jedis.hset("user:1", "age", "21");

        // 获取
        Map<String, String> map = jedis.hgetAll("user:1");
        System.out.println(map);
    }
//释放资源

    @AfterEach
    void tearDown() {
        if (jedis != null) {
            jedis.close();
        }
    }
}

3.1.2.连接池

Jedis本身是线程不安全的，并且频繁的创建和销毁连接会有性能损耗，因此我们推荐大家使用Jedis连接池代替Jedis的直连方式。

package com.heima.jedis.util;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

public class jedisConnectionFactory {
    private static final JedisPool jedisPool;

    static {
        //配置连接池
        JedisPoolConfig  poolConfig = new JedisPoolConfig();
        poolConfig.setMaxTotal(8);//最大连接数
        poolConfig.setMaxIdle(8);//最大空闲连接
        poolConfig.setMaxIdle(0);//最小空闲连接
        poolConfig.setMaxWaitMillis(1000);//无连接池等待时间1000ms，默认-1 无限等待
        // 创建连接池对象，参数：连接池配置、服务端ip、服务端端口、超时时间、密码
        jedisPool =new JedisPool(poolConfig,"192.168.193.139",6379,1000,"123456");;

    }
    public static Jedis getJedis(){
        return jedisPool.getResource();
    }
}

3.2.2 SpringDataRedis客户端

SpringData是Spring中数据操作的模块，包含对各种数据库的集成，其中对Redis的集成模块就叫做SpringDataRedis，官网地址：https://spring.io/projects/spring-data-redis

提供了对不同Redis客户端的整合（Lettuce和Jedis）
提供了RedisTemplate统一API来操作Redis
支持Redis的发布订阅模型
支持Redis哨兵和Redis集群
支持基于Lettuce的响应式编程
支持基于JDK、JSON、字符串、Spring对象的数据序列化及反序列化
支持基于Redis的JDKCollection实现
SpringDataRedis中提供了RedisTemplate工具类，其中封装了各种对Redis的操作。并且将不同数据类型的操作API封装到了不同的类型中：

3.2.1.快速入门

SpringBoot已经提供了对SpringDataRedis的支持，使用非常简单。

首先，新建一个maven项目，然后按照下面步骤执行：

1）引入依赖

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0modelVersion>
    <parent>
        <groupId>org.springframework.bootgroupId>
        <artifactId>spring-boot-starter-parentartifactId>
        <version>3.0.4version>
        <relativePath/> 
    parent>
    <groupId>com.examplegroupId>
    <artifactId>redis-demoartifactId>
    <version>0.0.1-SNAPSHOTversion>
    <name>redis-demoname>
    <description>redis-demodescription>
    <properties>
        <java.version>17java.version>
    properties>
    <dependencies>
        
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-data-redisartifactId>
        dependency>
        
        <dependency>
            <groupId>org.apache.commonsgroupId>
            <artifactId>commons-pool2artifactId>
        dependency>
        <dependency>
            <groupId>org.projectlombokgroupId>
            <artifactId>lombokartifactId>
            <optional>trueoptional>
        dependency>
        <dependency>
            <groupId>org.springframework.bootgroupId>
            <artifactId>spring-boot-starter-testartifactId>
            <scope>testscope>
        dependency>
    dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.bootgroupId>
                <artifactId>spring-boot-maven-pluginartifactId>
                <configuration>
                    <excludes>
                        <exclude>
                            <groupId>org.projectlombokgroupId>
                            <artifactId>lombokartifactId>
                        exclude>
                    excludes>
                configuration>
            plugin>
        plugins>
    build>

project>

2）配置Redis

spring:
  data:
    redis:
      host: 192.168.193.139
      port: 6379
      password: 123456
      lettuce:
        pool:
          max-active: 8
          max-idle: 8
          min-idle: 0
          max-wait: 100ms

3）注入RedisTemplate

因为有了SpringBoot的自动装配，我们可以拿来就用：

@SpringBootTest
class RedisStringTests {

    @Autowired
    private RedisTemplate redisTemplate;
}

4）编写测试

@SpringBootTest
class RedisStringTests {

    @Autowired
    private RedisTemplate edisTemplate;

    @Test
    void testString() {
        // 写入一条String数据
        redisTemplate.opsForValue().set("name", "虎哥");
        // 获取string数据
        Object name = stringRedisTemplate.opsForValue().get("name");
        System.out.println("name = " + name);
    }
}

3.2.2.自定义序列化

RedisTemplate可以接收任意Object作为值写入Redis：

只不过写入前会把Object序列化为字节形式，默认是采用JDK序列化，得到的结果是这样的：

缺点：

可读性差
内存占用较大
我们可以自定义RedisTemplate的序列化方式，代码如下：

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory connectionFactory){
        // 创建RedisTemplate对象
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        // 设置连接工厂
        template.setConnectionFactory(connectionFactory);
        // 创建JSON序列化工具
        GenericJackson2JsonRedisSerializer jsonRedisSerializer = 
            							new GenericJackson2JsonRedisSerializer();
        // 设置Key的序列化
        template.setKeySerializer(RedisSerializer.string());
        template.setHashKeySerializer(RedisSerializer.string());
        // 设置Value的序列化
        template.setValueSerializer(jsonRedisSerializer);
        template.setHashValueSerializer(jsonRedisSerializer);
        // 返回
        return template;
    }
}

这里采用了JSON序列化来代替默认的JDK序列化方式。：

整体可读性有了很大提升，并且能将Java对象自动的序列化为JSON字符串，并且查询时能自动把JSON反序列化为Java对象。不过，其中记录了序列化时对应的class名称，目的是为了查询时实现自动反序列化。这会带来额外的内存开销。

引入依赖：

com.fasterxml.jackson.core
jackson-databind

编写测试

@Test
    void testSaveUser(){
        //写入数据
        redisTemplate.opsForValue().set("user:100",new User("沈阳",21));
        //获取数据
         /*Object*/User o=(User) redisTemplate.opsForValue().get("user:100");
        System.out.println("o = "+o);
    }

3.2.3.StringRedisTemplate

为了节省内存空间，我们可以不使用JSON序列化器来处理value，而是统一使用String序列化器，要求只能存储String类型的key和value。当需要存储Java对象时，手动完成对象的序列化和反序列化。

因为存入和读取时的序列化及反序列化都是我们自己实现的，SpringDataRedis就不会将class信息写入Redis了。

这种用法比较普遍，因此SpringDataRedis就提供了RedisTemplate的子类：StringRedisTemplate，它的key和value的序列化方式默认就是String方式。

省去了我们自定义RedisTemplate的序列化方式的步骤，而是直接使用：

@Autowired
private StringRedisTemplate stringRedisTemplate;
// JSON序列化工具
private static final ObjectMapper mapper = new ObjectMapper();

@Test
void testSaveUser() throws JsonProcessingException {
    // 创建对象
    User user = new User("虎哥", 21);
    // 手动序列化
    String json = mapper.writeValueAsString(user);
    // 写入数据
    stringRedisTemplate.opsForValue().set("user:200", json);

    // 获取数据
    String jsonUser = stringRedisTemplate.opsForValue().get("user:200");
    // 手动反序列化
    User user1 = mapper.readValue(jsonUser, User.class);
    System.out.println("user1 = " + user1);
}

Hash：

@Test
    void testHash() {
        stringRedisTemplate.opsForHash().put("user:400", "name", "宋必检");
        stringRedisTemplate.opsForHash().put("user:400", "age", "21");
        Map<Object, Object> entries = stringRedisTemplate.opsForHash().entries("user:400");
        System.out.println("entries = " + entries);
    }

4.Redis消息队列

4.3 Redis消息队列-基于PubSub的消息队列：

SUBSCRIBE channel [channel] ：订阅一个或多个频道

1.SUBSCRIBE oder.q1

PUBLISH channel msg ：向一个频道发送消息

2.PUBLISH  order.q1 hello

PSUBSCRIBE pattern[pattern] ：订阅与pattern格式匹配的所有频道

基于PubSub的消息队列有哪些优缺点？
优点：

• 采用发布订阅模型，支持多生产、多消费

缺点：

• 不支持数据持久化
• 无法避免消息丢失
• 消息堆积有上限，超出时数据丢失

4.4Redis消息队列-基于Stream的消息队列

4.4.1.发送消息的命令：

XADD key [NOMKSTREAM] [MAXLEN|MINID [=|~] threshold [LIMIT count]] *|ID fiel value [firld value .....]

key： 队列名称
[NOMKSTREAM]: 如果队列不存在是否自动创建队列，默认自动创建
[MAXLEN|MINID [=|~] threshold [LIMIT count]]： 设置消息队列的最大消息数量
*|ID： 消息的唯一id，*代表由redis自动生成。格式是“时间戳-递增数字”，例如“1644804662707-0”
fiel value [firld value …]： 发送到队列的消息，称为Entry，格式就是多个key-value键值对

例：               XADD s1 * k1 v1

4.4.1.2

XLEN key：                                                                查看消息队列的数量

4.4.2.读取消息的方式之一：XREAD

XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...]

[BLOCK milliseconds]： 当没有消息时，是否阻塞、阻塞时长（毫秒），BLOCK 0 永久阻塞
STREAMS key [key …]： 要从哪个队列读取消息，key就是队列名
ID [ID …]： 起始id，只返回大于该ID的消息，0：代表从第一个开始，$:代表从最新的消息开始

例：             XREAD COUNT 1 BLOCK 0 STREAMS s1 $      

4.5 Redis消息队列-基于Stream的消息队列-消费者组

消费者组（Consumer Group）：将多个消费者划分到一个组中，监听同一个队列。具备下列特点：
01:消息分流 队列中的消息会分流给组内的不同消费者，而不是重复的消费，从而加快消息处理的速度.
02：消息标示 消费者组会维护一个标示，记录最后一个被处理的消息，哪怕消费者宕机重启，还会从标示之后读取消息。确保每一个消息都会被消费
03：消息确认 消费者获取消息后，消息处于pending状态，并存入一个pending-list。当处理完成后需要通过XACK来确认消息，标记消息为已处理，才会从pending-list移除。

4.5.2创建消费组

XGROUP [CREATE key groupname ID|$ [MKSTREAM]] [SETID key groupname ID|$] [DESTROY key groupname]

key： 队列名称
groupName： 消费者组名称
ID： 起始ID标示，$代表队列中最后一个消息，0则代表队列中第一个消息
MKSTREAM： 队列不存在时自动创建队列

例：                                  XGROUP CREATE s1 g1 0

4.5.3从消费者组读取消息：

XREADGROUP GROUP group consumer COUNT count [BLOCK milliseconds] [NOACK] STREAMS key [key …] ID [ID …]

• group： 消费组名称
• consumer： 消费者名称，如果消费者不存在，会自动创建一个消费者
• count： 本次查询的最大数量
• BLOCK milliseconds： 当没有消息时最长等待时间
• NOACK： 无需手动ACK，获取到消息后自动确认
• STREAMS key： 指定队列名称
• ID： 获取消息的起始ID：
  “>”： 从下一个未消费的消息开始

 例     xreadgroup GROUP g1 c1 COUNT 1 BLOCK 2000 STREAMS s1 >

其它：根据指定id从pending-list中获取已消费但未确认的消息，例如0，是从pending-list中的第一个消息开始.

XPENDING key group [[IDLE min-idle-time] start end count [consumer]]

* 例：                            XPENDING s1 g1 - + 10

4.5.4确认消息已读：

XACK key group ID [ID …]

例：XACK s1 g1 1679394987740-0  1679396615550-0

其它常见命令：

删除指定的消费者组

XGROUP DESTORY key groupName

给指定的消费者组添加消费者

XGROUP CREATECONSUMER key groupname consumername

删除消费者组中的指定消费者

XGROUP DELCONSUMER key groupname consumername

4.5.5、附近商户-GEO数据结构的基本用法

GEO就是Geolocation的简写形式，代表地理坐标。Redis在3.2版本中加入了对GEO的支持，允许存储地理坐标信息，帮助我们根据经纬度来检索数据。常见的命令有：

• GEOADD：添加一个地理空间信息，包含：经度（longitude）、纬度（latitude）、值（member）
  例： GEOADD g1 116.378248 39.865275 bjn 116.42803 39.903738 bjz 116.322287 39.893729 bjx
• GEODIST：计算指定的两个点之间的距离并返回
  例： GEODIST g1 bjn bjx
• GEOHASH：将指定member的坐标转为hash字符串形式并返回
  例： GEOHASH g1 bjz
• GEOPOS：返回指定member的坐标
• GEORADIUS：指定圆心、半径，找到该圆内包含的所有member，并按照与圆心之间的距离排序后返回。6.以后已废弃
• GEOSEARCH：在指定范围内搜索member，并按照与指定点之间的距离排序后返回。范围可以是圆形或矩形。6.2.新功能
  例： GEOSEARCH g1 FROMLONLAT 116.378248 39.865275 BYRADIUS 10 km WITHDIST
• GEOSEARCHSTORE：与GEOSEARCH功能一致，不过可以把结果存储到一个指定的key。 6.2.新功能

11.1、用户签到-BitMap功能演示
BitMap的操作命令有：

• SETBIT：向指定位置（offset）存入一个0或1
  SETBIT key offset value offset（角标）
  例： SETbit bm1 0 1
• GETBIT ：获取指定位置（offset）的bit值
  GETBIT key offset
  例： GETBIT bm1 1
• BITCOUNT ：统计BitMap中值为1的bit位的数量
  BITCOUNT key [start end]
  例： BITCOUNT bm1
• BITFIELD ：操作（查询、修改、自增）BitMap中bit数组中的指定位置（offset）的值（10进制）
  BITFIELD key [GET type offset] [SET type offset value] [INCRBY
  例： BITFIELD bm1 GET u2 0
• BITFIELD_RO ：获取BitMap中bit数组，并以十进制形式返回
• BITOP ：将多个BitMap的结果做位运算（与 、或、异或）
  BITOP operation destkey key [key …]
• BITPOS ：查找bit，数组中指定范围内第一个0或1出现的位置
  BITPOS key bit [start] [end]
  例： BITPOS bm1 0 0 1

Redis高级使用

1.Redis持久化

1.1.RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。（dump.rdb）

1.1.执行时机

RDB持久化在四种情况下会执行：

• 执行save命令
• 执行bgsave命令
• Redis停机时
• 触发RDB条件时

1）save命令

执行下面的命令，可以立即执行一次RDB：

save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。

2）bgsave命令

下面的命令可以异步执行RDB：

这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。

3）停机时

Redis停机时会执行一次save命令，实现RDB持久化。

4）触发RDB条件

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000 

RDB的其它配置也可以在redis.conf文件中设置：

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes（no）

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./ 

1.2.RDB原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

fork采用的是copy-on-write技术：

• 当主进程执行读操作时，访问共享内存；
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作。

1.2.AOF持久化

2.1.AOF原理

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

2.2.AOF配置

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof" 

位置 ‘/appendonly.aof’

寻找 appendonly.aof文件位置
find / -name appendonly.aof

AOF的命令记录的频率也可以通过redis.conf文件来配：

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

三种策略对比：

2.3.AOF文件重写

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

如图，AOF原本有三个命令，但是set num 123 和 set num 666都是对num的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。

所以重写命令后，AOF文件内容就是：mset name jack num 666

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb 

3.RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

2.Redis主从

2.1.搭建主从架构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

2.Redis主从集群

2.1.集群结构

我们搭建的主从集群结构：
共包含三个节点，一个主节点，两个从节点。

这里我们会在同一台虚拟机中开启3个redis实例，模拟主从集群，信息如下：

IP	PORT	角色
192.168.150.101	7001	master
192.168.150.101	7002	slave
192.168.150.101	7003	slave

2.2.准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

1）创建目录

我们创建三个文件夹，名字分别叫7001、7002、7003：

# 进入/tmp目录
cd /tmp
# 创建目录
mkdir 7001 7002 7003

2）恢复原始配置

修改redis-6.2.4/redis.conf文件，将其中的持久化模式改为默认的RDB模式，AOF保持关闭状态。

# 开启RDB
# save ""
save 3600 1
save 300 100
save 60 10000

# 关闭AOF
appendonly no

3）拷贝配置文件到每个实例目录

然后将redis-6.2.4/redis.conf文件拷贝到三个目录中（在/tmp目录执行下列命令）：

# 方式一：逐个拷贝
cp redis-6.2.4/redis.conf 7001
cp redis-6.2.4/redis.conf 7002
cp redis-6.2.4/redis.conf 7003

# 方式二：管道组合命令，一键拷贝
echo 7001 7002 7003 | xargs -t -n 1 cp redis-6.2.4/redis.conf

4）修改每个实例的端口、工作目录

修改每个文件夹内的配置文件，将端口分别修改为7001、7002、7003，将rdb文件保存位置都修改为自己所在目录（在/tmp目录执行下列命令）：

sed -i -e 's/6379/7001/g' -e 's/dir .\//dir \/tmp\/7001\//g' 7001/redis.conf
sed -i -e 's/6379/7002/g' -e 's/dir .\//dir \/tmp\/7002\//g' 7002/redis.conf
sed -i -e 's/6379/7003/g' -e 's/dir .\//dir \/tmp\/7003\//g' 7003/redis.conf

5）修改每个实例的声明IP

虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息，格式如下：

# redis实例的声明 IP
replica-announce-ip 192.168.150.101

每个目录都要改，我们一键完成修改（在/tmp目录执行下列命令）：

# 逐一执行
sed -i '1a replica-announce-ip 192.168.150.101' 7001/redis.conf
sed -i '1a replica-announce-ip 192.168.150.101' 7002/redis.conf
sed -i '1a replica-announce-ip 192.168.150.101' 7003/redis.conf

# 或者一键修改
printf '%s\n' 7001 7002 7003 | xargs -I{} -t sed -i '1a replica-announce-ip 192.168.150.101' {}/redis.conf

2.3.启动

为了方便查看日志，我们打开3个ssh窗口，分别启动3个redis实例，启动命令：

# 第1个
redis-server 7001/redis.conf
# 第2个
redis-server 7002/redis.conf
# 第3个
redis-server 7003/redis.conf
``


如果要一键停止，可以运行下面命令：

```sh
printf '%s\n' 7001 7002 7003 | xargs -I{} -t redis-cli -p {} shutdown

2.4.开启主从关系

现在三个实例还没有任何关系，要配置主从可以使用replicaof 或者slaveof（5.0以前）命令。

有临时和永久两种模式：

• 修改配置文件（永久生效）

  • 在redis.conf中添加一行配置：slaveof

• 使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：

  slaveof <masterip> <masterport>
  

注意：在5.0以后新增命令replicaof，与salveof效果一致。

这里我们为了演示方便，使用方式二。

通过redis-cli命令连接7002，执行下面命令：

# 连接 7002
redis-cli -p 7002
# 执行slaveof
slaveof 192.168.150.101 7001

通过redis-cli命令连接7003，执行下面命令：

# 连接 7003
redis-cli -p 7003
# 执行slaveof
slaveof 192.168.150.101 7001
replicaof 192.168.150.101 7001

然后连接 7001节点，查看集群状态：

# 连接 7001
redis-cli -p 7001
# 查看状态
info replication

2.5.测试

执行下列操作以测试：

• 利用redis-cli连接7001，执行set num 123

• 利用redis-cli连接7002，执行get num，再执行set num 666

• 利用redis-cli连接7003，执行get num，再执行set num 888

可以发现，只有在7001这个master节点上可以执行写操作，7002和7003这两个slave节点只能执行读操作。

如果连接不上需要输入主节点密码

masterauth xxxx

或者主节点

2.redis主配置文件

bind 127.0.0.1 -::1这个是默认值，主服务器绑定了127.0.0.1，其他的服务器IP访问就会拒绝

先要将 bind 127.0.0.1 -::1注释，或修改为bind 0.0.0.0 （本人就是直接添加bind 0.0.0.0，没注释默认值，导致报错）

2.2.主从数据同步原理

2.2.1.全量同步

主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，流程：

这里有一个问题，master如何得知salve是第一次来连接呢？？

有几个概念，可以作为判断依据：

• Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
• offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据。

因为slave原本也是一个master，有自己的replid和offset，当第一次变成slave，与master建立连接时，发送的replid和offset是自己的replid和offset。

master判断发现slave发送来的replid与自己的不一致，说明这是一个全新的slave，就知道要做全量同步了。

master会将自己的replid和offset都发送给这个slave，slave保存这些信息。以后slave的replid就与master一致了。

因此，master判断一个节点是否是第一次同步的依据，就是看replid是否一致。

完整流程描述：

• slave节点请求增量同步
• master节点判断replid，发现不一致，拒绝增量同步
• master将完整内存数据生成RDB，发送RDB到slave
• slave清空本地数据，加载master的RDB
• master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
• slave执行接收到的命令，保持与master之间的同步

2.2.2.增量同步

全量同步需要先做RDB，然后将RDB文件通过网络传输个slave，成本太高了。因此除了第一次做全量同步，其它大多数时候slave与master都是做增量同步。

什么是增量同步？就是只更新slave与master存在差异的部分数据。如图：

那么master怎么知道slave与自己的数据差异在哪里呢?

2.2.3.repl_backlog原理

master怎么知道slave与自己的数据差异在哪里呢?

这就要说到全量同步时的repl_baklog文件了。

这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset：

slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。

随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset：

直到数组被填满：

此时，如果有新的数据写入，就会覆盖数组中的旧数据。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。

但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset：

)

如果master继续写入新数据，其offset就会覆盖旧的数据，直到将slave现在的offset也覆盖：

棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。此时如果slave恢复，需要同步，却发现自己的offset都没有了，无法完成增量同步了。只能做全量同步。

2.3.主从同步优化

主从同步可以保证主从数据的一致性，非常重要。

可以从以下几个方面来优化Redis主从就集群：

• 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
• Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
• 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
• 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

主从从架构图：

2.4.小结

简述全量同步和增量同步区别？

• 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
• 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

• slave节点第一次连接master节点时
• slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

• slave节点断开又恢复，并且在repl_baklog中能找到offset时

3.搭建哨兵集群

3.1.集群结构

这里我们搭建一个三节点形成的Sentinel集群，来监管之前的Redis主从集群。：

三个sentinel实例信息如下：

节点	IP	PORT
s1	192.168.150.101	27001
s2	192.168.150.101	27002
s3	192.168.150.101	27003

3.2.准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

我们创建三个文件夹，名字分别叫s1、s2、s3：

# 进入/tmp目录
cd /tmp
# 创建目录
mkdir s1 s2 s3

然后我们在s1目录创建一个sentinel.conf文件，添加下面的内容：

port 27001
sentinel announce-ip 192.168.193.141
sentinel monitor mymaster 192.168.193.141 7001 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
dir "/redissz/s1"

解读：

• port 27001：是当前sentinel实例的端口
• sentinel monitor mymaster 192.168.150.101 7001 2：指定主节点信息
  • mymaster：主节点名称，自定义，任意写
  • 192.168.150.101 7001：主节点的ip和端口
  • 2：选举master时的quorum值

然后将s1/sentinel.conf文件拷贝到s2、s3两个目录中（在/tmp目录执行下列命令）：

# 方式一：逐个拷贝
cp s1/sentinel.conf s2
cp s1/sentinel.conf s3
# 方式二：管道组合命令，一键拷贝
echo s2 s3 | xargs -t -n 1 cp s1/sentinel.conf

修改s2、s3两个文件夹内的配置文件，将端口分别修改为27002、27003：

sed -i -e 's/27001/27002/g' -e 's/s1/s2/g' s2/sentinel.conf
sed -i -e 's/27001/27003/g' -e 's/s1/s3/g' s3/sentinel.conf

3.3.启动

为了方便查看日志，我们打开3个ssh窗口，分别启动3个redis实例，启动命令：

# 第1个
redis-sentinel s1/sentinel.conf
# 第2个
redis-sentinel s2/sentinel.conf
# 第3个
redis-sentinel s3/sentinel.conf

启动后：

3.4.测试

4.搭建分片集群

4.1.集群结构

分片集群需要的节点数量较多，这里我们搭建一个最小的分片集群，包含3个master节点，每个master包含一个slave节点，结构如下：

这里我们会在同一台虚拟机中开启6个redis实例，模拟分片集群，信息如下：

IP	PORT	角色
192.168.150.101	7001	master
192.168.150.101	7002	master
192.168.150.101	7003	master
192.168.150.101	8001	slave
192.168.150.101	8002	slave
192.168.150.101	8003	slave

4.2.准备实例和配置

删除之前的7001、7002、7003这几个目录，重新创建出7001、7002、7003、8001、8002、8003目录：

# 进入/tmp目录
cd /tmp
# 删除旧的，避免配置干扰
rm -rf 7001 7002 7003
# 创建目录
mkdir 7001 7002 7003 8001 8002 8003

在/tmp下准备一个新的redis.conf文件，内容如下：

port 6379
# 开启集群功能
cluster-enabled yes
# 集群的配置文件名称，不需要我们创建，由redis自己维护
cluster-config-file /redissb/6379/nodes.conf
# 节点心跳失败的超时时间
cluster-node-timeout 5000
# 持久化文件存放目录
dir /redissb/6379
# 绑定地址
bind 0.0.0.0
# 让redis后台运行
daemonize yes
# 注册的实例ip
replica-announce-ip 192.168.192.141
# 保护模式
protected-mode no
# 数据库数量
databases 1
# 日志
logfile /redissb/6379/run.log

将这个文件拷贝到每个目录下：

# 进入/tmp目录
cd /tmp
# 执行拷贝
echo 7001 7002 7003 8001 8002 8003 | xargs -t -n 1 cp redis.conf

修改每个目录下的redis.conf，将其中的6379修改为与所在目录一致：

# 进入/tmp目录
cd /tmp
# 修改配置文件
printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t sed -i 's/6379/{}/g' {}/redis.conf

4.3.启动

因为已经配置了后台启动模式，所以可以直接启动服务：

# 进入/tmp目录
cd /tmp
# 一键启动所有服务
printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t redis-server {}/redis.conf

通过ps查看状态：

ps -ef | grep redis

发现服务都已经正常启动：

如果要关闭所有进程，可以执行命令：

ps -ef | grep redis | awk '{print $2}' | xargs kill

或者（推荐这种方式）：

printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t redis-cli -p {} shutdown

4.4.创建集群

虽然服务启动了，但是目前每个服务之间都是独立的，没有任何关联。

我们需要执行命令来创建集群，在Redis5.0之前创建集群比较麻烦，5.0之后集群管理命令都集成到了redis-cli中。

1）Redis5.0之前

Redis5.0之前集群命令都是用redis安装包下的src/redis-trib.rb来实现的。因为redis-trib.rb是有ruby语言编写的所以需要安装ruby环境。

# 安装依赖
yum -y install zlib ruby rubygems
gem install redis

然后通过命令来管理集群：

# 进入redis的src目录
cd /tmp/redis-6.2.4/src
# 创建集群
./redis-trib.rb create --replicas 1 192.168.193.141:7001 192.168.193.141:7002 192.168.193.141:7003 192.168.193.141:8001 192.168.193.141:8002 192.168.193.141:8003

2）Redis5.0以后

我们使用的是Redis6.2.4版本，集群管理以及集成到了redis-cli中，格式如下：

redis-cli --cluster create --cluster-replicas 1 192.168.193.141:7001 192.168.193.141:7002 192.168.193.141:7003 192.168.193.141:8001 192.168.193.141:8002 192.168.193.141:8003

命令说明：

• redis-cli --cluster或者./redis-trib.rb：代表集群操作命令
• create：代表是创建集群
• --replicas 1或者--cluster-replicas 1 ：指定集群中每个master的副本个数为1，此时节点总数 ÷ (replicas + 1) 得到的就是master的数量。因此节点列表中的前n个就是master，其它节点都是slave节点，随机分配到不同master

运行后的样子：

Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: 65d27fb778680a35adefc0a49b841009a063b5a3 192.168.193.141:7001
slots:[0-5460] (5461 slots) master
M: 4355b9cb3cce32b2436a3e5476eda26dd0873030 192.168.193.141:7002
slots:[5461-10922] (5462 slots) master
M: 981064ba7a2c6130be11b533c134b023989bf44a 192.168.193.141:7003
slots:[10923-16383] (5461 slots) master
S: 3abf36d9d17ac86ef224cb4d1d8545a36bf8059f 192.168.193.141:8001
replicates 65d27fb778680a35adefc0a49b841009a063b5a3
S: 00c183fc285137bc905b2fefe1664d88111f5c83 192.168.193.141:8002
replicates 4355b9cb3cce32b2436a3e5476eda26dd0873030
S: 9b9250f8e9ffc36924bf6947f16d6f41a2e8b4df 192.168.193.141:8003
replicates 981064ba7a2c6130be11b533c134b023989bf44a

这里输入yes，则集群开始创建：
[OK] All nodes agree about slots configuration.

Check for open slots…
Check slots coverage…
[OK] All 16384 slots covered.

通过命令可以查看集群状态：

redis-cli -p 7001 cluster nodes

状态：
981064ba7a2c6130be11b533c134b023989bf44a 192.168.193.141:7003@17003 master - 0 1680576154095 3 connected 10923-16383
65d27fb778680a35adefc0a49b841009a063b5a3 192.168.193.141:7001@17001 myself,master - 0 1680576152000 1 connected 0-5460
4355b9cb3cce32b2436a3e5476eda26dd0873030 192.168.193.141:7002@17002 master - 0 1680576154095 2 connected 5461-10922
00c183fc285137bc905b2fefe1664d88111f5c83 192.168.193.141:8002@18002 slave 4355b9cb3cce32b2436a3e5476eda26dd0873030 0 1680576154000 2 connected
9b9250f8e9ffc36924bf6947f16d6f41a2e8b4df 192.168.193.141:8003@18003 slave 981064ba7a2c6130be11b533c134b023989bf44a 0 1680576152583 3 connected
3abf36d9d17ac86ef224cb4d1d8545a36bf8059f 192.168.193.141:8001@18001 slave 65d27fb778680a35adefc0a49b841009a063b5a3 0 1680576153590 1 connected

4.5.测试

尝试连接7001节点，存储一个数据：

# 连接
redis-cli -p 7001
# 存储数据
set num 123
# 读取数据
get num
# 再次存储
set a 1

结果悲剧了：
(error) MOVED 15495 192.168.193.141:7003

集群操作时，需要给redis-cli加上-c参数才可以：

redis-cli -c -p 7001

这次可以了：

ok

4.2.散列插槽

4.2.1.插槽原理

Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上，查看集群信息时就能看到：
7001： connected 0-5460
7002： connected 5461-10922
7003： connected 10923-16383

数据key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：

• key中包含"{}"，且“{}”中至少包含1个字符，“{}”中的部分是有效部分
• key中不包含“{}”，整个key都是有效部分

例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。

127.0.0.1:7001> set a 1
-> Redirected to slot [15495] located at 192.168.193.141:7003
OK
192.168.193.141:7003> set num 123
-> Redirected to slot [2765] located at 192.168.193.141:7001
OK
192.168.193.141:7001> get a
-> Redirected to slot [15495] located at 192.168.193.141:7003
"1"
192.168.193.141:7003> get num
-> Redirected to slot [2765] located at 192.168.193.141:7001
"123"
192.168.193.141:7001>

如示例，在7001这个节点执行set a 1时，对a做hash运算，对16384取余，得到的结果是15495，因此要存储到103节点。

到了7003后，执行get num时，对num做hash运算，对16384取余，得到的结果是2765，因此需要切换到7001节点

4.2.1.小结

Redis如何判断某个key应该在哪个实例？

• 将16384个插槽分配到不同的实例
• 根据key的有效部分计算哈希值，对16384取余
• 余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

• 这一类数据使用相同的有效部分，例如key都以{typeId}为前缀

4.3.集群伸缩

redis-cli --cluster提供了很多操作集群的命令，可以通过下面方式查看：

[root@centos redissb]#  redis-cli --cluster -help

Cluster Manager Commands:
create host1:port1 … hostN:portN
–cluster-replicas
check host:port
–cluster-search-multiple-owners
info host:port
fix host:port
–cluster-search-multiple-owners
–cluster-fix-with-unreachable-masters
reshard host:port
–cluster-from
–cluster-to
–cluster-slots
–cluster-yes
–cluster-timeout
–cluster-pipeline
–cluster-replace
rebalance host:port
–cluster-weight
–cluster-use-empty-masters
–cluster-timeout
–cluster-simulate
–cluster-pipeline
–cluster-threshold
–cluster-replace
add-node new_host:new_port existing_host:existing_port
–cluster-slave
–cluster-master-id
del-node host:port node_id
call host:port command arg arg … arg
–cluster-only-masters
–cluster-only-replicas
set-timeout host:port milliseconds
import host:port
–cluster-from
–cluster-from-user
–cluster-from-pass
–cluster-from-askpass
–cluster-copy
–cluster-replace
backup host:port backup_directory
help

比如，添加节点的命令：

 add-node       new_host:new_port existing_host:existing_port
                 --cluster-slave
                 --cluster-master-id <arg>

4.3.1.需求分析

需求：向集群中添加一个新的master节点，并向其中存储 num = 10

• 启动一个新的redis实例，端口为7004
• 添加7004到之前的集群，并作为一个master节点
• 给7004节点分配插槽，使得num这个key可以存储到7004实例

这里需要两个新的功能：

• 添加一个节点到集群中
• 将部分插槽分配到新插槽

4.3.2.创建新的redis实例

创建一个文件夹：

mkdir 7004

拷贝配置文件：

cp redis.conf /7004

修改配置文件：

sed /s/6379/7004/g 7004/redis.conf

启动

redis-server 7004/redis.conf

4.3.3.添加新节点到redis

添加节点的语法如下：

add-node new_host:new_port existing_host:existing_port
–cluster-slave
–cluster-master-id

执行命令：

redis-cli --cluster add-node  192.168.192.141:7004 192.168.192.141:7001

通过命令查看集群状态：

redis-cli -p 7001 cluster nodes

如图，7004加入了集群，并且默认是一个master节点：

973d5a034eb1aaa81e800aae490e9674e061c615 192.168.193.141:7004@17004 master - 0 1680611388000 0 connected

但是，可以看到7004节点的插槽数量为0，因此没有任何数据可以存储到7004上

4.3.4.转移插槽

我们要将num存储到7004节点，因此需要先看看num的插槽是多少：

get num
-> Redirected to slot [2765] located at 192.168.193.141:7001

如上图所示，num的插槽为2765.

我们可以将0~3000的插槽从7001转移到7004，命令格式如下：

reshard host:port
–cluster-from
–cluster-to
–cluster-slots
–cluster-yes
–cluster-timeout
–cluster-pipeline
–cluster-replace

具体命令如下：

建立连接：

[root@centos redissb]# redis-cli --cluster reshard 192.168.193.141 7001

得到下面的反馈：
过程：
How many slots do you want to move (from 1 to 16384)? 3000 //移动多少插槽
What is the receiving node ID? 973d5a034eb1aaa81e800aae490e9674e061c615 //谁来接收 //输入id 7004ID
Please enter all the source node IDs.
Type ‘all’ to use all the nodes as source nodes for the hash slots. //输入done结束
Type ‘done’ once you entered all the source nodes IDs. //从哪里作为数据源来拷贝 输入ID 7001
Source node #1: 65d27fb778680a35adefc0a49b841009a063b5a3 //拷贝
Source node #2: done //结束
Do you want to proceed with the proposed reshard plan (yes/no)? yes

询问要移动多少个插槽，我们计划是3000个：

新的问题来了：

What is the receiving node ID?

那个node来接收这些插槽？？

显然是7004，那么7004节点的id是多少呢？

973d5a034eb1aaa81e800aae490e9674e061c615g)

复制这个id，然后拷贝到刚才的控制台后：

What is the receiving node ID? 973d5a034eb1aaa81e800aae490e9674e061c615

这里询问，你的插槽是从哪里移动过来的？

• all：代表全部，也就是三个节点各转移一部分
• 具体的id：目标节点的id
• done：没有了

这里我们要从7001获取，因此填写7001的id：

Source node #1: 65d27fb778680a35adefc0a49b841009a063b5a3

填完后，点击done，这样插槽转移就准备好了：

Source node #2: done

确认要转移吗？输入yes：

然后，通过命令查看结果：

973d5a034eb1aaa81e800aae490e9674e061c615 192.168.193.141:7004@17004 master - 0 1680612772000 7 connected 0-2999

可以看到：

192.168.193.141:7004@17004 master - 0 1680612772000 7 connected 0-2999

目的达成。

4.4.故障转移

集群初识状态是这样的：

981064ba7a2c6130be11b533c134b023989bf44a 192.168.193.141:7003@17003 master - 0 1680683870000 3 connected 10923-16383
4355b9cb3cce32b2436a3e5476eda26dd0873030 192.168.193.141:7002@17002 master - 0 1680683871667 2 connected 5461-10922
3abf36d9d17ac86ef224cb4d1d8545a36bf8059f 192.168.193.141:8001@18001 slave 65d27fb778680a35adefc0a49b841009a063b5a3 0 1680683871566 1 connected
65d27fb778680a35adefc0a49b841009a063b5a3 192.168.193.141:7001@17001 myself,master - 0 1680683871000 1 connected 3000-5460
973d5a034eb1aaa81e800aae490e9674e061c615 192.168.193.141:7004@17004 master - 0 1680683870658 7 connected 0-2999
00c183fc285137bc905b2fefe1664d88111f5c83 192.168.193.141:8002@18002 slave 4355b9cb3cce32b2436a3e5476eda26dd0873030 0 1680683871566 2 connected
9b9250f8e9ffc36924bf6947f16d6f41a2e8b4df 192.168.193.141:8003@18003 slave 981064ba7a2c6130be11b533c134b023989bf44a 0 1680683871566 3 connected

其中7001、7002、7003都是master，我们计划让7002宕机。

4.4.1.自动故障转移

当集群中有一个master宕机会发生什么呢？

直接停止一个redis实例，例如7002：

redis-cli -p 7002 shutdown

1）首先是该实例与其它实例失去连接

2）然后是疑似宕机：

4355b9cb3cce32b2436a3e5476eda26dd0873030 192.168.193.141:7002@17002 master,fail? - 1680684517508 1680684515000 2 disconnected

3）最后是确定下线，自动提升一个slave为新的master：

4355b9cb3cce32b2436a3e5476eda26dd0873030 192.168.193.141:7002@17002 master,fail - 1680684517508 1680684515000 2 disconnected

4）当7002再次启动，就会变为一个slave节点了：

4355b9cb3cce32b2436a3e5476eda26dd0873030 192.168.193.141:7002@17002 slave 00c183fc285137bc905b2fefe1664d88111f5c83 0 1680684641000 10 connected

4.4.2.手动故障转移

利用cluster failover命令可以手动让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点，实现无感知的数据迁移。其流程如下：

1.salve节点告诉master节点拒绝任何客户端请求
2.master返回当前的数据offset给slave
3.等待数据offset与master一致
4.开始故障转移
5.标记自己为master，广播故障转移的结果
6.收到广播，开始处理客户端读取请求

这种failover命令可以指定三种模式：

• 缺省：默认的流程，如图1~6歩
• force：省略了对offset的一致性校验
• takeover：直接执行第5歩，忽略数据一致性、忽略master状态和其它master的意见

案例需求：在7002这个slave节点执行手动故障转移，重新夺回master地位

步骤如下：

1）利用redis-cli连接7002这个节点

2）执行cluster failover命令

如图：

127.0.0.1:7002> cluster failover
OK

效果：

重回master
4355b9cb3cce32b2436a3e5476eda26dd0873030 192.168.193.141:7002@17002 master - 0 1680685135000 11 connected 5461-10922

4.5.RedisTemplate访问分片集群

RedisTemplate底层同样基于lettuce实现了分片集群的支持，而使用的步骤与哨兵模式基本一致：

1）引入redis的starter依赖

2）配置分片集群地址

3）配置读写分离

与哨兵模式相比，其中只有分片集群的配置方式略有差异，如下：

spring:
  redis:
    cluster:
      nodes:
        - 192.168.193.141:7001
        - 192.168.193.141:7002
        - 192.168.193.141:7003
        - 192.168.193.141:8001
        - 192.168.193.141:8002
        - 192.168.193.141:8003