Redis

Redis是单线程 + 多路IO复用技术

多路复用是指使用一个线程来检查多个文件描述符(Socket)的就绪状态，比如调用select和poll函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行(比如使用线程池)

串行 vs 多线程 + 锁(Memcache) vs 单线程 + 多路IO复用(Redis)

(与Memcache三点不同：支持多数据类型，支持持久化，单线程 + 多路IO复用)

3、常用五大数据类型

3.1、Redis键(key)

keys * 查看当前库所有key (匹配：keys * 1)

exists key 判断某个key是否存在

type key 查看你的key是什么类型

del key 删除指定的key数据

unlink key 根据value选择非阻塞删除，仅将keys从keyspace元数据中删除，真正的删除会在后续异步操作

expire key 10 10秒钟：为给定的key设置过期时间

ttl key 查看还有多少秒过期，-1表示永不过期，-2表示已过期

select 命令切换数据库

dbsize 查看当前数据库的key的数量

flushdb 清空当前库

flush 通杀全部库

3.2、Redis字符串(String)

3.2.1、简介

String是Redis的最基本的数据类型，你可以理解成为Memcache一模一样的类型，一个key对应一个value。

String类型是二进制安全的。意味着Redis的String可以包含任何数据，比如jpg图片或者序列化对象

String类型是Redis最基本的数据类型，一个Redis中字符串value最多可以是512M

3.2.2、常用命令

set <key><value>添加键值对

*NX：当前数据库中key不存在时，可以将key-value添加数据库

*XX：当数据库中key存在时，可以将key-value添加数据库，与NX参数互斥

*EX：key的超时秒数

*PX：key的超时秒数，与EX互斥

get<key>查询对应键值

append <key><value>将给定的<value>追加到原值的末尾

strlen <key>获取值的长度

setnx <key><value>只有在key不存在时，设置key的值

incr <key>将key中储存的数字值增1，只能对数字值操作，如果为空，新增值为1

decr <key>将key中储存的数字值减1，只能对数字值操作，如果为空，新增值为-1

incrby /decrby <key><步长>将key中储存的数字值增减。自定义步长

原子性：INCR key 对存储在指定key的数值执行原子性的加1操作，时间复杂度为O(1)

所谓原子操作是指不会被线程调度机制打断的操作

这种操作一旦开始，就一直运行到结束，中间不会有任何context switch(切换到另一个线程)

（1）在单线程中，能够在单条指令中完成的操作都可以认为是“原子操作”，因为中断只能发生于指令之间

（2）在多线程中，不能被其他进程(线程)打断的操作就叫原子操作

Redis单命令的原子性主要得益于Redis的单线程

mset <key1><value1><key2><value2><key3><value3> ...

同时设置一个或多个key-value对

mget <key1><key2><key3> ...

同时获取一个或多个value

msetnx <key1><value1><key2><value2><key3><value3> ...

同时设置一个或多个key-value对，当且仅当所有给定key都不存在

原子性，有一个失败则都失败

getrange <key><起始位置><结束位置>

获取值的范围，类似java中的substring，前包，后包

setrange <key><起始位置><value>

用于<value>覆写<key>所存储的字符串，从<起始位置>开始(索引从0开始)

setex <key><过期时间><value>

设置键值的同时，设置过期时间，单位秒

getset<key><value>

以旧换新，设置了新值的同时获取旧值

3.2.3、数据结构

String的数据结构为简单动态字符串(String Dynamic String，缩写SDS)。是可以修改的字符串，内部结构实现上类似于Java的ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配

3.3、Redis列表(List)

3.3.1、简介

单键多值

Redis列表是简单的字符串列表，按照插入顺序排序，你可以添加一个元素到列表的头部(左边)或者尾部(右边)

它的底层实际上是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差

3.3.2、常用命令

lpush / rpush <key><value1><value2><value3> ... 从左边/右边插入一个或多个值

lpop / rpop <key>从左边/右边吐出一个值。值在键在，值光键亡。

rpoplpush <key1><key2>从<key1>列表右边吐出一个值，插到<key2>列表左边

lrange <key><start><stop>按照索引下标获得元素(从左到右)

lrange mylist 0 -1 左边第一个，-1右边第一个，(0 -1表示获取所有)

