Redis

Redis（数据库、缓存、消息中间件MQ）

一、介绍、安装

应用场景：

1.配合关系型数据库做高速缓存

1. 高频次，热门访问的数据，降低数据库IO操作
2. 分布式架构，做session共享

2.由于其拥有持久化的能力，利用其多样的数据结构存储特定的数据

最新N个数据	通过List实现暗自然时间排序的数据
排行榜，Top N	利用zset（有序集合）
时效性的数据，如手机验证码	Expire 过期
计数器，秒杀	原子性，自增方法INCR、DECR
去除大量数据中的重复数据	利用set集合
构建队列	利用List集合
发布订阅消息系统	pub/sub模式

基本操作

select 3  #切换数据库

DBSIZE  #查看数据库的大小

key *  #查看当前数据库所有的key

flushdb  #清空当前数据库

flushall #清空全部数据库所有的数据

set age 1  #设置键值对 

exists name #判断当前的key是否存在

move name #移除当前的key

expire name 10  #设置key的过期时间，单位是秒

ttl name #查看当前key的剩余时间

get name #获取一个key的值

type name #查看当前key的类型

Redis是单线程的！！！

​ 基于内存操作，CPU不是其性能的瓶颈,瓶颈是根据机器的内存和网络带宽，既然可以使用单线程来实现，就使用单线程了！！！

Redis为什么单线程还这么快？？？

1.误区1：高性能的服务器一定是多线程的

2.误区2：多线程（CPU上下文会切换！！！）一定比单线程效率高！！！

核心：

​ Redis是将所有的数据全部放在内存中的，所有说使用单线程去操作效率就是最高的，多线程（CPU上下文切换：耗时的操作！！！），对于内存系统来说，如果没有上下文切换，那么效率就是最高的，多次读写都在一个线程上的，在内存情况下，这就是最佳的方案。

二、五大数据类型

Redis-key

String（字符串）

1.String类型的基本操作

append name "追加的字符串"   #追加字符串，返回结果为结果字符串的总长度，如果该key的不存在，则直接新建

strlen  name  #获取当前key的字符串长度

incr name #增加一次

incrby name "增加的次数"  #增加？次

decr name #减少一次

decrby name "减少的次数"  #减少？次

getrange name 0 3 #截取当前key对应的字符串值，0-3的值

getrange name 0 -1 #查看当前key对应的字符串所有的值

setrange name 1 "替换的字符串内容" #替换指定位置开始的字符串

setex (set with expire)  #设置过期时间

setex name 30 "hello world"  #设置key的值为hello world ，30秒后过期

setnx (set if no expire)  #不存在设置（在分布式锁中常常使用）

setnx name "redis"  #如果key不存在，创建key ,如果存在，则创建失败（分布式锁）

mset k1 v1 k2 v2 #批量设置键值对 ， k1 = v1  ， k2 = v2

mget k1 k2 #批量获取值（通过key）

msetnx k1 v1 k4 v4 #批量进行不存在设置，如果其中有一个或以上的值已经存在，则设置失败！！！，无法保证原子性操作！！！

#对象

#这里的key是一个巧妙的设计，user:{id}:{name}，如此设计在redis中是可以的

set user:1 {name:zhangsan,age:3} #设置一个user:1 对象，值为json字符串来保存一个对象

mset user:1:name zhangsan user:1:age 2  #批量设置一个对象中的多个属性

mget user:1:name user:1:age #批量获取一个对象中的多个属性


getset  value1 value2 #先获取该值，再设置该值 。如果不存在值，则返回null  ！！！    如果存在值，获取原来的值，并设置新的值！！！

2.String类型的应用场景

​ value除了是字符串还可以是数字！！！

1. 计数器
2. 统计多单位的数量
3. 粉丝数
4. 对象缓存存储

List（列表）

​ 在redis中，List可以为栈、队列、阻塞队列

1.List类型的基本操作

#所有的list命令都是以l开头的

LPUSH list "值"   #从头部向list插入值（左）

RPUSH list "值"   #从尾部向list插入值(右)

LRANGE  list 0 -1  #获取list中所有的值

LRANGE list 0 3    #获取list中0-3的值

LPOP  list  #移除当前list头部的值

