Redis

90年代，一个基本的网站访问量一般不会太大，单个数据库完全足够。这种情况下：网站的瓶颈是什么？1、数据量如果太大，一个机器放不下了！2、数据的索引（B+Tree），一个机器内容也放不下3、访问量（读写混合）、一个服务器承受不了

1、单机MySql的时代

网站80%的情况都是在读，每次都要去查询数据库的话就很麻烦！所以我们希望减轻数据库的压力，我们可以使用缓存来保证效率！

发展过程：优化数据结构和索引--》文件缓存（IO）--》Memcached（当时最热门的技术！）

2、Memcached（缓存）+MySQL+垂直拆分

数据库本质：读，写

Mysql早些年MyISAM引擎：表锁，十分影响效率！高并发下会出现严重的锁问题转战Innodb引擎：行锁

3、分库分表+水平拆分+MySQL集群

2010-2020十年之间，世界已经发生了翻天覆地的变化；（定位，音乐、热榜，也是一种数据！）

MySQL等关系型数据库就不够用了！数据量很多，变化很快！

MySQL有的使用它来存储比较大的文件，博客，图片！数据库表很大，效率就低了！如果有一种数据库来专门处理这种数据，M有SQL压力就变的十分小（研究如何处理这些问题！）大数据的IO压力下，表几乎没法更大！

4、如今最近的年代

用户的个人信息，社交网络，地理位置。用户自己产生的数据，用户日志的等等爆发式增长！这个时候我们就需要使用N哦SQL数据库，N哦SQL可以很好的处理以上的情况！

为什么要用Nosql

NoSQL = Not Only SQL(不仅仅是SQL)关系型数据库：表格，行，列

解耦！

1、方便扩展（数据之间没有关系，很好扩展！）

2、大数据量高性能（Redis一秒写8万次，读取11万，NoSQL的缓存记录级，是一种细粒度的缓存，性能会比较搞！）

3、数据类型是多样型的！（不需要事先设计数据库！随取随用！如果是数据量十分大的表，很多人就无法设计了）

传统的RDBMS：1、结构化组织2、SQL3、数据和关系都存在单独的表中4、严格的一致性5、基础的事务。。。

NoSQL：1、不仅仅是数据2、没有固定的查询语言3、键值对存储，列存储，文档存储，图形数据库（社交关系）4、最终一致性5、CAP定理和BASE（异地多活）6、高性能，高可用，高可扩。。。

传统的关系型数据库

4、传统的关系型数据库和Nosql

NoSQL特点

大数据时代的3V：主要是描述问题的1、海量Volume2、多样Variety3、实时Velocity

大数据时代的3高：主要是对程序的要求1、高并发2、高可扩（随时水平拆分，机器不够可以扩展机器来解决）3、高性能

了解：3V+3高

真正在公司的实践：NoSQL+RDBMSYI一起使用才是最强的！

什么是NoSQL

2、商品的描述、评论（文字比较多）文档行数据库中，MongoDB

3、图片1）分布式文件系统  FastDFS2）淘宝自己的TFS3）Google的GFS4）Hadoop  HDFS5）阿里云的OSS

4、商品的关键字（搜索）搜索引擎  solr  elasticSearchISearch（淘宝在用）

5、商品热门的波段信息内容数据库：redis、Tair...

6、商品的交易，外部的支付接口· 三方应用

阿里巴巴演进分析

新浪：Redis美团：Redis+Tair阿里、百度：Re

KV键值对

基于分布式文件存储的数据库，C++编写，主要用来处理大量的文档!

介于关系型数据库和非关系型数据库中间的产品！MongoDB是非关系型数据库中功能最丰富，最像关系型数据库的！

MongoDB

ConthDB

文档型数据库（bson格式 和json一样）

HBase分布式文件系统

列存储数据库

他不是存图形，放的是关系，比如：朋友圈社交网络，广告推荐！Neo4j，InfoGrid

图关系数据库

NoSQL的四大分类

Nosql概述

Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis是什么

1、内存存储、持久化，内存中是断电即失、所以说持久化很重要（rdb、aof）