lindex <key><index>按照索引下标获得元素(从左到右)

llen <key>获得列表长度

linsert <key> before <value><newvalue>在<value>的后面插入<newvalue>插入值

lrem <key><n><value>从左边删除n个value(从左到右)

lset <key><index><value>将列表key下标为index的值替换成value

3.3.3、数据结构

List的数据结构为快速链表quickList。

首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是ziplist，也即是压缩列表。

它将所有的元素紧挨着一起存储，分配的是一块连续的内存。

当数据量比较多的时候才会改成quicklist。

因为普通的链表需要附加指针空间太大，会比较浪费时间。比如这个列表里存的只是int类型的数据，结构上还需要两个额外的指针prev和next。

Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除功能，又不会出现太大的空间冗余。

3.4、Redis集合(Set)

3.4.1、简介

Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。

Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表，所以添加，删除，查找的复杂度都是O(1)。

一个算法，随着数据的增加，执行时间的长短，如果是O(1)，数据增加，查找数据的时间不变。

3.4.2、常用命令

sadd <key><value1><value2><value3> ...

将一个或多个member元素加入到集合key中，已经存在的member元素将会被忽略

smembers <key>取出该集合的所有值

sismember <key><value>判断集合<key>是否为含有该<value>值，有1，没有0

scard <key>返回该集合的元素个数

srem <key><value1><value2> ... 删除集合中的某个元素

spop <key>随机从该集合中吐出一个值

srandmember <key><n>随机从该集合中取出n个值。不会从集合中删除

smove <source><destination><value>把集合中一个值从一个集合中移动到另一个集合

sinter <key1><key2>返回两个集合的交集元素

sunion <key1><key2>返回两个集合的并集元素

sdiff <key1><key2>返回两个集合的差集元素(key1中的，不包含key2中的)

3.4.3、数据结构

Set数据结构是dict字典，字典使用哈希表实现的。

3.5、Redis哈希(Hash)

3.5.1、简介

Redis hash是一个键值对集合

Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象

类似Java里面的Map<String,Object>

用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储

主要有以下两种方式存储：

3.5.2、常用命令

hset <key><field><value>给<key>集合中的<field>键赋值<value>

hget <key1><field>从<key1>集合<field>取出value

hmset <key1><field1><value1><field2><value2> .. 批量设置hash的值

hexists <key1><field>查看哈希表key中，给定域field是否存在

hkeys <key>列出该hash集合中的所有field

hvals <key>列出该hash集合的所有value

hincrby <key><field><incrment>为哈希表key中的域field的值加上增量1 -1

hsetnx <key><field><value>将哈希表key中的域field的值设置为value，当且仅当field不存在

3.5.3、数据结构

Hash类型对应的数据结构是两种：ziplist（压缩列表），hashtable（哈希表）。当field-value长度较短且个数较少时，使用ziplist，否则使用hashtable。

3.6、Redis有序集合Zset(sorted set)

3.6.1、简介

Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。

不同之处是有序集合的每个成员都关联一个评分(score)，这个评分(score)被用来按照从最低分到最高分的方式排序集合中的成员。集合中的成员是唯一的，但是评分可以是重复的。

因为元素是有序的，所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。

访问有序集合的中间元素也是非常快的，因此你能够使用有序集合作为一个没有重复成员的智能列表。

3.6.2、常用命令

zadd <key><score1><value1><score2><value2> ...

将一个或多个member元素及其score值加入到有序集key当中。

zrange <key><start><stop> [WITHSCORES]

返回有序集key中，下标在<start><stop>之间的元素

带WITHSCORES，可以让分数一起和值返回到结果集。

zrangebyscore key minmax [withscores] [limit offset count]

返回有序集key中，所有score值介于min和max之间（包括等于min或max）的成员。

有序集成员按score值递增（从小到大）次序排列。

zrevrangebyscore maxmin [withscores] [limit offset count]

同上，改为从大到小排列。

zincrby <key><increment><value>为元素的score加上增量

zrem <key><value>删除该集合下，指定值的元素

zcount <key><min><max>统计该集合，分数区间内的元素个数

zrank <key><value>返回该值在集合中的排名，从0开始

3.6.3、数据结构