Rpop list  #移除当前list的最后一个值

lindex list 1 #通过下标获取list中的某个值

Llen lts  #获取当前list的长度

Lrem list 1 one #移除当前list中指定的值，精确匹配

ltrim list 1 2  #通过下标截取指定的长度，这个list已经改变了

rpoplpush list1 list2  #移除list中的最后一个元素，并将其移动到新的list中

lset list 0 hello #将list中指定下标的值替换为另外一个值

linsert list before "1" "2" #在指定值后面插入一个值

2.List小结

1. 其实际上是一个链表，before node after left right 都可以插入值
2. 如果key不存在，创建新的链表
3. 如果key存在，新增内容
4. 如果移除了所有制，空链表，代表不存在！！！
5. 在两边插入或改动值，效率最高！中间元素，相对来说效率会低一点。

消息排队！消息队列（Lpush Rpop），栈（Lpush Lpop）

Set（无序不重复集合）

Set中的值是不能重复的！！！

1.Set的基本操作

Sadd myset "helloworld!!!" #新增一个元素

smembers myset #查看集合中的所有值

sismember myset "hello" #判断该集合中是否存在该值，返回 0 为不存在，返回 1 为存在。

scard myset #获取当前集合中的元素个数

srem myset "helloworld" #移除当前集合中的指定元素

spop myset  #随机移除当前集合中的一个值

srandmember myset #从当前集合中随机抽选出一个值

srandmember myset 指定个数  #从当前集合中随机抽选出指定个数值

smove myset1 myset2 "值" #移动指定的元素到另一个集合中

#共同关注（并集）
数字集合类
-- 差集  sdiff  key1 key2
-- 交集  sinter key1 key2 #共同好友就可以这样实现
-- 并集  sunion key1 key2

微博，A用户将所有关注的人放在一个set集合中，将他的粉丝也放在一个集合中！

共同关注、共同爱好、共同好友、推荐好友(六度分割理论)

Hash（哈希表、Map集合）

Map集合，key-map ，这时候这个值是一个map集合！本质和String类型没有太大的区别，还是简单的key-value

hset myhash key1 "值"  #存入一个键值对

hget myhash key1 #通过key获取对应的值

hmset myhash key1 "值1" key2 "值2"  #同时存入多个键值对

hmget myhash key1 key2 #通过key同时获取多个值

hgetall myhash #获取所有的值，以键值对的形式展示

hdel myhash key1 #移除hash指定的key字段，对应的值也没有了

hlen myhash  #获取当前hash表的字段数量

hexists myhash key1 #判断该key字段是否存在于hash表中

hkeys myhash #只获取所有的key字段

hvals myhash #只获取所有的value值

hincrby myhash key1 1

hsetnx myhash key1 hello #如果键值对不存在，可以设置


hsetnx myhash key2 world #如果键值对存在，不可以设置

2.hash应用场景

hash变更的数据 user name age，尤其是用户信息之类的，经常变动的信息！

hash更适合于对象的存储，String更适合于存储字符串

Zset（有序集合）

在Set的基础上，增加了一个值，

1.Zset的基本操作

zadd myset 1 one #新增一个值

zadd myset 2 two 3 three #新增多个值

zrange myset 0 -1 #查看所有的值

zrangebyscore salary -inf +inf #从小到大排序

zrangebyscore salary -inf +inf withscore #从小到大排序，并且附带值

zrem myset key1 #移除指定元素

zcard myset  #获取集合中元素的个数

zrevrange myset 0 -1 #从大到小排序

zcount myset 1 3 #获取指定区间的成员数量

2.Zset应用场景

三种特殊数据类型

geosptial（地理空间）

朋友的定位，附近的人，打车距离

1.geosptial基本操作

Geoadd 添加地理位置

#geoadd 添加地理位置
#规则：两极无法直接添加，。一般会下载城市数据，直接通过java一次性导入
#参数：key 值（纬度、经度、名称）
#有效的经度：-180度至180度
#有效的纬度：-85.05112878度到85.05112878
geoadd china:city 116.40 39.90 beijing

Geopos #获取指定城市的经纬度

获取当前定位：一个坐标值

geopos china:city beijing

geolist #两个坐标点主键的距离

