Redis学习笔记
Redis学习笔记
一.Nosql的概述
1.为什么用Nosql？
用户信息、社交网络、地理位置等。用户自己产生的数据、用户日志等爆发式增长。 NOsql可以很好的处理以上情况。
2.什么是NoSQL
No SQL = Not Only SQL（不仅仅是数据库）
3.特点
1.方便扩张
2.大数据量高性能（Redis 一秒写8万次 读取11万次 ）
3.数据类型是多样性的（不需要事先设计数据库！随时随用！）
二.Nosql的分类及演进
大数据时代的3V：
1.海量Volume
2.多样Variety
3.实时Velocity
大数据时代的3高：
1.高平发
2.高可拓
3.高性能
NoSQL+RDBMS（关系性数据库）
阿里巴巴架构演进分析：
…
一、NoSQL的四大分类：
1.KV键值对
Redis
2.文档型数据库（bson格式 和json格式一样）
MongoDB
3.列存储数据库
HBase
分布式文件系统
4.图关系数据库
Neo4j、infoGrid
三.Redis入门
1.Redis:
Remote Dictionary Server 远程字典服务
开源、支持多数据类类型、可持久化
百度百科
2.能干嘛？
1.内存存储、持节化，内存中是断电即失，所以持久化很重要（rdb、aof）
2.效率高、可以用于高速缓存
3.发布订阅系统
4.地图信息分析
5.计时器、计数器（浏览量、库存）
3.特性：
开源、支持多数据类类型、可持久化、集群、事务
四.Redis基本知识
1.Redis单线程。
根据机器的内存和网络带宽。
2.C语言写的
3.Redis为什么单线程还那么快？
redis所有的数据放在内存中的，所以使用单线程效率高。
多线程基于cpu上下文切换。
16个database、flushdb、flushall
五.五大数据类型
redis可以用作 数据库 、 缓存 、 消息中间件MQ（发布订阅）。
一、String（字符串）
基本讲的是使用命令
set、get、mset、mget、setex、setnx、getset、
mset user:1:name 张三 user:1:age 18
mget user:1:name user:1:age
二、List（基本数据类型、列表）
可以完成：栈、队列、阻塞队列
所有命令都是l开头
lpush、lrange、rpush 、lpop、rpop
lindex、llen、lrem、ltrim、rpoplpush、
lset（ 更新）、linsert
实际上是一个链表
消息队列（lpush rpop）、栈（lpush lpop）
三、Set（集合）
set中的值是不能重复的！无序不重复
sadd、smembers、sismember
scard、srem、srandmember、spop、smove、
sdiff（差集）、sinter（交集）、sunion（并集）
四、Hash（哈希）
Map集合、key-Map key-key-value
hset、hget、hmset、hmget、hgetall、
hdel、hlen、hexists、hkeys、hval
hincrby、hsetnx
变更数据user name age hash更适合对象的存储。
五、Zset（有序集合）
增加了一个序号的值
zadd、zrange、zrangebyscore、zrem
zcard、zrevrange、zcount
排行榜
六.三种特殊的数据类型
三种特殊的数据类型
一、geospatial 地理位置
geoadd、geopos
两个人之间的距离
geodist
我附近的人？
georadius 、georediusbymember
geohash 返回11个字符的geohash字符串
GEO底层实现原理就是Zset、可以使用zset命令操作geo
二、hyperloglog
基数的统计算法、不允许重复
优点：占用内存固定
允许容错
pfadd、pfcount、pfmerge
三、bitmap
位存储
两个状态的可以使用 如打卡和未打卡
setbit、getbit、bitcount
七.springboot整合redis
spring操作数据：
springdata、 jpa、jdbc、mongodb、redis
说明：spring2.x之后，原来使用的jedis被替换为了lettuce
jedis：采用的直连，多个线程操作的化是不安全的，如果想避免，就要使用jedis pool连接池！
lettuce：采用的netty，实例可以再多个线程中进行共享，不存在线程不安全的情况！可以减少线程数量！
所有的对象传入redis都需要序列化，否则报序列化的错误。
真正的企业及开发的用法！
redisUtil 使用自己的redis配置文件、工具类
八.事务
原子性：要么同时成功、要么同时失败
Redis单条命令保存原子性的、但redis事务不保证原子性。
redis事务的本质：
一组命令的集合、一个事务中所有命令都需要序列化、在事务执行过程中，按照顺序执行。
一次性、顺序性、排他性。
Redis事务没有隔离级别的概念！
所有的命令在事务中，没有立即执行，只有发起命令是才会执行。
redis事务：
开始事务（multi）、命令入队、执行事务（exec）
取消事务：discard
编译型异常、运行时异常
redis实现乐观锁：（监控）watch
悲观锁：很悲观，任务什么时候都会出现错误，无论做什么都会加锁！
乐观锁：很乐观，认为什么时候都不会出现错误，所以不会上锁！更新数据的时候取判断一下，在此期间是否有人修改过这个数据
获取version
更新时比较version
执行失败 记得解锁 unwatch
九.学会看redis.cof配置文件
看配置文件redis.cof
快照：
持久化：在规定时间内，执行多少次操作，则会持久化到文件.rdb、 .aof
redis是基于内存的数据库，是持久化的。
没有持久化，意味着 断电即失 。
十.Redis持久化
RDB AOF
RDB:Redis DataBase 保存的文件是dump.rdb
原理：
Redis会单独创建（fork）一个子进程进行持久化，会先将数据写入到一个临时文件，待持久化进程结束了，临时文件就会替代上次持久化的文件。
整个过程中，主经常不进行io操作，保证了性能的高效。
如果需要进行大规模的数据恢复，且对于数据恢复的完整性要求不高，那么RDB模式会比AOF模式更加高效。
RDB持久化方式能够在指定时间内对你的数据进行快照存储！
触发机制：
1.满足save的规则的情况下，会自动触发rdb规则，生成dump.rdb
2.执行flushall命令，会自动触发rdb规则，生成dump.rdb
3.退出redis，会自动触发rdb规则，生成dump.rdb
如何恢复dump.rdb:
将dump.rdb文件放到redis-server的同一级目录下，会自动读取dump.rdb
优点：
1.适合大规模的数据恢复 性能高于aof
2.对数据的完整性不高
缺点：
1.需要一定的时间间隔进行操作！如果redis意外宕机了，最后一次修改i的数据就没有了。
2.fork进程的时候，会占用一定的内存空间。
AOF：Append Only File 保存的文件是appendonly.aof
原理：
通过日志的方式将所有每次写的操作记录到文件中（将我们所有命令记录下来），只是追加文件而不是修改文件，恢复的时候就将这个文件全部执行一遍。
默认不开启，开启进redis.conf文件中修改即可。
如果appendonly.aof文件存在错误：
redis-check-aof可以修复appendonly.aof文件。
优点：（基于aof触发机制）
1.数据文件完整性较好。（每次修改都进行同步）
2.可能有一秒的数据丢失。（每秒进行同步）
3.从不同步的情况，效率最高。
缺点：
1.相对于数据文件来说，占用的内存比较大，所以修复速度就比较慢。
2.性能低于rdb，所以默认的配置就是rdb持久化
rewrite重写规则：
aof默认是无限制的追加文件，所以文件越来越大，这时需要重写。
触发rewrite重写机制：
如果aof文件大于64m，aof会fork一个新的进程将我们文件重写。
十一.Redis发布订阅
Redis发布订阅（pub/sub）是一种消息通信方式：
发送者发送消息，订阅者接收消息。。。微博、微信、关注系统。
发送者、频道、订阅者。
命令：
publish、subscribe
原理：
Redis是通过publish、subcribe、psubcribe等命令实现发布和订阅功能。
比如微信：
通过subcribe命令订阅某频道后，redis-server里维护了一个字典，字典里包含很多频道，也就是字典的键就是一个个频道。而字典的值则是一个链表，链表中保存了所有订阅该频道的客户端。
subcribe命令的关键就是 将客户端添加到给定channel的订阅链表中。
用过publish命令向订阅者发送信息，redis-server会使用给定的频道作为键，在它所维护的channel字典中查找订阅了该频道的客户端链表，遍历这个链表发送信息给订阅者。
应用场景：
1.实时消息系统
2.实时聊天
3.订阅、关注系统
稍微复杂的场景：
我们使用 消息中间件MQ 比如：Kafka、RabbitMQ…
十二.Redis主从复制
概念：
主从复制，是指一台redis服务器的数据，复制到其他redis服务器。前者称为主节点（master/leader），后者称为从节点（slave/follower）
数据的复制是单向，所以只能从主节点到从节点。Master以写为主，Slave以读为主。
默认情况下，每台Redis服务器都是主节点。
一个主节点有多个从节点，而从节点只有一个主节点。
主从复制的作用：
1.数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2.故障恢复：当主节点出现问题，就可以从从节点获取服务。实现快速的故障恢复。实际上是一种服务的冗余。
3.负载均衡：在主从复制的基础上，配合读写分离。由主节点提供写服务，从节点提供读服务，实现读写分离（即 写redis数据应用连接主节点，读redis数据时应用连接从节点），分担服务器负载；大多数都写少读多的情况，所以通过从节点分担读负载，可以大大提高Redis服务器的并发量。
4.高可用（集群）基石：主从复制是哨兵模式和集群能够实施 的 基础，所以主从复制时高可用的基础
一般来说，redis应用与工程项目，一台redis是不可能的，原因：
1.结构上，单个redis服务器会发生单点故障，并且一台redis服务器需要处理所有请求负载，压力大。
2.容量上，单个redis服务器内存容量有限，就算一台服务器很大，有256个G，也不能将所有的内存用作redis存储内存。一般来说，最大不超过20G
---------------------一主（79）二从 （80、81） 测试------------------
复制3个配置文件，然后修改对应的信息：
1.端口 2.pid名字 3.log文件名 4.dump.rdb文件名
环境配置：
只配置从库，不配置主库！
一些命令：info replication、salveof
测试1.主机断开连接，从机依旧可以获取主机以前写的信息。
测试2.从机断开连接，如果是命令行的方式来获取主机的化，从机是临时的，重启后，重新变为主机。想永久 就去配置文件中修改redis.conf。变为从机，依旧可以获取主机以前携带数据。这就涉及到复制的原理！
复制原理：
slave启动成功后，会向master发送一个同步命令sync，执行全量复制。
master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将发送整个文件到slave，并完成一次同步。
1.全量复制：slave服务在接收到数据库文件数据之后，将其存盘加载到内存中。（也就是在从机重新连接到主机时的操作）
2.增量复制：master继续将新的收集到的修改命令依次传给slave，完成同步。
但是只要是重新连接master，一次完全同步（全量复制）将被自动执行！我们的数据一定可以从从机中看到！
层层链路：
一个主从节点跟一个从节点，从节点再跟一个从节点.....
主要在于：万一主节点宕机了，接着后面的一个可以当主节点（不过需要手动配置SLAVE no one）,可以使用写的功能了。
万一主节点回来了，如果需要跟以前一样当老大，就需要重新配置了。
十三.哨兵模式
哨兵模式（自动选举老大的模式）：
概述：
主从切换技术的方法是：当主机宕机后，需要手动一台服务器变为主服务器，这就需要人工干涉、费事费力，还会造成一段时间内服务器无法使用的情况。所有真正的开发项目时不推荐的，我们优先考虑哨兵模式。
redis从2.8开始提供了Sentinel（哨兵）架构解决这个问题。
哨兵模式可以说是 谋朝篡位 的自动版，能够后台监控主机是否故障，如果故障了根据投票重新选择主服务器，自动将从库转换为主库。
原理：
哨兵模式是一种特殊的模式，首先从redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是 哨兵通过发送命令，等待Redis服务器响应，从而监控多个redis实例。
哨兵作用：
1.通过发送命令，让redis服务器返回监控运行状态，包括主、从服务器。
2.当哨兵监测到m宕机了，会自动将某一个s变为m，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让他们切换主机。
问题：
一个哨兵对redis服务器进行监控，可能出现问题，可能哨兵有问题了，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了
多哨兵模式！
多哨兵模式：
假设master宕机了，哨兵1先检测到这个结果，系统不会马上进行faillover过程，仅仅是哨兵1主观认为这个m不可用，这个现象称为【主观下线】！
当后面的哨兵也检测到，并且达到一定的数值，那么哨兵就会进行一次投票，投票的结果有一个哨兵发起，进行failover（故障转移）操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为【客观下线】
-------------------测试-------------------------------
目前状态为：一主二从
1.增加修改sentinel.conf配置文件
sentinel monitor 被监控名称（自己取） host port 1
例如：sentinel monitor myredis 127.0.0.1 6379 1
数字1：代表主机挂了，slave投票让谁接替成为主机，票数多的，就会成为主机！这里有个投票算法。！
2.启动哨兵
3.看看主机宕机发生什么情况
随机的一个从机变为主机。。。。
4.主机恢复会怎样
主机变为了从机。。。。。
十四.Redis缓存穿透
还需要进行了解！
缓存穿透（查不到）：
概念：
用户想要查询一个数据，发现redis内存数据库中没有，也就是缓存没有命中，于是向持久层数据库中查询。发现数据库中也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中（秒杀高并发），于是都去数据库中请求。这就给持久层数据库造成很大的压力，这时候相当于出现了缓存穿透！
解决方案：（深入了解请百度）
1.布隆过滤器：
布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。
2.缓存空对象：
当存储层不命中后，即使返回的空对象也将其缓存起来，同时设置缓存过期时间，之后再访问这个数据将会从会从中获取，保护后端数据源。
问题：
1.如果空值能够被缓存起来，这就意味着需要跟多的空间去存储更多的键，因为这当中可能会有很多空值的键，没有意义。
2.即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。比如：缓存区还存在这个商品，而存储层么有这个商品了。
十五.缓存击穿
缓存击穿（量太大，缓存过期！）
概述：
这里需要注意和缓存穿透的区别，缓存击穿是指一个key非常热点，再不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像一个屏幕凿开一个洞。
当某个key在过期的瞬间，大量的请求并发访问，这类数据一般使热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且协会缓存，会导致数据瞬间压力过大。
解决方案：
1.设置热点数据不过期。！从缓存层面来看，没有设置过期时间，就不会出现热点key不在缓存中的情况。这也导致了需要大量内存的浪费与使用。
2.加互斥锁。！使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考研很大。
哨兵模式优点：
1.哨兵集群，基于主从复制，所以主从复制的优点，它都有！
2.主从可以切换，故障可以转移，系统可用性更好
3.哨兵模式就是主从模式的升级，手动到自动，更加友好、健壮。
缺点：
1.Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦！
2.实现哨兵模式的配置其实很麻烦，里面有很多选择！
ps：自行百度【哨兵模式的全部配置】
十六.缓存雪崩
缓存雪崩
概念：
缓存雪崩，是指在某一个时间段，缓存集中过期失效。redis宕机！
产生的原因：
比如在双十一期间，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一小时。那么凌晨一点的时候，这批商品的缓存过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。
其实集中过期，倒不是非常致命，因为自然形成的缓存雪崩，一定在某个时间段集中创建缓存，这个时候，数据库是可以顶住压力的，无非是对数据库产生周期性的压力而已。
比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。
解决方案：
1.redis高可用
这个思想的含义：既然redis有可能挂掉，那我就多增设几台redis服务器，这样挂掉一台之后还可以继续工作。其实就是搭建集群！（异地多活！）
2.限流降级（springcloud）
这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库与写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
3.数据预热
数据预热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间尽量均匀。