SortedSet(zset)是Redis提供的一个非常特别的数据结构，一方面它等价于Java的数据结构Map<String,Double>，可以给每一个元素value赋值一个权重score，另一方面它又类似于TreeSet，内部的元素会按照权重score进行排序，可以得到每个元素的名次，还可以通过score的范围来获取元素的列表。

zset底层使用了两个数据结构

（1）hash，hash的作用就是关联元素value和权重score，保障元素value的唯一性，可以通过元素value找到相应的score值。

（2）跳跃表，跳跃表的目的在于给元素value排序，根据score的范围获取元素列表。

4、Redis的发布和订阅

4.1、什么是发布和订阅

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

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

4.2、Redis的发布和订阅

1、客户端可以订阅频道如下图

2、当给这个频道发布消息后，消息就会发送给订阅的客户端

4.3、发布订阅命令行实现

1、打开一个客户端订阅channel1

SUBSCRIBE channel1

2、打开另一个客户端，给channel1发布消息hello

publish channel1 hello

返回的1是订阅者数量

3、打开第一个客户端可以看到发送的消息

注：发布的消息没有持久化，如果在订阅的客户端接收不到hello，只能收到订阅后发布的消息

5、Jedis操作Redis

1、在linux安装了redis的情况下，在IDEA下创建maven工程，并添加依赖

<!-- jedis操作redis-->
		<dependency>
			<groupId>redis.clients</groupId>
			<artifactId>jedis</artifactId>
			<version>3.2.0</version>
		</dependency>

2、创建Jedis对象及密码验证

    public static void main(String[] args) {
        //创建jedis对象
        Jedis jedis = new Jedis("192.168.16.3",6379);
        //验证密码
        jedis.auth("123456");
        String value = jedis.ping();
        System.out.println(value);
    }

注：连接成功的前提

1、linux服务器防火墙关闭

2、配置文件bind需要注释掉

3、配置文件potected-mode（保护模式）需要设置为no

关闭保护模式及密码设置

模拟验证码发送代码案例

/*
    1、输入手机号，点击发送后随机生成6位数字码，2分钟内有效
    2、输入验证码，点击验证，返回成功或失败
    3、每个手机号每天只能输入3次
     */
    public static void main(String[] args) {

        //模拟验证码发送
        verifyCode("15800000000");

    }


    //1、设置随机的六位数验证码
    public static String getCode(){
        Random random = new Random();
        String code = "";
        for (int i=0;i<6;i++){
            int rand = random.nextInt(6);
            code += rand;
        }
        return code;

    }

    //2、每个手机每天只能发送3次，验证码放到redis中，设置过期时间
    public static void verifyCode(String phone){
        //连接redis
        Jedis jedis = new Jedis("192.168.16.3",6379);
        jedis.auth("123456");

        //拼接key
        //手机发送次数key
        String countKey = "VerifyCode"+phone+":count";
        String codeKey = "VerifyCode"+phone+":code";
        //每个手机每天只能发送3次
        String count = jedis.get(countKey);
        if (count == null){
            //没有发送次数，第一次发送
            //设置发送次数是1
            jedis.setex(countKey,24*60*60,"1");
        }else if (Integer.parseInt(count) <= 2){
            //发送次数 +1
            jedis.incr(countKey);
        }else if(Integer.parseInt(count) > 2){
            //发送3次，不能在发送
            System.out.println("今天发送次数已超过三次，不能再发送了");
            jedis.close();
            return;
        }

        //发送验证码放到redis里面
        String vcode = getCode();
        jedis.setex(codeKey,120,vcode);
        jedis.close();

    }

    //3、验证码校验
    public static void getRedisCode(String phone,String code){
        //从redis中获取验证码
        Jedis jedis = new Jedis("192.168.16.3",6379);
        jedis.auth("123456");
        //验证码key
        String codeKey = "VerityCode"+phone+":code";
        String redisCode = jedis.get(codeKey);
        //判断
        if (redisCode.equals(code)){
            System.out.println("成功");
        }else{
            System.out.println("失败");
        }
    }

6、事务和锁机制

6.1、事务的概述

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其它客户端发送来的命令请求所打断。

Redis事务的主要作用就是串联多个命令防止别的命令插队

6.2、Multi、Exec、discard

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。

组队的过程中可以通过discard。

实例

组队成功，提交成功