2、效率高，可以用于告诉缓存

3、发布订阅系统

4、地图信息分析

5、计时器，计数器（浏览量！）

。。。。

Redis能干嘛

1、多样的数据类型

2、持久化

3、集群

4、事务

。。。。。

特性

概述

redis-benchmark是一个压力测试工具！官方自带的性能测试工具！

redis-benchmark命令参数

测试：100个并发链接   100000请求redis-benchmark -h localhost -p 6379 -c 100 -n 100000

测试性能

redis默认有16个数据库、默认使用的是第0个

可以使用select进行切换数据库

清空当前数据库  flushdb清空全部数据库的内容  flushall

redis是很快的，官方表示，Redis是基于内存操作，CPU不是Redis性能瓶颈，Redis的瓶颈是根据机器的内存和网络带宽，既然可以使用单线程来实现，就使用单线程了

误区1：高性能的服务器一定是多线程的？误区2：多线程（CPU上下文会切换！）一定比单线程效率高？

速度：CPU>内存>硬盘

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

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

redis是单线程的

基础知识

Redis入门

Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。 Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动 分区（Cluster）提供高可用性（high availability）。

exists name  #判断当前的key是否存在move name 1  #移除当前的keyexpire name 10  #设置key的过期时间，单位是秒ttl name  #查看当前key的剩余时间type name  #查看当前key的一个类型

Redis-Key

set key1 v1  #设置值get key1  #获得值keys *  #获得所有的keyexists key1  #判断某个key是否存在append key1 \"hello\"  #追加字符串，如果当前key不存在，就相当于set keystrlen key1  #获得字符串长度！

incr views  #自增1decr views  #自减1incrby views 10  #可以设置步长，指定增量！decrby views 5  

字符串范围getrange key1 0 3   #截取字符串【0，3】getrange key1 0 -1  #获取全部的字符串setrange key2 1 xx   #替换指定位置开始的字符串！

setex key3 30 \"hello\

getset  #先get然后setgetset db redis   #如果不存在值，则返回nil，并设置值getset db mongodb   #如果存在值，获取原来的值，并设置新的值

使用场景：value除了是字符串还可以是数字！1、计数器2、统计多单位的数量3、粉丝数4、对象缓存存储

Stirng（字符串）

栈：先进后出队列：先进先出阻塞队列：通道直通，两边都可以拿

在redis里面，我们可以把list玩成，栈、队列、阻塞队列！

LPUSH list one LPUSH list twoLPUSH list three   #将一个值或多个值，插入列表头部（左）LRANGE list 0 -1   #获取list中的值！LRANGE list 0 1   #通过区间获取具体的值！RPUSH list four    #将一个值或多个值，插入到列表尾部（右）

Lpop list   #移除list的第一个元素Rpop list   #移除list的最后一个元素

Lindex list 1   #通过下标获得list中的某一个值！Llen list   #返回列表的长度lrem list 1 one   #移除list集合中指定个数的value，精确匹配ltrim mylist 1 2   #通过下表截取指定长度，list已经被改变，截断了只剩下截取的元素rpoplpush mylist myotherlist   #移除列表mylist的最后一个元素，将它移动到新的列表myotherlist中。

lset list 0 item    #将列表中指定下标的值替换为另一个值，更新操作，如果不存在列表我们去更新就会报错，如果存在更新当前下标的值linsert mylist before \"world\" \"other\"   #将某个具体的value插入到列表中某个元素的前面或者后面

命令

小结：1、实际上是一个链表，before Node after left right 都可以插入值；2、如果key不存在，创建新的链表3、如果key存在，新增内容4、如果移除了所有值，空链表，也代表不存在5、在两边插入或者改动值，效率最高！中间元素，相对来说效率会低一点消息排队！消息队列（Lpush  Rpop），栈（Lpush  Lpop）

List（列表）

set中的值不能重复

sadd myset \"hello\"  #set集合中添加元素smembers myset   #查看指定set的所有值sismember myset hello   #判断某一个值是不是在set集合中scard myset   #获取set集合中的内容元素个数srem myset hello   #移除set集合中的指定元素srandmember myset   #随机抽选出一个元素srandmember myset 2   #随机抽选出指定个数的元素spop myset   #随机删除一些set集合中的元素smove myset myset2 \"hello\"   #将一个指定的值，移动到另外一个set集合

