Redis-大厂程序员是怎么用的
Redis是什么?
为什么需要Redis?
数据逐渐从单表----》分库分表
MySQL从单机出现了集群
出现了数据量增长，读写数据压力增长
tip1：数据分冷热,热数据指经常被访问到的数据，被放到Redis里面也就是内存里。
数据库回写到Redis里面:
1.写入数据库产生beinglog日志，记录MySQL数据的变更,框架反解beinglog，写入Redis中，这是实现MySQL和Redis同步的基本逻辑.
Redis原理:
Redis的数据可以在一定程度上做到持久化:
Redis基本工作原理:
1.数据从内存中读写
2.数据保存到硬盘上防止重启数据丢失
RDB:可以将Redis在内存中的数据库状态保存到磁盘里面，避免数据意外丢失
RDB持久化既可以手动执行，也可以根据服务器配置选项定期执行，该功能可以将 某个时间点上的 数据库状态(所有的键值对) 保存到 一个RDB文件中
RDB持久化功能所生成的 RDB文件 是一个 经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态
每次Redis启动时先读取全量数据RDB，判断是否又没有命令，如果有，执行AOF文件执行宕机前的命令.
(Redis中单线程处理全部操作命令，即进来是排队处理----分布式锁有用到)
Redis应用案例
1.连续签到
每天可签到一次，如果断签，连续签到计数归0：连续签到的定义--》每天必须在23:59:59前签到。
关键是设计。key:id value: 签到天数 expireAt：过期时间(后天0点)
两个redis的能力:1.在原有数据上+1 Incr() 2.设置过期时间，过期value后置0 ExpireAt()
Redis中的String数据结构:
寻址方式很特殊，sds指针先向左看数据有多长，再向右移动获取对应的数据。
2.消息通知
list作为消息队列
场景:当文章更新时，将更新后的文章推到ES，用户就能搜索到最新的文章数据.
Redis中数据结构List--Quicklist
Quicklist由一个双向链表和listpack实现
3.计数
一个用户有多项计数需求，可通过hash结构存储。
Pepeline()打包，减少重复传输。
Hash数据结构dict
rehash:rehash操作是将ht[0]中的数据，全部迁移到ht[1]中。数据量小的场景下，直接将数据从ht[0]拷贝到ht[1]速度是比较快的。数据量大的场景，例如存有上百万条KV时,迁移过程将会明显阻塞用户请求。
渐进式hash:为避免出现这种情况，使用率rehash方案，基本原理就是，每次用户访问时都会迁移少量数据。将整个迁移过程,平摊到所有的访问用不请求过程中。
为什么要rehash，因为要扩容槽位数为。
渐进式rehash:
为ht[1]分配空间，让dict字典同时持有 ht[0] 和 ht[1] 两个哈希表。
在字典中维持一个索引计数器变量rehashidx，初始时值为-1，代表没有rehash操作，当rehash工作正式开始，会将它的值设置为0。
在rehash进行期间，每次对字典执行添加、删除、查找或者更新操作时，程序除了执行指定的操作以外，还会顺带将ht[0]哈希表在 rehashidx索引(table[rehashidx]桶上的链表)上的所有键值对rehash到ht[1]上，当rehash工作完成之后，将rehashidx属性的值+1，表示下一次要迁移链表所在桶的位置。
随着字典操作的不断执行，最终在某个时间点上，ht[0]的所有桶对应的键值对都会被rehash至ht[1]，这时程序将rehashidx属性的值设为-1，表示rehash操作已完成。
其中ht[0]表是旧表，ht[1]表是新表扩容时候使用，是ht[0]的2倍。
4.排行榜
积分变化时，排名要实时变更。
Zset实现，有序集合。
可以实现key里的排序。
zset数据结构 zskiplist跳表
Redis里是跳表结合hash，因为要存值
5.限流
场景:要求1秒内放行的请求为N,超过N则禁止访问。
利用时间戳。
利用redis的key来实现限流的条件。key上附带时间戳（字符串拼接），value是访问的次数，当1s内，value大于1则限流访问。
5.分布式锁 (多了解一下)
并发场景，要求一次只能有一个协程执行。执行完成后，其他等待中的协程才能执行。
可以借助redis中的setnx实现:
1Redis是单线程执行命令
2setnx只有未设置过才能执行成功。(不一定能解决高并发分布式锁)
Redis使用注意事项
大Key，热Key
大Key是什么?
String类型，value的字节数大于10kb即为大Key
Hash，Set，Zset，list等复杂数据结构，元素个数大于5000或者总value字节数大于10M即为大Key
危害:1.读取成本高 2.容易导致慢查询 3.主从复制异常，服务阻塞，无法正常响应请求
业务方面:请求Reids超时请求。
处理方法:
1.不用大Key
2.拆分与压缩:
拆分：一个String拆成多个String进行拼接。(因为解析字符串耗时间，所以首先想到压缩的方法)
压缩：将value压缩写入redis，读取时解压后再使用。考虑解压时间，因为redis写少读多。JSON-----MessagePack进行序列化。
3.集合类结构hash，lsit，set：
1.拆分:用hash取余，位掩码方式决定放在哪个key里.1---->多
2.区分冷热：例如榜单zset只存前十页，后续走db
热Key:
用户访问一个Key的QPS特别高，导致Server实例出现CPU负载突增或者不均的情况。热Key没有明确的标准，QPS超过500就有可能被识别为热Key.
QPS 网络每秒查询率(query per second)
解决:
1.设置Localcache:
在访问Redis前，在业务服务侧设置Localcache，降低访问Redis的QPS，LoalCache中缓存过期或未命中，则从Redis中将数据更新到LocalCache，Java的Guava，Golang的Bigcache就是这类LocalCache。(即利用当前Server本机的内存)
2.拆分:
讲一个热key复制多份放到Redis里，key不一样，value相同，将QPS分散到不同实例上，降低负载。代价是更新时需要更新多个key，存在数据短暂不一致风险。
3.使用Redis代理的热Key承载能力。（热Key发现和Loalcache功能）
感觉像是sql和redis的翻版，变成了Redis和Localcahce。
根据QPS判断热Key，然后存入Localcache
localcache由proxy来做。
慢查询场景
容易导致慢查询:
1.批量操作，建议单批次不超过100
2.zset大部分命名，大小不超过5k
3.操作的单个value过大，大key
4.对大key的delete和expire操作
缓存穿透，缓存雪崩
缓存穿透:
热点数据查询绕过缓存，直接查询数据库.(Redis服务宕机，原始查询)
危害:
1.查询一个一定不存在的数据，会直接打到db，系统bug或者人为攻击，容易导致db响应慢，宕机。
2.缓存过期时
高并发场景下，热key过期，会有大量请求至db，影响性能和稳定性。
大量key集中过期也会有影响。
方法:
1.缓存空值
如果有人查询一个不存在的userId，在缓存和db中都不存在，可以设置一个空值,下次再查缓存，直接返回空值。
2.布隆过滤器
通过bloom filter算法来存储合法的key，压缩率超高，极小空间存储大量key，能告诉key是否存在，接着进行操作。
缓存雪崩:
大量缓存同时过期，等于缓存失效，直接落到数据库
1.缓存空值
缓存失效时间分散开，在原有失效时间基础加随机值，例如不同key过期时间。
2.使用缓存集群，避免单机宕机造成的缓存雪崩,备用节点。