组队阶段报错，提交失败

组队成功，提交有成功有失败情况

6.3、事务的错误处理

组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消

如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其它的命令都会执行，不会回滚

6.4、事务冲突问题

6.4.1、实例

一个请求想给金额减8000

一个请求想给金额减5000

一个请求想给金额减1000

6.4.2、悲观锁

悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

6.4.3、乐观锁

乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

6.4.4、WATCH key [key ...]

在执行multi之前，先执行watch key1 [key2]，可以监视一个（或多个）key，如果在事务执行之前这个（或这些）key被其它命令所改动，那么事务将会被打断。

测试：

再开一个窗口，使用两个redis窗口

在一号窗口：

127.0.0.1:6379> set k1 100  
OK 
127.0.0.1:6379> watch k1   #监视k1
OK

然后在二号窗口也监视k1并执行事务

127.0.0.1:6379> watch k1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> incrby k1 10
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 110

然后再去窗口1执行事务

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> incrby k1 20
QUEUED
127.0.0.1:6379(TX)> exec 
(nil)         #因为这个还停留在1.0版本，而我们窗口二改了数据了k1是1.1版本了

在开启事务的时候，在执行前先修改一下信息，就会执行失败，这是watch key的作用

6.4.5、unwatch

取消WATCH命令对所有key的监视

如果在执行WATCH命令之后，EXEC命令或DISCARD命令先被执行了的话，那么就不需要再执行UNWATCH了。

6.5、Redis事务-秒杀案例

源码

源码转载于 https://github.com/TyCoding/springboot-seckill

本想着看完尚硅谷视频自己写一个的，但视频上用到的SSM框架，xml文件配置起来麻烦，所以在GitHub上找到类似Redis秒杀的案例（使用的SpringBoot框架）。

浏览器页面，立即抢购，库存减 1

数据库中的数据

项目启动后，缓存中（Redis中的数据）

7、持久化操作

7.1、持久化操作-RDB

7.1.1、是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

7.1.2、备份是如何执行的

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是特别敏感，那么RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

7.1.3、Fork

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值和原进程一致，但是是一个全新的进程，并作为原进程的子进程
在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后都会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程

7.2、持久化操作-AOF

7.2.1、是什么

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

7.2.2、AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的。

7.2.3、AOF默认不开启

可以在redis.conf中配置文件名称，默认为appendonly.aof

AOF文件的保存路径，同RDB的路径一致。

7.3.4、AOF和RDB同时开启，redis听谁的？

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

7.3.5、AOF启动/修复/恢复

AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝Redis工作目录下，启动系统即加载。

正常恢复

修改默认的appendonly no，改为yes
将有数据的aof文件复制一份保存到对应目录（查看目录：config get dir）
恢复：重启redis然后重新加载

异常恢复

修改默认的appendonly no。改为yes
如遇到AOF文件损坏，通过 /usr/local/bin/redis-check-aof--fix appendonly.aof
备份被写坏的AOF文件
恢复：重启redis，然后重新加载

7.3.6、AOF同步频率设置

appendfsync always

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性较好

appendfsync eyerysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失

appendfsync no

redis不主动进行同步，把同步时机交给操作系统

7.3.7、优势

备份机制更稳健，丢失数据概率更低
可读的日志文本，通过操作AOF稳健，可以处理误操作

7.3.8、劣势

比起RDB占用更多的磁盘空间
恢复备份速度要慢
每次读写都同步的话，有一定的性能压力
存在个别Bug。造成恢复不能

8、主从复制

8.1、主从复制-搭建-一主多从

前提是redis.conf配置文件中appendonly 需要关掉，设置成no，不然AOF也会开启

8.1.1、新建redis6379.conf，填写以下内容

include /myredis/redis.conf
pidfile "/var/run/redis_6379.pid"
port 6379
dbfilename "dump6379.rdb"

8.1.2、新建redis6380.conf，填写以下内容

include /myredis/redis.conf
pidfile "/var/run/redis_6380.pid"
port 6380
dbfilename "dump6380.rdb"

8.1.3、新建redis6381.conf，填写以下内容

include /myredis/redis.conf
pidfile "/var/run/redis_6381.pid"
port 6381
dbfilename "dump6381.rdb"

8.1.4、启动三个Redis服务

