Redis 笔记

https://blog.csdn.net/ZY_Coldnai/article/details/125153335

String

SET name “value”
Ok
GET name
“Value”

Hash(map)
HMSET key value1 value2 value3
Ok
HGETALL key
“value1” “value2” “value3”
hset 给集合中的 键赋值
hget 从key1中取出指定的field对应的value
hmset … 批量插入key1的filed-value对
hexists 查看哈希表key中，给定的field是否存在
hkeys 列出该key的所有field
hvals 列出该hash集合的所有value
hincrbu 为哈希表key中的域field的值加上

List
lpush key value1
(integer) 1
lpush key value2
(integer) 2
lrange key 0 10
“value1”
“value2”

Set: sadd key member
sadd key value1
(integer) 1
sadd key value2
(integer) 1
sadd key value1
(integer) 0
smembers key
“value1”
“value2”

zset: zadd key score member
zadd key 100 ming
(integer) 1
zadd key 20 hong
(integer) 1
如同样的key中已经有了同样的member，则只更新score，并重排序
如key已经在redis中存在，而不是zset类型，就报错
默认排序：按score从小到大排序

ZRANGE key 0 -1 [WITHSCORES]
查看所有元素，选择是否展示score
ZRAM key member1 member2
删除单个或者多个元素，元素不存在，返回0
ZCARD key
返回key 成员的个数
ZCOUNT key min max
返回key中分数在min 和max之间的member个数
ZSCORE key member
返回 key中member的score值
ZINCRBY key increment member
对key中member的分数值增加increment,若是负数就是减少
ZRANGE key start stop [WITHSCORES]
返回指定key的指定下标的member ，选择是否带score 下标是从0开始，从小到大的排序
ZREVRANGE key start stop [WITHSCORES] 从大到小的排序
ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]
返回分数从小大的区间的member ,LIMIT 指定返回结果的数量，与 sql 中的 limit 一样
ZREVRANGEBYSCORE key max min [WITHSCORES] [LIMIT offset count]
与ZRANGEBYSCORE用法一样，只是返回的成员按照 分数从大到小排列
ZRANK key member
返回指定key 的成员排名，按照分数 从小到大排列，其中返回的排名是以 0 开始
ZREVRANK key member
与 ZRANK 的用法相同，区别就是按照分数 从大到小排列
ZREMRANGEBYRANK key start stop
移除指定 key 的指定排名介于 start 和 stop 之间的成员，同样排名以 0 开始。
REMRANGEBYSCORE key min max
移除指定key的 分数介于 min 和 max 之间的成员
ZINTERSTORE sum_key 2 key_1 key_2
把 key_1 和 key_2 根据 成员 把相关的 分数加起来到一个新的集合 sum_key
ZUNIONSTORE union0 2 key_2 key_3
UNION key_2 key_3　没有写　乘法因子　默认是　１
ZUNIONSTORE union1 2 key_2 key_3 WEIGHTS 2 2
UNION key_2 key_3 并对key_2,key_3两个key下面的member对应的score值*2

redis过期删除策略
分为三种：定时删除、定期删除、惰性删除。其中，定时删除和定期删除是主动删除策略，惰性删除是被动删除策略
定时删除：在redis的redis.h文件中写一个timer定时器，只要key一过期就会执行删除
代码在redis.c的activeExpireCycle函数，需要传个type参数，用以区分是用“快速模式”还是“正常模式”
惰性删除：是在使用这个key时才做过期判断，并删除

定期删除：每隔一段时间，程序就会对 Redis 数据进行一次检查，删除里面的过期 key，至于要删除多少过期 key，以及要检查多少个 db，则是由 Redis 内部算法决定

注意：1-默认100ms执行一次扫描，随机抽取一定的数量（如20个key），删除这20个key中过期的key，若超过1/4过期了，说明过期数量多，那么就会重复执行抽取再删除，不然就等待下一个周期。2-默认设置扫描时长上限为25ms，这也是防止扫描时间过长，增加服务器负担；3-防止大量key过期，导致同一时间过期key超过总扫描的1/4，设置过期时间分散；4-从redis不会执行过期策略，只会被同步执行是自动del

内存淘汰策略
当 Redis 的内存占用超过我们设置的 maxmemory 时，会把长时间没有使用的key清理掉。按照 LRU算法，我们需要对所有key（也可以设置成只淘汰有过期时间的key）按照空闲时间进行排序，然后淘汰掉空闲时间最大的那部分数据，使得Redis的内存占用降到一个合理的值
*LRU算法的缺点：*维护一个全部（或过期）key的列表，还要按照最近使用时间排序，消耗内存和cpu资源
Redis采用了一种 近似LRU 的算法
Redis首先是采样了一部分key，这里采样数量 maxmemory_samples 通常是5，我们也可以自己设置，采样数量越大，结果就越接近LRU算法的结果，带来的影响是：性能随之变差
清理策略

1. noeviction：不会继续处理写请求（DEL可以继续处理）。
2. allkeys-lru：对所有key的近似LRU
3. volatile-lru：使用近似LRU算法淘汰设置了过期时间的key
4. allkeys-random：从所有key中随机淘汰一些key
5. volatile-random：对所有设置了过期时间的key随机淘汰
6. volatile-ttl：淘汰有效期最短的一部分key
   Redis4.0 开始支持了 LFU 策略，和 LRU 类似，它分为两种：
7. volatile-lfu：使用LFU算法淘汰设置了过期时间的key
8. allkeys-lfu：从全部key中进行淘汰，使用LFU

redis 4.0 引入了 lazyfree 的机制
它可以将删除键或数据库的操作放在后台线程里执行， 从而尽可能地避免服务器阻塞。
unlink 指令，它能对删除操作进行懒处理，丢给后台线程来异步回收内存。

unlink key
OK

Redis 中 flushall 和 flushdb 的区别
flushall 清空redis并持久化数据到rdb
flushdb 清空redis但不持久化，rdbd的数据没有变化，所以要恢复数据，可以进行重启redis恢复

基础
1.QPS10万，单线程
2.IO多路复用-reactor模式：事件驱动机制
3.redis的事务操作
multi 开启一个事务
exec执行一个事务
事务执行非原子性，也就是中间一个失败，不回滚之前的也不会中断之后的
discard 取消事务，放弃执行事务块内的所有命令
watch keys 监视一个或多个key，执行事务之前若执行key被其他命令修改，事务中断
unwatch 取消所有的key监视
4.redis lua命令和原理：保证redis批量操作原子性
5.1.单线程；2.核心4部分：多个socket，IO多路复用程序，文件事件分派器，事件处理器（分别：请求命令，回复处理命令，连接应道命令）多个socket并发产生多个不同操作，IO多路复用程序进行监听，但是会将socket放到队列中排序，每次从队列中取出一个socket给事件分派器，事件分派器根据事件类型，分配给不同的事件处理器
https://blog.csdn.net/liu_xue_xue/article/details/115449259
redis单线程模式如何实现高性能
https://wenku.baidu.com/view/a8bb7604fc00bed5b9f3f90f76c66137ee064f2f.html
6.

布隆过滤器
bitmap

集群分布式锁

1. 2.6版本之前命令：setnx key value;2.expire key 过期时间，分两步会导致原子性问题，2.6版本之后：setex
2. setex与setnx的区别，setex当key存在进行覆盖，setnx当key存在不做任何操作，setex可以同步加过期时间
3. redlock红锁算法：在集群条件下（只有主节点，没有主从关系），2/N+1个节点加锁成功才算加锁成功，分布式加锁的实际有效时间=过期时间-加锁成功耗时
4. 锁续命：1-当我们的业务执行时间>redis锁的时间，为了防止我们的业务未完成，但是锁的时间到期了又不让其到期，那么我们要做的就是对锁续命；2-通过守护线程和lua命令，在我们判断业务未完成时，对分布式锁增加时间续命；3-watch dog 客户端一旦加锁成功，就会启动看门狗，一个后台线程，会每隔10秒检查一次，如客户端还持有这个锁，那么就会不断延长key过期时间，重置过期时间，若客户端宕机了，那么就不能延期了
5. 缓存穿透；缓存和数据库种都没有，重复访问攻击，接口增加校验如用户鉴权，id做基础校验，不正常id直接拦截；设置key对应的value为空同时对缓存数据进行有效期；
   缓存击穿：同一数据缓存没有，数据库中有数据；设置热点数据永不过期，业务限流或降级；增加key集合，先判断集合中是否存在再判断是否去读取缓存值；对key加锁或者标识设置加锁时间
   缓存雪崩：缓存批量数据过期，导致数据压力大或者down机；数据过期时间随机，防止同一时间大量数据过期；分布式部署缓存分散热点数据；热点永不过期

redis大key问题

redis集群的三种方式
主从模式
读写分离，多个从节点
不能自动容错和恢复功能，主节点故障，集群无法使用，从节点升级为主节点，需要人工介入
哨兵模式
主从模式的复制，也是只有一个主机来接受和处理写请求，多了一个竞选机制，依赖于在系统中启动一个sentinel进程
哨兵本身也有单点故障，在一个一主多从的redis系统中，多个哨兵监控，哨兵不仅会监控主从节点，哨兵之间也会相互监控。每个哨兵都是一个独立的进程，独立运行。
redis cluster
一致性哈希算法
每一个mater节点负责一部分槽slot，每个master对应多个slave，客户端不用链接集群中所有节点，链接集群中任何一个可用节点即可，去中心化，每个节点都知道其他节点的存储信息
部分节点不可用时，集群任可用
自动扩缩容，slot迁移，且不影响正常使用