赞
踩
用户查询的数据在缓存和数据库中都不存在
这样的请求每次都会打到数据库上
解决方案:
1.缓存空字符串(额外的内存消耗,可能造成短期的不一致)
2.布隆过滤(内存占用少,没有多余key,实现复杂,存在误判可能)
对于数据库中没有的数据,向缓存中缓存空值,别再访问数据库了,减少压力
更新数据库的时候,先更新数据库,再删除缓存
实现强一致性,需要使用分布式锁控制,修改数据和向缓存存数据使用同一个分布式锁
实现最终一致性,缓存数据要加过期时间
对于实时性要求强的,要实现数据强一致性要尽量避免使用缓存
同一时间大量的key失效或者redis宕机
解决方案:
1.过期时间可以设置随机数,如30+(0~5)分钟随机,不要同时过期
2.使用redis集群提高可用性
3.给缓存业务添加降级限流策略
4.给业务添加多级缓存
热点key问题
某些Key属于极端热点数据,且并发量很大的情况下,如果这个key过期,可能会在瞬间出现大量的并发请求直接打到了数据库
常见解决方案
互斥锁:
线程在重建缓存数据时,进行加锁,其他线程等待重试,直到释放锁之后,其他线程就可以缓存命中了
保证一致性,实现简单
其他线程需要等待,可能有死锁风险
逻辑过期:
对数据加一个过期时间字段,但并不实际设置过期时间,始终在redis当中。
校验发现逻辑时间过期时,获得互斥锁,开新线程去重建缓存数据,本线程返回那个过期的数据
对于其他线程,发现缓存中数据逻辑时间过期时,尝试获取互斥锁失败,就直接返回过期数据。
线程无需等待,不保证一致性
# 全局唯一ID生成策略
UUID
Redis自增
snowflake
数据库自增
在分布式系统下用来生成全局唯一ID的工具
(唯一性,高可用,高性能,递增性,安全性)
Long型,8个字节
多个线程在操作共享的变量\资源
解决方案:加锁
悲观锁:认为线程安全问题一定会发生,在操作数据之前先获取锁,确保线程串行执行(Synchronized,Lock)
乐观锁:认为线程安全问题不一定会发生,因此不加锁,只在更新数据时去判断有没有其他线程对数据做了修改
常见方案:
1.版本号法
给数据加上一个版本字段
2.CAS法
单机情况下由于有锁,所以安全
但是集群模式下,synchronized并不能保证集群并发安全性
需要多进程可见互斥的分布式锁
# lua脚本
eval "lua_script" NumberOfKeys key argv
redisson可重入锁原理
"lockName":{
"threadId": "重入次数"
}
# 利用hash结构记录线程对应的重入次数
获取锁时锁已存在:
看线程标识是否是自己,是自己,锁计数value+1(并且重置有效期),不是自己获取锁失败
获取锁时锁不存在:
获取锁,并添加线程标识,锁计数为1,设置有效期
释放锁时:
线程标识是自己:锁计数减一,且重置有效期(减完如果为0,则释放锁)
线程标识不是自己:说明已经超时释放
-- 获取锁 local key = KEYS[1]; --锁的名字 local threadId = ARGV[1]; --线程标识(fieldName),对应的value是重入次数 local releaseTime = ARGV[2]; -- 过期时间(自动释放) -- 锁不存在 if(redis.call('exists',key) == 0) then redis.call('hset',key,threadId,'1'); -- 将field(threadId)对应的value置为1 redis.call('expire',key,releaseTime); return 1; end; -- 锁已存在(且线程标识是自己) if(redis.call('hexists',key,threadId) == 1) then redis.call('hincrby',key,threadId,'1'); -- 重入次数+1 redis.call('expire',key,releaseTime); return 1; end; return 0; -- 说明锁已存在但线程标识不是自己,获取锁失败
-- 释放锁 local key = KEYS[1]; -- 锁名 local threadId = ARGV[1]; --线程标识(fieldName),对应的value是重入次数 local releaseTime = ARGV[2]; -- 过期时间(自动释放) -- 线程标识不是自己(不用管) if(redis.call('HEXISTS',key,threadId) == 0) then return nil; end; -- 是自己,重入次数-1 local count = redis.call('HINCRBY',key,threadId,-1); if(count > 0) then redis.call('EXPIRE',key,releaseTime); return nil; else redis.call('DEL',key); -- 重入次数为0,则释放锁(删除) return nil; end;
可重试原理:
第一次获取锁失败以后,等待释放锁的消息(redis中pubsub机制),释放锁的时候会发送这样的消息
得到消息后,重新获取锁,再次失败会继续等待消息
会有等待时间,超过时间不会再重试
超时续约问题:
默认的锁释放时间是30s
获取锁成功以后,会开启一个延时定时任务,每隔一段时间,不断的刷新有效期,直到手动释放锁
释放锁的时候:会取消掉定时任务
解决主从一致性问题(使用multilock,只要有一个主节点没挂,就是安全的)
redis消息队列和阻塞队列区别
1.消息队列是在JVM内存以外的独立服务,不受JVM内存限制
2.消息队列里的消息会做持久化,不管服务宕机还是重启,数据不会丢失
3.消息投递给消费者以后,要求消费者做消息的确认,没有确认,消息就会在队列中依然存在,确保消息至少被消费一次
# 发送消息
XADD 队列名 *(表示消息id自动生成) field value [field value ...]
# 创建名为users的队列,发送一条消息{name:jack,age:21},消息id自动生成
XADD users * name jack age 21
# 消费消息(消息可以被重复消费,并不会删除)
# 阻塞读取一条消息, 阻塞时长1秒, 从users队列中读取消息, $表示读取最新的消息
XREAD COUNT 1 BLOCK 1000 STREAMS users $
消费者组:将多个消费者划分到一个组当中,监听同一队列
有以下特点:
1.队列中的消息会分流给组内不同的消费者, 同一个消费者组内的消费者是竞争关系, 不会重复消费
2.消费者组会维护一个标识,记录最后一个被处理的消息,哪怕消费者宕机重启,还会从标识后读取消息
3.消费者获取消息后,消息处于pending状态,并存入pending-list,处理完成以后需要使用XACK来确认消息,标记已处理,才会从pending-list移除
发布文章时,推送给所有的粉丝
使用GEO数据结构(基于SortedSet) # 添加一个地理信息 # GEOADD key longitude latitude member [longitude latitude member ...] # Add one or more geospatial items in the geospatial index represented using a sorted set # key是g1,成员是(bjn,bjz,bjx) GEOADD g1 116.378248 39.865275 bjn 116.42803 39.903738 bjz 116.322287 39.893729 bjx # bjn和bjx的距离(单位米) GEODIST g1 bjn bjx GEODIST g1 bjn bjx km # 单位(km) # 返回成员bjn的地理坐标 GEOPOS g1 bjn # 将指定成员的地理坐标转为hash字符串并返回 GEOHASH g1 bjn # 北京天安门附近10km内的地理坐标信息(升序列出) GEOSEARCH g1 FROMLONLAT 116.397904 39.909005 BYRADIUS 10 km WITHDIST
# 用一个二进制串表示本月中的签到情况,每一位表示其中的某一天
setbit bm1 5 1 # 第6天签到(1表示签到,默认是0)
getbit bm1 2 # 查看第3天是否签到
bitcount bm1 # 值为1的位数
bitfield bm1 get u3 0 # 从索引0位开始,查3位,返回值是十进制,u表示无符号
UV:Unique Visitor,独立访客量,一天内同一用户多次访问只记录一次
PV:Page View,页面访问量\点击量,每次访问页面,都会记录
# 大用户量的时候,做UV统计要判断是否已统计过,需要存数据,是一个巨大的数据量
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。