geolist china:city beijing shanghai km  #北京到上海的直线距离km

georadius 以给定的经纬度为中心，找出某个半径的元素

我附近的人？（获取所有附近的人的地址、定位！）

georadius china:city 110 30 100km #查询经纬度100km半径之内的所有元素

georadius china:city 110 30 100km withdist  #显示到中心位置的距离

georadius china:city 110 30 100km withcoord #显示他人的定位信息

georadius china:city 110 30 100km withdist withcoord count 1 #筛选出指定的结果

georadiusbymember #找出位于指定元素周围的其他元素

georadiusbymember china:city beijing 1000km

geohash #返回一个或多个位置元素的Geohash表示

该命令将返回11个字符的Geohash字符串！！！

#将二维的经纬度转换为一维的字符串信息，如果两个字符串越接近，那么则距离越近
geohash china:city beijing shanghai  #返回两城市经纬度的字符串形式

GEO底层的实现原理其实就是Zset！！！

我们也可以使用Zset命令来操作geo！！！

zrem china:city beijing #移除指定城市的地理位置信息

hyerloglog（数据结构，错误率0.81%）

用于基数统计的算法

优点：占用的内存是固定的

网页的UV（一个人访问一个网站多次，但是还是算作一个人）

传统的方式：set保存用户的id，然后就可以统计set中的元素数量作为标准判断！

这个方式如果保存大量的用户id，就会比较麻烦！我们的目的是为了计数，而不是保存用户id。

1.hyerloglog基本操作

pfadd mykey a b c d e f g h i j   #创建第一组数据

pfcount mykey  #统计当前的基数数量

pfmerge mykey3 mykey1 mykey2  #合并两组数据集

bitmaps(位图)

位存储(0101)

bitmaps(位图)，数据结构！！！

都是操作二进制来进行记录，就只有0和1两个状态

1.bitmaps基本操作

setbit sign 0 0   #新增第一个key的值

getbit sign 0 #查看指定key的value

bitcount sign #统计bitmaps中value为1的数量

2.应用场景

1. 统计用户信息
2. 用户的活跃度
3. 用户的登录情况
4. 打卡
5. 两个状态的转换的场景，都可以使用bitmaps

三、SpringBoot整合Redis

SpringBoot操作数据：spring-data jpa jdbc mongdb redis！！！

SpringData也是和SpringBoot齐名的项目

说明：在SpringBoot 2.x 之后，原来的jedis被替换为了lettuce？？？

jedis

采用的是直连的方式，多线程操作的话，是不安全的，如果想要避免不安全的，使用jedis pool 连接池！！！ 更像BIO模式

lettuce

采用netify（异步请求），实例可以在多线程中进行共享，不存在线程不安全的情况！！！

可以减少线程数据，更像NIO模式

1.整合测试

1.1 pom

<dependencies>
        <!--    springboot 启动器 start    -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>
        <!--    springboot 启动器 end     -->

        <!--    redis 连接 start   -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
        <!--    redis 连接 end     -->

        <!--   web组件 start     -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <!--   web组件 end       -->

        <!--   热部署工具 start     -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
        </dependency>
        <!--   热部署工具 end       -->
    </dependencies>

1.2 配置连接

spring:
  redis:
    host: localhost
    port: 6379

1.3 测试

1.4自定义的Redis配置类

package cn.qf.configuration;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;

import java.net.UnknownHostException;

/**
 * @author cxf
 * @date 2020/10/9 8:40
 * @msg Redis配置类
 */

@Configuration
public class RedisConfiguration {

    //自定义的redisTemplate
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) throws UnknownHostException {

        RedisTemplate<String, Object> template = new RedisTemplate<>();

        template.setConnectionFactory(redisConnectionFactory);

        return template;
    }
}

四、Java的客户端Jedis

我们要使用java来操作Redis

1.什么是Jedis？

是Redis官方推荐的Java连接开发工具！

使用Java操作Redis的中间件！

2.测试

1.pom

<dependencies>
            <!--  导入jedis的依赖  -->
            <dependency>
                <groupId>redis.clients</groupId>
                <artifactId>jedis</artifactId>
                <version>3.2.0</version>
            </dependency>

            <!--    fastjson  start        -->
            <dependency>
                <groupId>com.alibaba</groupId>
                <artifactId>fastjson</artifactId>
                <version>1.2.62</version>
            </dependency>
            <!--    fastjson  end        -->
        </dependencies>