redis-server redis6379.conf
redis-server redis6380.conf
redis-server redis6381.conf

8.1.5、查看三台主机运行情况

info replication

打印主从复制的相关信息

这里已经提前配置好主服务器了，主服务器是6381，下面会说明如何配置主服务器。

8.1.6、配从（库）不配主（库）

slaveof <ip><port>

成为某个实例的从服务器

1、在6380和6381上执行：slaveof 127.0.0.1 6379

如果从服务器宕机了，后面重新启动从服务器，重新启动的服务器会升级为主服务器，那么就需要重新将重启后的服务器设置为从服务器，数据会在主服务器中从头复制到从服务器中。

如果主服务宕机了，那么从服务器不做任何事情，还是认这台已经挂掉的做主服务器，而主服务器重启之后，还是做主服务器。

主从复制原理

1、slave启动成功连接到master后会发送一个sync命令

2、Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据命令，在后台进程执行完毕之后，master将传送整个文件到slave，以完成一次完全同步

全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中

增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步

但是只要重新连接master，一次完全同步（全量复制）将被自动执行

8.1.7、薪火相传与反客为主实现

概念：

1、薪火相传：主机a有一台从机b，同时从机b有一台从机c，这时候从机b相对于从机c来说就是主机，也就是一个接一个

2、反客为主：主机挂掉了，从机可以变成主机

反客为主用法：（手动执行）

slaveof no one

即主机挂掉以后，从机变为主机

缺点：手动完成

解决缺点：自动完成需要用到哨兵模式

测试：（这里就不用代码展示了）

现在6380端口要作为6379的从机：slaveof 127.0.0.1 6379 （在6380的端口服务器上执行）

现在6381端口要作为6380的从机：slaveof 127.0.0.1 6380 （在6381的端口服务器上执行）

现在即为：薪火相传模式

info replication 查看状态

6379端口执行shutdown

6379挂掉之后6380还是从机状态

现在在6380端口执行：slaveof on one，6380变成了主机，同时6381还是从机

这就是反客为主

8.2、主从复制-哨兵模式

8.2.1、是什么？

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

8.2.2、怎么玩？

1、调整为一主二仆模式，6379带着6380、6381

将6379端口设置为主库，在6380和6381的端口上执行slaveof 127.0.0.1 6379即可实现下图效果

2、自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错

3、配置哨兵，填写内容

sentinel monitor mymaster 127.0.0.1 6379 1

其中mymaster为监控对象起的服务器名称，1为至少有多少个哨兵同意迁移的数量

4、启动哨兵

执行 redis-sentinel /myredis/sentinel.conf

当主机挂掉了，从机选举中产生新的主机

（大概10秒左右可以看到哨兵窗口日志，切换了新的主机）

哪个从机会被选举为主机呢？根据优先级别：replica-priority

原主机重启后会变成从机

当挂掉的主机重启之后，会作为从机使用

回到6381的端口上，可以看到重启之后的服务器作为从机使用

8.2.3、复制延时

由于所有的写操作都是现在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

8.2.4、从库选举规则

选择条件依次为：

1、选择优先级靠前的

优先级在redis.conf中默认：replica-priority 100，值越小优先级越高

2、选择偏移量最大的

偏移量是指获得原主机数据最全的，从机和主机的同步数据谁更多，选举谁，如果两个从机的数量同步量是一样的，那考虑第三种

3、选择runid最小的从服务

每个redis实例启动后都会随机生成一个40位的runid，这个就是随机的情况

9、Redis集群

9.1、问题

容量不够，redis如何进行扩容？

并发写操作，redis如何分摊？

另外，主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。

之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置。

代理主机：以一个电商系统为例，电商系统有很多模块，比如用户模块、订单模块、商品模块，客户端请求数据，如果没有加入代理主机方式，那么客户端发送请求时就不知道请求的是哪个模块，这时候就需要通过代理主机的方式，客户端发送请求，代理主机确认客户端发送的请求去请求相对应的模块，最后返回数据给客户端。

无中心化集群：之前介绍的主从模式和哨兵模式都只有一个master主节点，如果写操作并发比较大时，这两个模式就会堵塞。这时就可以使用集群化模式，也称之为去中心化模式，其特点是多master和多slave。