sdiff key1 key2   #差集sinter key1 key2   #交集  共同好友就可以这样实现sunion key1 key2   #并集

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

共同关注，共同爱好，二度好友，推荐好友！

场景

Set（集合）

Map集合，key-map。本质和String类型没有太大区别，还是一个见到那的key-value

hset myhash field1 kuangshen   #set一个具体key-valuehget myhash field1   #获取一个字段值hmset myhash field1 hello field2 world   #set多个 key-valuehmget myhash field1 field2   #获取多个字段值hgetall myhash   #获取全部的数据hdel myhash field1   #删除hash指定key字段，对应的value值也就消失了hlen myhash   #获取hash表的字段数量hexists myhash field1   #判断hash中指定字段是否存在

hkeys myhash   #获得所有的fieldhvals myhash   #获得所有的value

hincrby myhash field3 1   #指定字段的值自增1hdecrby myhash field3 1   #指定字段的值自减1hsetnx myhash field4 hello   #如果不存在则可以设置hsetnx myhash field4 world   #如果存在则不能设置

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

Hash（哈希）

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

zadd myset 1 one   #添加一个值zadd myset 2 two 3 three   #添加多个值zrange myset 0 -1

#  zrangebyscore key min maxzadd salary 2500 xiaohong   #添加三个用户zadd salary 5000 zhangsanzadd salary 500 kuangshenzrangebyscore salary -inf +inf   #显示全部的用户 从小到大！zrangebyscore salary -inf +inf withscores   #显示全部的用户并且附带成绩zrevrange salary 0 -1   #从大到小显示全部用户

zrem salary xiaohong   #移除有序集合中的指定元素zcard salary    #获取有序集合中的个数

zadd myset 1 hellozadd myset 2 world 3 kuangshenzcount myset 1 3   #获取指定区间的成员数量

set排序，存储班级成绩表，工资表排序！普通消息1，重要消息2，带权重进行判断！排行榜应用实现，取Top N测试！

案例思路

Zset（有序集合）

五大数据类型

朋友的定位，附近的人，打车距离计算。可以推算地理位置的信息，两地之间的距离，方圆几里的人！

#geoadd   添加地理位置#规则：两极无法直接添加，我们一般会下载城市数据，直接通过java程序一次性导入！#参数 key 值（纬度，经度，名称）

geopos china:city beiing   #获取指定城市的经度和纬度！geopos china:city beijing chongqing

两人之间的距离！单位：m表示单位为米。km表示单位为千米。mi表示单位为英里。ft表示单位为英尺。geodist china:city beijing shanghai km   #查看上海到北京的直线距离

georadius：以给定的经纬度为中心，找出某一半径内的元素附近的人（获取所有附近的人地址，定位！）通过半径搜索georadius china:city 110 30 500 km    #以110，30 这个经纬度为中心，寻找方圆500km内的城市georadius china:city 110 30 500 km withdist   #显示到中间距离的位置georadius china:city 110 30 500 km withdist count 1  #筛选出一条指定的结果

georadiusbymember china:city beijing 1000km   #找出位于指定元素周围的其他元素！

geohash china:city beijing chongqing    #将二维的经纬度转换为一维的字符串，如果两个字符串越像，则距离越接近

GEO底层的实现原理其实就是Zset！我们可以使用Zset命令来操作geozrange china:city 0 -1    #查看地图中全部的元素zrem china:city beijing   #移除指定的元素

geospatial地理位置

不重复的元素，可以接受误差！例：A{1.3.5.7.8.7}   B{1.3.5.7.8}AB的基数为5

什么是基数？

基数统计的算法！优点：占用的内存是固定，2^64不同的元素的基数，只需要废12kb的内存！如果要从内存角度来比较的话Hyperloglog首选！