2.连接redis

package cn.qf.jedis;

import redis.clients.jedis.Jedis;

/**
 * @author cxf
 * @date 2020/10/8 15:22
 * @msg 测试连接redis
 */
public class TestPing {
    public static void main(String[] args) {

        //1.new Jedis对象
        Jedis jedis = new Jedis("127.0.0.1",6379);

        //2.测试连接
        String ping = jedis.ping();

        System.out.println(ping);

    }
}

3.事务

package cn.qf.jedis;

import com.alibaba.fastjson.JSONObject;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.Transaction;

/**
 * @author cxf
 * @date 2020/10/8 15:30
 * @msg 事务
 */
public class TestTX {

    public static void main(String[] args) {
        Jedis jedis = new Jedis("127.0.0.1", 6379);

        JSONObject jsonObject = new JSONObject();

        jsonObject.put("username", "张三");
        jsonObject.put("password", "123456");

        //将json对象转换为json字符串
        String result = jsonObject.toJSONString();

        Transaction multi = jedis.multi();//开启事务

        try {
            //命令加入队列
            multi.set("key1", result);
            multi.set("key2", result);
            //执行命令
            multi.exec();
        } catch (Exception e) {
            e.printStackTrace();
            //放弃事务
            multi.discard();
        } finally {

            //获取执行成功的结果值
            System.out.println(jedis.get("key1"));
            System.out.println(jedis.get("key2"));
            jedis.close();  //关闭连接
        }


    }
}

五、事务

Redis的单条命令是保证原子性的，但是事务不保证原子性！！！

Redis 事务的本质：一组命令的集合，一个事务中的所有命令都会被序列化，在事务执行过程中，会按顺序执行，一次性、顺序性、排他性！执行一系列的命令

Reids事务中没有隔离级别的概念

1.Reids的事务

1.开启事务（multi）

2.命令入队（…）

3.执行事务（exec）

正常执行事务！！！

multi   #开启事务

#命令入队
set k1 v1

set k2 v2

get k2

#执行事务
exec

放弃事务！！！

multi   #开启事务

#命令入队
set k1 v1

set k2 v2

get k2

#取消事务
discard

编译型异常（代码有问题！命令有错！），事务中的所有命令都不会被执行！！！

运行时异常，如果事务队列中存在语法性错误，那马执行命令的时候，其他命令时可以整除执行的，错误命令则抛出异常！！！

监控 watch

悲观锁：

​ 认为什么时候都会出现问题，无论做什么都加锁！

乐观锁：

1. 认为什么时候都不会出现问题，所有不会上锁，更新数据的时候去判断一下，在此期间是否有人修改过这个数据
2. 获取version
3. 更新的时候比较version

2.Redis的监控测试（watch当乐观锁操作）

#单线程！！！

set money 1000

set out 0

watch money  #监控money对象

multi  #事务正常结束，数据期间没有发生变动，这个时候正常执行成功！！！

decrby money 20

increby out 20

exec  

六、Redis.config详解

启动时，通过配置文件来启动

bind 127.0.0.1      #绑定的ip地址

protected-mode yes  #保护模式

port 6379            #端口设置

daemonize no         #以守护进程的方式运行，默认是no，我们需要自己开启为yes

supervised no        #管理守护进程

pidfile /var/run/redis.pid   #如果以后台的方式运行，就需要指定一个pid文件

# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)
loglevel notice       #日志级别  生产环境使用

logfile ""            #日志文件的存放位置

database 16           #数据库的数量，默认是16个数据库

always-show-logo yes  #是否总是显示logo

快照 RDB的设置

持久化，在规定的时间内，执行了多少次操作，则会持久化到文件(RDB、AOF)

redis是内存数据，如果没有持久化，断电就会导致数据丢失

save 900 1   #如果900秒内，如果至少一个key进行了修改，就进行持久化操作
save 300 10   #如果300秒内，如果至少10个key进行了修改，就进行持久化操作
save 60 10000  #如果60秒内，如果至少10000个key进行了修改，就进行持久化操作（高并发）