去中心化的原理为：Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，redis 会先对 key 使用 crc16 算法算出一个结果，然后将结果对 16384 求余，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点上。当你往Redis Cluster中加入一个Key时，会根据 crc16(key) mod 16384计算这个 key 应该分布到哪个 hash slot 中，一个hash slot 中会有很多key和value。你可以理解成分区，使用单节点时的redis时只有一个表，所有的key都放在这个表里，当改用Redis Cluster以后会自动为你生成16384个分区表，写入数据时会根据上面的算法来决定你的 key 应该存在哪个分区。

任何一台服务器都可以作为集群的入口，模块之间是联通的状态。

9.2、什么是集群

Redis集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。

Redis集群通过分区（partition）来提供一定集群的可用性（availability）：即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。

9.3、搭建Redis集群

9.3.1、将持久化数据rdb，aof的文件都删除掉

9.3.2、制作6个实例，6379，6380，6381，6389，6390，6391

6379是6389的主机，6389作为6379的从机

6380是6390的主机，6390作为6380的从机

6381是6391的主机，6391作为6381的从机

9.3.3、redis cluster配置修改

cluster-enabled yes 打开集群模式

cluster-config-file nodes-6379.conf 设定节点配置文件名

cluster-node-timeout 15000 设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换

include /myredis/redis.conf
pidfile "/var/run/redis_6379.pid"
port 6379
dbfilename "dump6379.rdb"
dir "/myredis/redis_cluster"
logfile "/myredis/redis_cluster/redis_err_6379.log"
cluster-enabled yes 
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000

9.3.4、修改好redis6379.conf文件之后，拷贝多个redis.conf文件

9.3.5、后面将配置文件中的端口号改成对应的端口号，最后:wq!退出。

9.3.6、启动这六台服务，在/myredis目录下执行 redis-server 文件名字(redis6379.conf)，因为在每个配置文件中加了集群的配置，所以启动之后会自动生成节点配置文件(nodes-端口.conf)和持久化文件(dump端口号.rdb)。

9.3.7、将六个节点合成一个集群

组合之前，请确保所有redis实例启动后，nodes-xxxx.conf文件都生成正常。

合体：cd /usr/local/redis-6.2.7/src

在redis的安装目录使用该指令

redis-cli --cluster create --cluster-replicas 1 192.168.16.3:6379 192.168.16.3:6380 192.168.16.3:6381 192.168.16.3:6389 192.168.16.3:6390 192.168.16.3:6391

此处不要用127.0.0.1，请用真实IP地址

--replicas 1 采用最简单的方式配置集群，一台主机，一台从机，正好三组

如果某个存在redis服务中有数据，那么在启动集群的时候会报错。

9.3.8、普通方式登录

可能直接进入读主机，存储数据时，会出现MOVED重定向操作。所以，应该以集群的方式登录

9.3.9、 -c 采用集群策略连接，设置数据会自动切换到相应的写主机

9.3.10、通过cluster nodes 命令查看集群信息

9.3.11、redis cluster如何分配这六个节点？

一个集群至少要有三个主节点。

选项--cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。

9.4、集群操作和故障恢复

9.4.1、什么是slots

一个Redis集群包含16384个插槽（hash slot），数据库中的每个键都属于这16384个插槽中的其中一个

集群使用公式CRC16(key) % 16384来计算键key属于哪个插槽，其中CRC16(key)语句用于计算键key的CRC16校验和

集群中的每个节点负责处理一部分插槽。举个例子，一个集群可以有主节点，其中：

节点 A 负责处理 0 号至 5460 号插槽

节点 B 负责处理 5461 号至 10922 号插槽

节点 C 负责处理 10923 号至 16383 号插槽

9.4.2、在集群中录入值

在redis-cli每次录入、查询键值，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。

redis-cli客户端提供了 -c 参数实现自动重定向

如redis-cli -c -p 6380 登入后，再录入、查询键值对可以自动重定向。

不在一个slot下的键值，没办法计算插槽的位置，是不能使用mget，mset等操作

可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去

9.4.3、查询集群中的值

CLUSTER GETKEYSINSLOT <slot><count> 返回count个slot槽中的键

只能看自己插槽上的值，别的插槽上的值看不到

9.4.4、故障恢复

