Redis教程

redis方案设计

本文主要是介绍redis方案设计,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

jedisCluster.incr,key值+1并返回,将 key 中储存的数字值增一,没有的先设为0再+1并返回,如果 key不存在,那么 key 的值会先被初始化为 0 ,然后再执行 INCR 操作
jedisCluster.expire,设置过期时间
jedisCluster.llen,列表长度
jedisCluster.hincrBy,把对象属性+对应数值
jedisCluster.ttl,当key不存在时,返回 -2 。 当 key 存在但没有设置剩余生存时间时,返回 -1 。否则,以秒为单位,返回 key的剩余生存时间
jedisCluster.setex,为指定的key设置值及其过期时间。如果 key 已经存在, SETEX 命令将会替换旧的值
jedis.eval,执行lua脚本,redis服务器内置lua解释器
hdel 被成功删除字段的数量,可以和hset结合作为请求锁
加解锁最好使用lua脚本,能保证原子性,通过设置key标记值,再设置过期时间的方式没有原子性,一旦中间出问题没有设置成功过期时间,锁有可能永久不会释放了,详情参考LockImpl
1.lpush,从左往右添加元素,在key 对应 list的头部添加字符串元素 rpop右取
2.rpush,从右到左添加元素,在key 对应 list 的尾部添加字符串元素 lpop左取

redis5.0以上支持string hash list set zset geo hyperloglog stream等数据类型
redis模式:主从、哨兵、集群
使用场景:
String:
计数器(incr、decr)、分布式锁(setnx)、存储对象(对象转换为json字符串)

hash:
购物车,以用户id为key,商品id为field,商品数量为value,恰好构成了购物车的3个要素,使用hincrby添加/减少商品个数,hgetall获取列表,hdel删除商品,hlen获取商品数量
较多fields(比如表很多字段,只挑选有用的一些字段存在redis)/序列化消耗较大/只需要获取少量fields的场景,大JSON对象序列化/反序列化比较耗费资源,尤其是在仅需要少量fields时,使用hash结构,可以减少性能和网络传输损耗
比如最好不要存储对象,因为存取需要序列化、反序列化比较耗时,只存有用字段,hmset/hmget很有用

list:
1.简单发布/订阅。list类型的lpop和rpush(或者反过来,lpush和rpop)能实现队列的功能,可以实现简单的点对点消息队列。但是一般不建议使用,因为当前PH-MQ、MQCP的功能已经很完善了
2. 时序相关的列表缓存
  通过lrange等命令可以批量获取list内容,可用于缓存用户发表的朋友圈列表、评论等时序相关数据,但是针对删除、更新等操作支持不佳

set:
黑名单/白名单/好友/关注集合,全量操作成本较高,redis提供了一些很实用的命令用于直接操作这些集合,如:
a. sinter命令可以获得并集
b. sismember命令可以判断集合中是否存在某值
c. scard命令可以获取sets数量

zset:
1. 排行榜,支持score传入票数等排行依据进行排序
2. 延时队列(带有延时功能的消息队列),比如用户下单30分钟后未付款自动关闭订单或者用户下单后延时短信提醒
score作为时间戳,自动按照时间最近的进行排序,启一个线程持续poll并设置park时间,完成延迟队列的设计,可参考Executors.newScheduledThreadPool中的DelayedWorkQueue
3. 滑动窗口限流(指定时间T内,只允许发生N次。我们可以将这个指定时间T,看成一个滑动时间窗口(定宽))
  score作为时间戳,可统计最近一段时间内内的成员数量,实现滑动窗口限流

Geo:
1. 查找附近的人,需要传入坐标信息
  获取方圆20km的10个人,按距离排序:georadiusbymember keyname ireader 20 km count 10 asc

HyperLogLog:
1. 带有一定精度损失的去重统计计数
  海量数据处理,存在精度缺失问题,最高损失0.81%精度,适用场景:
  a. 统计注册 IP 数
  b. 统计每日访问 IP 数
  c. 统计页面实时 UV 数
  d. 统计在线用户数
  e. 统计用户每天搜索不同词条的个数
       不适用需要精准判断的场景,如黑名单,以免误伤
       
Redis 内存淘汰算法
随机
TTL(从设置了过期时间的 Keys 中获取最早过期的 一批 Keys,然后淘汰这些 Keys)
LRU(Least Recently Used,通过 Key 的最后访问时间来判定哪些 Key 更适合被淘汰)
LFU(Least Frequently Used,最不经常使用,访问次数)  
Redis驱逐策略(基于淘汰算法)
noeviction:达到内存限额后返回错误,客户尝试可以导致更多内存使用的命令(大部分写命令,但DEL和一些例外)
allkeys-lru:为了给新增加的数据腾出空间,驱逐键先试图移除一部分最近使用较少的
volatile-lru:为了给新增加的数据腾出空间,驱逐键先试图移除一部分最近使用较少的,但只限于有过期设置的驱逐key
allkeys-random: 为了给新增加的数据腾出空间,驱逐任意key
volatile-random: 为了给新增加的数据腾出空间,驱逐任意key,但只限于有过期设置的驱逐key
volatile-ttl: 在设置了过期时间的key空间中,具有更早过期时间的key优先移除

Redis使用规范
禁止使用较长key,可以使用md5后的值
禁用keys、flushall、flushdb等命令
必须设置缓存过期时间,不能把Redis当做持久化存储的数据库(不绝对,长期热点数据比如配置信息可以不过期)
禁止存储大value,可以使用不同key分片存储在不同集群节点
使用批处理操作提高效率,原生的可以使用mget、mset,非原生可以使用pipeline(多个命令一起提交,不支持事务,主要是减少网络延迟)
一个应用对应一个Redis实例,避免相互覆盖数据

常见问题及解决方案
缓存失效(过期了,正常业务场景)

缓存击穿,缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库去取数据,引起数据库压力瞬间增大,造成过大压力。设置热点数据(比如配置)不过期,设置数据中过期时间大于实际过期时间,加锁读取数据库
对该key的请求进行拦截

缓存穿透
缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者,攻击会导致数据库压力过大。接口层增加校验,如用户鉴权校验,id做基础校验,id<=0的直接拦截。设置排队锁排队访问

缓存雪崩
缓存在同一时间内大量键值过期(失效),需从数据库中获取数据,大量并发请求访问数据库,影响系统稳定。设置排队锁,在并发访问时,排队访问。缓存超时时间设置时,增加一个随机时间长度,避免所有缓存在同一时间失效。建立缓存备份机制(例如:运用本地缓存+分布式缓存互为备份,Redis自动备份)。定时任务更新缓存并续期

缓存污染(多发生在本地缓存,没有深拷贝,改变了对象引用值)

缓存一致性方案
弱一致性方案
先更新数据库,再更新缓存
这套方案,大家是普遍反对的。为什么呢?有如下两点原因。原因一(线程安全角度)同时有请求A和请求B进行更新操作,那么会出现(1)线程A更新了数据库(2)线程B更新了数据库(3)线程B更新了缓存(4)线程A更新了缓存这就出现请求A更新缓存应该比请求B更新缓存早才对,但是因为网络等原因,B却比A更早更新了缓存。这就导致了脏数据,因此不考虑。原因二(业务场景角度)有如下两点:(1)如果你是一个写数据库场景比较多,而读数据场景比较少的业务需求,采用这种方案就会导致,数据压根还没读到,缓存就被频繁的更新,浪费性能。(2)如果你写入数据库的值,并不是直接写入缓存的,而是要经过一系列复杂的计算再写入缓存。那么,每次写入数据库后,都再次计算写入缓存的值,无疑是浪费性能的。显然,删除缓存更为适

先删除缓存,再更新数据库(不推荐)
该方案会导致不一致的原因是。同时有一个请求A进行更新操作,另一个请求B进行查询操作。那么会出现如下情形:(1)请求A进行写操作,删除缓存(2)请求B查询发现缓存不存在(3)请求B去数据库查询得到旧值(4)请求B将旧值写入缓存(5)请求A将新值写入数据库上述情况就会导致不一致的情形出现。而且,如果不采用给缓存设置过期时间策略,该数据永远都是脏数据

先更新数据库,再删除缓存(推荐)
先更新数据库,再延迟删除缓存
监听binlog更新redis(不推荐,容易出问题)

强一致性方案
通过加锁

     

这篇关于redis方案设计的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!