stop-writes-on-bgsave-error yes  #持久化如果出错，redis是否需要继续工作

rdbcompression yes   #是否压缩rdb文件，需要消耗cpu资源

rdbchecksum yes      #保存RDB文件的时候，进行检查和校验

dir ./               #rdb文件保存的目录

安全

config get requirepass            #获取redis的密码

config set requirepass "123456"   #设置redis的密码

auth 123456                       #使用密码进行登录

限制

maxclients 10000             #设置redis客户端的最大连接数

maxmemory  <bytes>           #设置最大的内存容量

maxmemory-policy noeviction  #内存达到上限之后的处理策略
	# maxmemory-policy 六种方式
    1、volatile-lru：只对设置了过期时间的key进行LRU（默认值） 

    2、allkeys-lru ： 删除lru算法的key   

    3、volatile-random：随机删除即将过期key   

    4、allkeys-random：随机删除   

    5、volatile-ttl ： 删除即将过期的   

    6、noeviction ： 永不过期，返回错误

APPEND ONLY MODE 模式 AOF配置

appendonly no          #默认不开启AOF模式，默认使用RDB模式，因为在大多数的情况下，RDB模式完全够用了

appendfilename "appendonly.aof"   #持久化的文件的名字

# appendfsync always  #每次修改都会sync，速度慢，消耗性能
appendfsync everysec  #每秒都执行一次sync，可能会丢失这1s内的数据！！！
# appendfsync no      #不执行sync，这个时候操作系统自己同步数据，速度最快！！！

no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

aof-load-truncated yes

七、持久化(RDB、AOF)

​ Redis是内存的数据库，如果不将内存中的数据库状态保存到硬盘中，一旦服务器进程退出，服务器中的数据库状态也会消失，所以Redis提供了持久化的功能！！！

1.RDB（Redis DataBase）

1.什么是RDB

在主从复制中，RDB就是备用的！！！

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

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

	RDB的缺点：在最后一次持久化后的数据可能会丢失！！！
	
	一般情况下不需要修改配置！！！

2.RDB配置

dbfilename dump.rdb   #设置生成的临时文件的名称

#触发RDB机制的条件
    #1.save的规则满足的情况下，hi自动触发RDB规则
    save 900 1       #在900秒内，至少一个key修改了
    save 300 10      #在300秒内，至少10个key修改了
    save 60 10000    #在60秒内，至少10000个key修改了（高并发）
    
    #2.执行了flushall命令，也会触发RDB！！！
    flushall
    
    #3.退出Redis的时候也会产生RDB文件
  
 备份就会自动生成一个dump.rdb文件

 如果恢复RDB文件？
 1.只需要将RDB文件放在Redis的启动目录下就可以了，Redis启动的时候就会自动检查dump.rdb，恢复其中的数据！！！
 2.查看需要存在的位置
 dir ./  #设置rdb文件存放的位置

3.优点

1. 适合大规模的数据恢复！
2. 如果对数据的完整性要求不高！

4.缺点

1. 需要一定的时间间隔
2. 如果Redis意外宕机了，最后一次修改的数据就可能没有了
3. Fork进程的时候，会占用一定的内存空间

2.AOF（Append Only File）

将我们的所有命令都记录下来,history，恢复的时候就把这个文件执行一遍

1.什么是AOF（Append Only File）

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

2.AOF配置（重启Redis就可以生效）

appendonly no          #默认不开启AOF模式

appendfilename "appendonly.aof"   #生成aof文件的名称

# appendfsync always  #每次修改都会sync，速度慢，消耗性能
appendfsync everysec  #每秒都执行一次sync，可能会丢失这1s内的数据！！！
# appendfsync no      #不执行sync，这个时候操作系统自己同步数据，速度最快！！！


#重写规则
no-appendfsync-on-rewrite no  #是否重写


auto-aof-rewrite-percentage 100 #如果aof日志文件记录的指令超过了100条，就会fork一个新的进程进行重写！！！

auto-aof-rewrite-min-size 64mb  #如果aof文件大于64MB，就会fork一个新的进程来将我们的文件进行重写！！！

aof-load-truncated yes

如果appendonly.aof文件出现问题？

1. 会导致Redis启动失败！！！
2. 可以使用Redis提供的工具进行修复！！！