如果主节点下线？从节点能否自动升为主节点？注意：15秒超时

主节点恢复后，主从关系会如何？主节点回来变成从机

如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续？

如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为 yes，那么，整个集群都挂掉。

如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为 no，那么，该插槽数据全部都不能使用，也无法存储。

redis.conf中的参数 cluster-require-full-coverage

9.5、集群的Jedis开发

即使连接的不是主机，集群会自动切换主机存储。主机写，从机读。

无中心化主从集群。无论从哪台主机写的数据，其它主机上都能读到数据。

    /**
     * 演示redis集群操作
     * @param args
     */
    public static void main(String[] args) {
        //创建对象
        HostAndPort hostAndPort = new HostAndPort("192.168.16.3", 6379);
        JedisCluster jedisCluster = new JedisCluster(hostAndPort);
        //进行操作
        jedisCluster.set("liufang","12");
        String value = jedisCluster.get("liufang");
        System.out.println("value："+value);
        jedisCluster.close();
    }

9.6、Redis集群提供了以下好处

1、实现扩容

2、分摊压力

3、无中心配置相对简单

9.7、Redis集群的不足

1、多键操作是不被支持的

2、多键的Redis事务是不被支持的。lua脚本不被支持

3、由于集群方案出现较晚，很多公司已经采用了其它的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

10、应用问题解决

10.1、缓存穿透

10.1.1、问题描述

key对应的数据在数据源并不存在，每次针对此key的请求从缓存中获取不到，请求都会压倒数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

10.1.2、解决方案

一个一定不存在缓存及查询不到的数据，由于缓存中不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

解决方案：

（1）对空值缓存：如果一个查询返回的数据为空（不管是数据是否存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最多不超过五分钟。

（2）设置可访问的名单（白名单）：使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmaps里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

（3）采用布隆过滤器：（布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量（位图）和一系列随机映射函数（哈希函数））。

布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。

（4）进行实时监控：当发现Redis中的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务。

10.2、缓存击穿

10.2.1、问题描述

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

10.2.2、解决方案

key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。

解决问题：

（1）预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长

（2）实时调整：现场监控哪些数据热门，实时调整key的过期时长

（3）使用锁：

（1）就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。

（2）先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX），去set一个mutex key

（3）当操作返回成功时，再进行load db的操作，并回设缓存，最后删除mutex key；

（4）当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

10.3、缓存雪崩

10.3.1、问题描述

key对应的数据存在，但在redis中过期，此时若大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

缓存雪崩与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key

正常访问

缓存失效瞬间

10.3.2、解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕！

解决方案：

（1）构建多级缓存架构：nginx缓存 + redis缓存 + 其它缓存（ehcache等）

（2）使用锁或队列：

用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况

（3）设置过期标志更新缓存：

记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。

（4）将缓存失效时间分散开：

比如我们可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

10.4、分布式锁（设置锁和过期时间）

10.4.1、问题描述

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

分布式锁主流的实现方案：

1、基于数据库实现分布式锁

2、基于缓存（Redis等）

3、基于Zookeeper

每一种分布式锁解决方案都有各自的优缺点：

1、性能：redis最高

2、可靠性：zookeeper最高

这里，我们就基于redis实现分布式锁。

10.4.2、解决方案

使用redis实现分布式锁

redis:命令

#set sku:1:info "OK" NX PX 10000

EX second：设置键的过期时间为second秒。SET key value EX second 效果等同于

SETEX key second value 。

PX millisecond：设置键的过期时间为millisecond毫秒。SET key value PX

millisecond 效果等同于 PSETEX key millisecond value 。

NX：只在键不存在时，才对键进行设置操作。SET key value NX 效果等同于SETNX key value

XX：只在键已经存在时，才对键进行设置操作。

1、使用setnx上锁，通过del释放锁

2、锁一直没有释放，设置key的过期时间，自动释放

3、上锁之后突然出现异常，无法设置过期时间了，可以通过上锁的同时设置过期时间

10.5、分布式锁（UUID防止误删）