网页的UV（浏览量），一个人访问一个网站多次，但还是算作一个人传统的方式，set保存用户的id，然后就可以统计set中的元素数量作为标准判断！这个方式如果保存大量的用户id，就会比较麻烦！我们的目的是为了计数，而不是保存用户id。

简介

Hyperloglog

Bitmaps位图，数据结构！都是操作二进制位来进行记录，只有0和1两个状态

统计用户信息，活跃，不活跃！登录，未登录！打卡，365打卡！两个状态的，都可以使用Bitmaps。

查看周四是否打卡getbit sign 3

使用bitmap来记录周一到周日的打卡setbit sign 0 1   周一setbit sign 1 0   周二setbit sign 2 0   周三setbit sign 3 1   周四

统计操作(查看一共打卡多少天)bitcount sign

位存储

Bitmaps

三种特殊数据类型

Redis事务本质：一组命令的集合！一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行！一次性、顺序性、排他性！执行一系列的命令！Redis事务没有隔离级别的概念！所有的命令在事务中，并没有直接被执行！只有发起执行命令的时候才会执行！Redis单条命令保证原子性的，但是事务不保证原子性！

127.0.0.1:6379> multi     #开启事务OK127.0.0.1:6379(TX)> set k1 v1QUEUED127.0.0.1:6379(TX)> set k2 v2QUEUED127.0.0.1:6379(TX)> get k2QUEUED127.0.0.1:6379(TX)> exec   #执行事务1) OK2) OK3) \"v2\"

开启事务（Multi）命令入队执行事务（exec）取消事务（Discard）

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

运行时异常（1/0），如果事务队列中存在运行时异常，那么执行命令的时候，其他命令时可以正常执行的，错误命令抛出异常！

Redis事务

无论做什么都会加锁！

悲观锁

认为什么时候都不会出现问题，所以不会上锁！更新数据的时候去判断一下，在此期间是否有人修改过这个数据

version字段

更新的时候比较version

乐观锁

127.0.0.1:6379> set money 100OK127.0.0.1:6379> set out 0OK127.0.0.1:6379> watch money    #监视 money对象OK127.0.0.1:6379> multiOK127.0.0.1:6379(TX)> DECRBY money 20QUEUED127.0.0.1:6379(TX)> INCRBY out 20QUEUED127.0.0.1:6379(TX)> exec1) (integer) 802) (integer) 20

正常执行成功

线程一：127.0.0.1:6379> watch money    #监视 money对象OK127.0.0.1:6379> multiOK127.0.0.1:6379(TX)> DECRBY money 20QUEUED127.0.0.1:6379(TX)> INCRBY out 20QUEUED127.0.0.1:6379(TX)> exec（nil）线程二（在线程一exec前，multi后执行）：increby money 1000

修改失败

测试

修改失败后，进行解锁，重新加锁

解锁（unwatch）

监控Watch（乐观锁）

事务

SpringBoot操作数据：spring-data jpa jdbc mongodb redisSpringData也是和SpringBoot齐名的项目！说明：在SpringBoot2.0之后，原来使用的jedis被替换为了lettucejedis：采用直连，多个线程操作的话，是不安全的，如果想要避免不安全，使用jedis pool连接池！更像BIO模式lettuce：采用netty。实例可以在多个线程中进行共享，不存在线程不安全的情况！可以减少线程数量，更像NIO模式

Springboot整合

1、配置文件 unit单位，对大小写不敏感

bind 0.0.0.0   #绑定ipprotected-mode yes # 保护模式port 6379   #端口daemonize yes   #守护进程（后台启动）pidfile /var/run/redis_6379.pid  #如果以后台方式运行，我们就需要指定一个Pid文件

持久化，在规定的时间内，执行了多少此操作，则会持久化到文件 .rdb  .aofredis时内存数据库，如果没有持久化，那么数据断电即失save 900 1  #如果900s内，如果至少有一个key进行了修改，我们就进行持久化操作stop-writes-on-bgsave-error yes  #持久化出错，是否会继续工作rdbcompression yes   #是否压缩rdb文件，需要消耗一些cpu资源rdbchecksum yes  #保存rdb文件时，进行错误的检查校验dir ./   #rdb文件保存的目录，默认当前路径

requirepass WDwd123456   #设置密码   默认没有密码命令：config set requirepass \"123456\"   #命令设置密码

maxclients 10000    #设置能连接上redis的最大客户端数量maxmemory <bytes>  #redis配置最大的内存容量

noeviction：当内存使用达到阈值的时候，所有引起申请内存的命令会报错。allkeys-lru：在主键空间中，优先移除最近未使用的key。(推荐)volatile-lru：在设置了过期时间的键空间中，优先移除最近未使用的key。allkeys-random：在主键空间中，随机移除某个key。volatile-random：在设置了过期时间的键空间中，随机移除某个key。volatile-ttl：在设置了过期时间的键空间中，具有更早过期时间的key优先移除。

maxmemory-policy noeviction   #内存到达上限的处理策略

appendonly no   #默认不开启，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用appendfilename \"appendonly.aof\"   #持久化文件的名字appendfsync everysec   #每秒执行一次sync，可能丢失这1s的数据#  always   每次修改都会sync ，消耗性能#  no    不执行，操作系统会自己同步，效率最高

APPEND ONLY模式   aof配置

Redis.conf详解

在指定的时间间隔内将内存中的数据集体写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。Redis会单独创建一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。

rdb保存的文件是dump.rdb，在主从复制中，rdb通常是备份的。不占用主机的空间

1、save的规则满足的情况下，会自动触发RDB规则2、执行flushall命令，会触发3、退出redis，也会产生rdb文件备份就会生成dump.rdb

触发机制

1、只需要将rdb文件放在我们redis启动目录下就可以，redis启动会自动检查dump.rdb文件，恢复其中的数据！2、查看需要存放的位置    config get dir        如果再这个目录下存在dump.rdb文件，启动就会自动恢复！

如何恢复rdb文件

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

优点

1、需要一定的时间间隔进行操作！如果redis意外宕机了，这个最后一次修改数据就没有了2、开启子进程的时候，会占用一定的内容空间！

缺点

RDB（Redis DataBase）

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

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

默认是不开启的，需要手动开启！我们只需要将appendonly改为yes就可以开启。重启redis就可以生效了rdb和aof同时开启，默认读取aof文件

Aof保存的是 appendonly.aof文件

如果这个aof文件有错误，redis是无法启动的，我们需要修复这个aof文件。redis给我们提供了一个工具，redis-check-aof --fix appendonly.aof

1、每一次修改都同步，文件的完整性更加好2、每秒同步一次，可能会丢失一秒的数据3、从不同步，效率最高，操作系统自动调度刷磁盘

1、相对于数据文件大小来说，aof远远大于rdb，修复的数据比rdb慢2、Aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化

AOF（Append Only File）

Redis持久化

Redis发布订阅（pub/sub）是一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息。微信、微博、带关注的系统！

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

Redis是用C实现的，通过分析Redis源码里的pubsub.c文件，了解发布和订阅机制的底层实现，籍此加深对Redis的理解。Redis通过PUBLISH、SUBSCRIBE和PSUBSCRIBE等命令实现发布和订阅功能。通过SUBSCRIBE命令订阅某频道后，redis-server里维护了一个字典，字典的键就是一个个channel，而字典的值则是一个链表，链表中保存了所有订阅这个channel的客户端。SUBSCRIBE命令的关键，就是将客户端添加到给定channel的订阅链表中。通过PUBLISH命令想订阅者发送消息，redis-server会使用给定的频道作为键，在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者。Pub/Sub从字面上理解就是发布（Publish）与订阅（Subscribe），在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。

1、实时消息系统2、实时聊天（频道当作聊天室，将信息回西安给所有人）3、订阅，关注系统都是可以的！稍微复杂的场景我们就会使用消息中间件MQ

使用场景

原理

Redis发布订阅

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

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点，但一个节点只能有一个主节点。

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

作用

127.0.0.1:6379> info replication# Replicationrole:master   #角色  masterconnected_slaves:0    #没有从机master_failover_state:no-failovermaster_replid:48113c251846434522c5c7b9522bab0ccb197285master_replid2:0000000000000000000000000000000000000000master_repl_offset:0second_repl_offset:-1repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0

查看当前库的信息

复制3个配置文件，然后修改对应的信息1、端口2、pid名字3、log文件名字4、dump.rdb名字

默认情况下，每台Redis服务器都是主节点；我们一般情况下只用配置从机就好了

127.0.0.1:6382> SLAVEOF 127.0.0.1 6380   #认6380做主机OK127.0.0.1:6382> info replication# Replicationrole:slave   #当前角色  从机master_host:127.0.0.1master_port:6380master_link_status:downmaster_last_io_seconds_ago:-1master_sync_in_progress:0slave_read_repl_offset:0slave_repl_offset:0master_link_down_since_seconds:-1slave_priority:100slave_read_only:1replica_announced:1connected_slaves:0master_failover_state:no-failovermaster_replid:c552e97f8b65ef6c4f83d29b5638777652b61234master_replid2:0000000000000000000000000000000000000000master_repl_offset:0second_repl_offset:-1repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0

真实的主从配置应该在配置文件中配置，这样的话是永久的，我们这里使用的命令是暂时的。重启就失效了。只要变为从机，马上就会把主机里面的数据都读过来

细节：主机可以写，从机不能写！只能读。

Slave启动成功连接到master后会发送一个sync同步命令Mashter接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕后，master将传送整个数据文件到slave，并完成一次完全同步。全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中增量复制：Master继续将新的所有收集到的修改命令一次传给slave，完成同步但是只要重新连接master，一次完全同步（全量复制）将被自动执行

复制原理

一主二从

上一个从节点连接下一个从节点，这个时候也可完成主从复制。虽然第二台从节点是第三台的主节点，但第二台还是从节点，无法写入

层层链路

slaveof no one    自己变成主节点

手动变主节点

环境配置（不常用）

自动选举老大主从切换技术的方法是：当主服务宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费时费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。redis从2.8开始正式提供了Sentinel哨兵架构来解决这个问题。能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例

1、通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器2、当哨兵监测到mater宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他从服务器，修改配置文件，让他们切换主机

一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行选举过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行故障转移操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换为主机，这个过程称为客观下线

1、配置哨兵配置文件sentinel.conf#sentinel monitor 被监控的名称 host port 1sentinel monitor myredis 127.0.0.1 6379 1后面的这个数字1，代表一个哨兵监控到主机挂了，就客观下线，slave投票看让谁接替为主机，票数最多的就会成为主机！2、在bin目录下 启动redis-sentinel

如果主机挂了，选举一个从机当主机。如果主机挂了之后回来了，当从机。

6台服务器时，先全部启动redis，然后随机进入一台执行以下命令即可完成主从配置redis-cli --cluster create 172.38.0.11:6379 172.38.0.12:6379 172.38.0.13:6379 172.38.0.14:6379 172.38.0.15:6379 172.38.0.16:6379 --cluster-replicas 1

1、哨兵集群，基于主从复制模式2、主从可以切换，故障可以转移，系统的可用性会更好3、哨兵模式就是主从模式的升级，手动到自动，更加健壮

1、Redis不好在线扩容，集群容量一旦到达上限，在线扩容就很麻烦2、实现哨兵模式很麻烦，配置很多

哨兵模式（重点）

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

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

布隆过滤器

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

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

问题

缓存空对象

解决方案

缓存穿透（查不到）

指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。当这个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导致数据库瞬间压力过大。

从缓存层面来看，没有设置过期时间，所以就不会出现热点Key过期后产生的问题

设置热点数据永不过期

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

加互斥锁

缓存击穿（量太大，缓存过期）

在某一个时间段，缓存集中过期失效。Redis宕机！产生雪崩的原因之一，比如在写文本的时候，马上到双十二零点，很快会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了陵城1点的时候，这批商品的缓存就过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会到达存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

其实其中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

双十一：阿里会把一些不重要的服务停掉，保证主要的服务可用

多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建集群

redis高可用

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

限流降级

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

数据预热

缓存雪崩

Redis缓存穿透和雪崩

主从复制

Redis