修改指令

reids-check-aof --fix appendonly.aof

3.优点

1. 每次修改都同步，文件的完整性比RDB模式更好！！！
2. 每秒同步一次，可能会丢失这1s内的数据
3. 从不同步，效率最高

4.缺点

1. 相对于数据文件来说，aof远大于rdb，修复的速度也比rdb慢！！！
2. aof的运行效率也比rdb慢，所以Redis默认配置的是RDB模式，而不是AOF模式，进行持久化！！！

扩展

1. RDB持久化模式能够在指定时间间隔内对你的数据进行快照存储
2. AOF持久化模式记录你每次对服务器写的操作，当服务器重启时会重新执行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
3. 只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用持久化。
4. 同时开启两种持久化模式
   1. 在这种情况下，当Redis重启的时候回优先加载AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件的数据集要完整！！！
   2. RDB的数据不实时，同时使用两者时，服务器重启也只会找AOF文件，那为什么不只用AOF呢？因为RDB更加适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。
5. 性能建议
   1. 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1 这条触发规则
   2. 如果Enable AOF，好处是在最恶劣情况下也只会丢失不超过两秒的数据，启动脚本叫简单只load自己的AOF文件就可以了，代价一：带来了持续的IO操作，代价二：AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite 的频率，AOF重写的基础大小默认值64MB太小了，可以设置到5G以上，默认超过原大小100%大小重写可以改到适合的数值。
   3. 如果不Enable AOF ，仅靠Master-Slave Repllcation 实现高可用性也可以，能减少大量的IO操作，也减少了rewrite时带来的系统波动，代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个，微博就是这种架构！！！

八、Redis发布订阅

1.三要素

1. 消息发送者（pub）
2. 频道
3. 消息订阅者（sub）

​ Redis发布订阅（pub/sub）是也只能怪消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息

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

订阅/发布消息图：

2.操作命令

#这些命令被广泛用于构建即时通讯应用，比如网络聊天室和实时广播，实时提醒等！！！

psubscribe pattern [pattern....]  #订阅一个或多个符合给定模式的频道

pubsub subcommand [argument [argument...]]  #查看订阅与发布系统状态

publish channel message  #将消息发送到指定的频道
 
punsubscribe [pattern [pattern...]]  #退订所有给定模式的频道

subscribe channel [[channel...]]  #订阅给定的一个或多个频道的消息

unsubscribe [channel [channel...]]  #指退订给定的频道

3.测试

subscribe test   #消息发布者订阅（发送者）

publish test message  #将消息发布到频道(订阅者)

4.实现原理

	Redis是C实现的，通过分析Redis源码里的pubsub.c文件，了解发布和订阅机制的底层实现，加深了对Redis的理解

	Redis通过PUBLISH、SUBSCRIBE和PSUBSCRIBE等命令实现发布和订阅功能。

	通过SUBSCRIBE命令订阅某频道后，redsi-sever里维护了一个字典，字典的键就是一个个的channel，而字典的值则是一个链表，链表中保存了所有订阅这个channel的客户端。SUBSCRIBE命令的关键：就是将客户端添加到给定的channel订阅链表中。

	通过PUBLISH命令向订阅者发送消息，redis-server会使用给定的频道作为键，在它所维护的字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者。

	Pub/Sub从字面上理解就是发布（Publish）和订阅（Subscribe），在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布之后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天、群聊等。

九、Redis主从复制

1.概念

主从复制：是指将一台Redis服务器的数据，复制到其他的Redis服务器上，前者称为主节点（Master/leader），后者称为从节点（Slave/follower）；数据的复制都是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。

默认情况下：每台Redis服务器都是主节点，并且一个主节点可以有多个从节点（或没有从节点），但是一个从节点只能由一个主节点。

主从复制的作用主要包括：

1. 数据冗余：主从复制实现了数据备份，是持久化之外的一个数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，实际是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供都服务（即写Redis数据时应用连接主节点，读Redis数据时应用的连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读的负载，可以大大的提高Redis服务器的并发量。
4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的，原因如下：

1. 从结构上：单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大。
2. 从容量上：单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有的内存用作Redis存储内存（一般来说，单台Redis最大使用内存不应该超过20G）。

2.环境配置（只配置从库）

info replication  #查看当前库的信息

port 6379         #设置端口号（区别开）

logfile "不同的名称"   #设置日志文件名称（区别开）

dbfilename dump.rdb    #设置rdb文件的名称（区别开）

pidfile /var/run/redis_6381.pid   #设置后台进程文件的名称（区别开）

3.一主二从

默认情况下，每台Redis服务器都是主节点！！！

我们一般情况下只用配置从机就行

命令配置从机（暂时性的）

slaveof 127.0.0.1 6379 #设置当前Redis服务器的主节点（将当前Redis服务器设置为从机）

配置文件配置从机（永久性）

slaveof <masterip> <masterport>  

4.细节

主机可以写，从机不可以写，只能读！！！

主机中的所有数据和信息都会被从机自动保存！！！

5.复制原理

Slave启动成功连接奥Master后发送一个sync同步命令。

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

1.全量复制

Slave服务在接收到数据库文件数据后，将其存盘加载到内存中。

2.增量复制

Master继续将新的所有收集到的修改命令依次传给Slave，完成同步！！！

但是只要重新连接Master，一次全量复制将被自动执行！！！

6.如果主机宕机，如何解决？

#如果主机宕机了，可以使用命令

slaveof no one  #使当前Redis服务器成为主机

7.哨兵模式（自动选举Leader的模式）

1.配置哨兵配置文件(sentinel.conf)

# sentinel monitor 被监控的名称 host port 1

#后面那个数字！代表主机宕机后，从机（Slave）投票看让谁接替成为主机，票数最多的，就会成为主机！

sentinel monitor myredis 127.0.0.1 6379 1

2.启动哨兵

redis-sentinel redis.conf/sentinel.conf 

如果主节点断开，这个时候就会在从机中随机选择一个服务器（投票算法）

哨兵模式

如果之前宕机的主机回来了，只能归并在新的主机下，当从机

3.优点

1.哨兵集群，基于主从复制，所有的主从配置优点都有

2.主从可以切换，故障可以转移，系统可用性会更好

3.哨兵模式就是主从模式的升级，手动到自动，更加健壮！！！

4.缺点

1.Redis不好在线扩容，集群容量一旦到达上限，在线扩容就十分麻烦！！！

2.实现哨兵模式的配置其实是很麻烦的，里面有很多选择！！！

5.哨兵模式的全部配置

# 哨兵sentinel实例运行的端口 默认26379
port 26379

#哨兵sentinel的工作目录
dir /tmp

#哨兵sentinel监控的Redis主节点的ip port
#Master-name 可以自己命名的主节点名字，只能由字母A-Z、数字0-9，这三个字符".-_"组成。
#quorum 配置多个sentinel哨兵统一认为master主节点失联，那么这是客观上认为主节点失联了
#sentienl moitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

#当Redis实例中开启了requirepass foobared授权密码 这样所有连接Redis实例的客户端都需要提供密码
#设置哨兵sentinel连接主从的密码，注意必须为主从设置一样的验证密码
#sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

#指定多少毫秒之后，主节点没有响应sentinel哨兵，此时哨兵主观上认为主节点下线了，默认为30秒
sentinel down-after-milliseconds mymaster 30000

#这个配置项指定了在发生failover主备切换是最多可以有多少个Slave同时对新的Master进行同步
这个数字越小，完成failover所需要的时间就越长
但是如果这个数字越大，就意味着越多的Slave因为replication而不可用
可以通过将这个值设为1来保证每次只有一个Slave处于不能处理命令请求的状态。
#sentinel parallel-sync <master-name> <numslaves>
sentinel parallel-sync mymaster 1

#故障转移的超时时间 failover-timeout 可以用在以下这些方面
#1.同一个sentinel对同一个master两次failover之间的间隔时间
#2.当一个Slave从一个错误的Master哪里同步数据开始计算时间，直到Slave被纠正为向正确的Master哪里同步数据时。
#3.当想要取消一个正在进行的failover所需的时间。
#4.当进行faileover时，配置所有Slaves指向新的Master所需的最大时间，不过，即使过了这个超时，Slave依然会被正确配置为指向Master，但是就不暗parallel-sync所配置的规则来了
#默认两分钟
#sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

#配置当某一时间发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下的规则：
#1.若脚本执行后返回1，那么该脚本稍后将会再次执行，重复次数且目前默认为10。
#2.若脚本执行后返回2，或者比2更高的一个返回值，该脚本将不会重复执行。
#3.如果脚本在执行过程中由于收到系统终端信号被终止了，则返回值为1时的行为相同。
#4.一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。

#通知型脚本：当sentinel有任何警告级别的实践发生时（比如Redis实例的主观失效和客观失效等），将会去调用这个脚本，这时这个脚本一个通过邮件、SNS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数：1.事件的类型，2.事件的描述。如果sentinel.conf配置文件中配置了这个脚本的路径，那么必须保证一个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动。
#通知脚本
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /vat/redis/notify.sh

#客户端重写配置主节点参数脚本
#当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
#以下参数将会在调用脚本时传递给脚本
#<master-name> 
#<role> 
#<state>
#<from-ip>
#<from-port>
#<to-ip>
#<to-port>

#目前<state>总是"failover"
#<role>是"leader"或者"observer"其中一个
#参数<from-ip>、<from-port>、<to-ip>、<to-port>是用来和旧的master和新的master来通信的
#这个脚本应该是通用的，能被多次调用，不是针对性的。
#sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

#一般由运维配置

十、Redis缓存穿透和雪崩(服务的高可用问题！！！)

​ Redis缓存的使用，极大的提高了应用程序的性能和效率，特别是在数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性唯一，从严格意义上讲，这个问题无解，如果对数据的一致性要求很高，就不能使用缓存。

​ 另外的一些经典问题就是：缓存穿透、缓存雪崩和缓存击穿。

1.缓存穿透

概念

	用户想要查询严格数据，发现Redis内存数据库中没有，也就是缓存没有命中，于是想持久层数据库查询数据。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久成数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

解决方案

1.布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。

2.缓存空对象

​ 当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源。

存在两个问题！！！

1. 如果空值能够被缓存起来，这就意味着缓存需要更多的空间来存储更多的键，因为这当中可能会有很多的空值的键；
2. 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间内的数据不一致情况出现，这对于需要保存数据一致性的业务会存在一定的影响。

2.缓存击穿（量大，缓存过期）

概念

	这里需要注意和缓存穿透的区别，缓存击穿，是指一个Key非常的热点，在不停的扛着大量并发，并发集中对这一个点进行访问，当这个Key在过期的瞬间，持续的并发就会击穿缓存层，直接去到持久层数据库中获取数据。
	当某个key在过期的瞬间，有大量的请求并发访问，这类的数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导致数据库瞬间压力过大。

解决方案

1.设置热点数据永不过期

​ 从缓存层面来看，没有设置过期时间，就不会出现key过期之后产生的缓存击穿问题！！！

2.加互斥锁

​ 分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他服务没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁上，所以到分布式锁的考验也很大！！！

3.缓存雪崩

概念

缓存雪崩：是指在某一时刻，缓存集中过期失效，Redis服务器宕机！！！

	产生雪崩的原因之一：比如马上到双十一了，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一小时，那么到了一小时后，这波商品的缓存都集中过期了，而对于这波商品的访问查询，都落到了持久层数据库上，对数据库造成了很大的压力，导致持久层数据库随时都会有挂掉的可能！！！
	
	产生雪崩的原因之二：缓存集中过期，倒也不是最致命的，比较致命的是Redis服务器某一个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某一个时间段集中创建缓存的，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而Redis服务节点宕机，队数据库服务器造成的压力是不可预知的，很可能瞬间就把数据库搞挂了！！！

解决方案

1.Redis高可用

​ 既然Redis随时都有可能出现故障，那么我们就增加多台Redis服务器（搭建Redis集群），这样一台故障之后其他的也可以继续正常的工作。

2.限流降级

​ 在缓存失效后，通过加锁或者队列来控制读取数据库写缓存的线程数量。比如对某个key只允许一个线程来查询数据和写缓存，其他线程等待。

3.数据预热

​ 在正式部署之后，我们先把用户可能访问的数据预先访问一遍，这样部分大量访问的数据就会加载到缓存中。在即将发生高并发访问手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。