10.5.1、代码实现

    @RequestMapping("/testLock")
    public void  testLock() {
        /*获取锁*/
        Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "1");
        /*获取锁成功*/
        if(lock){
            Object num = redisTemplate.opsForValue().get("num");
            if(StringUtils.isEmpty(num)){
                return ;
            }
            int count = Integer.parseInt(num+"");
            redisTemplate.opsForValue().set("num",++count);
            /* 释放锁，del*/
            redisTemplate.delete("lock");
        }else {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }

    }

对比代码是没问题的，找了一天没找问题出现在哪。那我就发他们成功拿到锁的案例图吧。

在这里插入图片描述

基本实现。

问题：setnx刚好获取到锁，业务逻辑出现异常，导致锁无法释放

解决：设置过期时间，自动释放锁

10.5.2、优化之设置锁的过期时间

设置过期时间有两种方式：

1、首先可以通过expire设置过期时间（缺乏原子性：如果在setnx和expire之间出现异常，锁也无法释放）

2、上锁的同时设置过期时间（推荐）

问题：可能会释放其它服务器的锁

场景：如果业务逻辑的执行时间是7s。执行流程如下

1、index1 业务逻辑没执行完，3秒后锁被自动释放

2、index2 获取到锁，执行业务逻辑，3秒后锁被自动释放

3、index3 获取到锁，执行业务逻辑

4、index1 业务逻辑执行完成，开始调用del释放锁，这时释放的是 index3 的锁，导致index3的业务只执行1s就被别人释放

最终等于没锁的情况。

解决：setnx获取锁时，设置一个指定的唯一值（例如：uuid）；释放前获取这个值，判断是否自己的锁

10.5.3、优化之UUID防误删

弊端：

index1 在释放锁的过程中，会判断uuid是否一样，如果一样，那么就进行删除操作，但在删除的时候，锁刚好到了过期时间，那么index2 就拿到了锁，最后index1 在做删除的时候，就直接删除了index2 的锁，缺乏删除原子性操作。

10.6、分布式锁（LUA保证删除原子性）

问题：删除操作缺乏原子性

场景：

1、index1 执行删除时，查询到的lock值确实和uuid相等

uuid = v1

set(lock,uuid);

2、index1 执行删除前，lock刚好过期时间已到，被redis释放

在redis中没有了lock，没有了锁

3、index2 获取了lock

index2 线程获取到了cpu的资源，开始执行方法

uuid = v2

set(lock,uuid);

4、index1 执行删除，此时会把index2的lock删除

index1 因为已经在方法中了，所以不需要重新上锁。index1 有执行的权限。index1 已经比较完成了，这个时候，开始执行

删除的 index2 的锁！

解决：

 @GetMapping("testLockLua")
    public void testLockLua() {
        //1 声明一个uuid ,将做为一个value 放入我们的key所对应的值中
        String uuid = UUID.randomUUID().toString();
        //2 定义一个锁：lua 脚本可以使用同一把锁，来实现删除！
        String locKey = "lock"; 

        // 3 获取锁
        Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid, 3, TimeUnit.SECONDS);

        // 第一种： lock 与过期时间中间不写任何的代码。
        // redisTemplate.expire("lock",10, TimeUnit.SECONDS);//设置过期时间
        // 如果true
        if (lock) {
            // 执行的业务逻辑开始
            // 获取缓存中的num 数据
            Object value = redisTemplate.opsForValue().get("num");
            // 如果是空直接返回
            if (StringUtils.isEmpty(value)) {
                return;
            }
            // 不是空 如果说在这出现了异常！ 那么delete 就删除失败！ 也就是说锁永远存在！
            int num = Integer.parseInt(value + "");
            // 使num 每次+1 放入缓存
            redisTemplate.opsForValue().set("num", String.valueOf(++num));
            /*使用lua脚本来锁*/
            // 定义lua 脚本
            String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
            // 使用redis执行lua执行
            DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
            redisScript.setScriptText(script);
            // 设置一下返回值类型 为Long
            // 因为删除判断的时候，返回的0,给其封装为数据类型。如果不封装那么默认返回String 类型，
            // 那么返回字符串与0 会有发生错误。
            redisScript.setResultType(Long.class);
            // 第一个要是script 脚本 ，第二个需要判断的key，第三个就是key所对应的值。
            redisTemplate.execute(redisScript, Arrays.asList(locKey), uuid);
        } else {
            // 其他线程等待
            try {
                Thread.sleep(1000);
                testLockLua();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }