Redis
redis数据结构
- String 字符串
- 内部实现通过SDS来存储,类似于Java中的ArrayList,可以通过预分配冗余空间的方式来减少内存的频繁分配
- 简单的KV缓存
- 可以用作计数器,实现计数和查询的功能
- 共享用户session
- Hash 字典
- List 列表
- 存储列表型的数据结构,例如粉丝列表,文章的评论列表
- 通过Irange命令,基于List实现分页查询
- 简单的消息队列
- Set 集合
- 交集、并集、差集,可以用交集实现共同好友
- SortedSet 有序集合
- 自动去重
- 排行榜的实现
高级用法
- Bitmap:位图,支持按bit位存储信息,可以用来实现布隆过滤器
- HyperLogLog:不精确的去重计数功能,适合用来做大规模数据的去重统计
- Geospatial:保存地理位置,位置距离计算或根据半径计算位置
- pub/sub 订阅发布功能,用作简单的消息队列
- Pipeline:批量执行一组指令,一次性返回全部结果,减少频繁的请求应答。
- LUA:Lua脚本,执行一系列的功能,具备原子性
- 事务:不严格,只能保证串行执行,执行命令失败时不会回滚。
redis分布式锁
先用setnx来争夺锁,用expire设置有一个国企时间防止锁忘记释放
若在repire之前进程意外crash或重启维护
- 可以吧setnx和expire指令合成一条使用
- keys指令扫描指定模式的key列表
- redis是单线程的,keys指令会导致线程阻塞,线上服务停滞,可以使用scan指令,无阻塞提取,担忧一定的重复概率,需要在客户端做一次去重。
redis做异步队列
用list结构作为队列,rpush生产消息,lpop消费消息。当lpop没有消息的时候,适当sleep一会再重试
- 不用sleep的情况下可以使用blpop,在lpop没有消息的时候,会阻塞指导消息到来
- 使用pub/sub主题订阅者模式,可以实现1:N的消息队列。
- pub/sub的缺点在消费者下线时,生产的消息会丢失。
redis如何实现延时队列 - 使用sortedset,使用时间戳为score,消息队列为key调用zadd来生产消息,消费者用zrangebyscore指令获取N秒之前的数据轮训进处理。、
Redis的同步机制
redis可以使用主从同步,从从同步。第一次同步时,主节点使用bgsave,将后续修改操作记录到内存buffer中,将RDB文件复制到复制节点。复制节点将RDB镜像家挨刀内存,操作重放。后续增量数据通过AOF日志同步。
redis集群
Redis Sentinal着眼于高可用,在master宕机时会自动将slave提升为master,继续提供服务。
Redis Cluster着眼于扩展性,在单个redis内存不足时,使用Cluster进行分片存储。
Redis高可用
选择主节点策略
- slave的priority设置的越低,优先级越高
- 同等条件下,slave复制的数据越高优先级越高
- 相同条件下runid越小越容易被选中
哨兵机制
哨兵必须要用三个实例去保证自己IDE健壮性,哨兵+主从并不能保证数据不丢失,但是可以保证集群的高可用。
哨兵的主要功能
- 集群监控:负责监控Redis master和slave进程是否正常工作
- 消息通知:如果某个Reids实例有故障,哨兵负责发送消息作为报警通知管理员
- 故障转移:如果master node挂掉了,自动转移到slave node上
- 配置中心:发生故障转移时,通知client客户端新的master地址
Redis淘汰策略
- FIFO淘汰最早数据
- voeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令
- LRU剔除最近最少使用
- allkeys-lru:超时回收最少使用的键
- volatile-lru
- LFU剔除最近使用评率最低
- allkeys-random:回收随机的键
- volatile-random:回收随机的键,但仅限于在过期集合的键
- valatile-ttl:回收再国企集合的键,并且优先回收存活时间较短的键
如果有没键满足回收的前提条件的话,volatile-*和noeviction差不多。
1、缓存穿透
缓存穿透,是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是,数据查询先进行缓存查询,如果key不存在或者key已经过期,再对数据库进行查询,并把查询到的对象,放进缓存。如果数据库查询对象为空,则不放进缓存。
public EsGoods getGoods(Long goodsId){
Object object = redisTemplate.opsForValue().get(String.valueOf(goodsId));
if(object != null){
return (EsGoods)Object;
}else {
//redis为空时查询数据库
EsGoods goods = esGoodsMapper.getGoods(goodsId);
if(goods != null){
redisTemplate.opsForValue().set(String.valueOf(goodsId),goods,60);
}
return goods;
}
}
代码流程
(1)、参数传入对象主键ID
(2)、根据key从缓存中获取对象
(3)、如果对象不为空,直接返回
(4)、如果对象为空,进行数据库查询
(5)、如果从数据库查询出的对象不为空,则放入缓存(设定过期时间)
**在这种情况下,如果传入的参数为-1,这个-1,就是一定不存在的对象。就会每次都去查询数据库,而每次查询都是空,每次又都不会进行缓存。假如有恶意攻击,就可以利用这个漏洞,对数据库造成压力,甚至压垮数据库。即便是采用UUID,也是很容易找到一个不存在的KEY,进行攻击。
解决方案:
- 会式采用缓存空值的方式,也就是从数据库查询的对象为空,也放入缓存,只是设定的缓存过期时间较短,比如设置为60秒。
- 采用布隆过滤器,存在性检测,如果布隆过滤器中华不存在,则实际数据也可能会不存在
Bloon Filter(布隆过滤器)
布隆过滤器(英语:BloomFilter)是1970年由一个叫布隆的小伙子提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法,缺点是有一定的误识别率和删除困难。
布隆过滤器的原理是,当一个元素被加入集合时,通过K个散列函数将这个元素映射成一个位数组中的K个点,把它们置为1。检索时,我们只要看看这些点是不是都是1就(大约)知道集合中有没有它了:如果这些点有任何一个0,则被检元素一定不在;如果都是1,则被检元素很可能在。这就是布隆过滤器的基本思想。
缺点
- 牺牲了判断的准确率,删除的便利性
- 存在误判 可能要查到的元素没有在容器中,但是hash之后得到的k个位置上都是1。可以通过建立一个白名单来存储可能误判的元素
- 删除困难。一个放入容器的元素映射到bit数组上的k个位置是1,删除的时候不能简单的置位0,可能影响其他元素的判断。可以采用计数布隆过滤器
常见应用场景 - cerberus在收集监控数据的时候, 有的系统的监控项量会很大, 需要检查一个监控项的名字是否已经被记录到db过了, 如果没有的话就需要写入db.
- 爬虫过滤已抓到的url就不再抓,可用bloom filter过滤
- 垃圾邮件过滤。如果用哈希表,每存储一亿个 email地址,就需要 1.6GB的内存(用哈希表实现的具体办法是将每一个 email地址对应成一个八字节的信息指纹,然后将这些信息指纹存入哈希表,由于哈希表的存储效率一般只有 50%,因此一个 email地址需要占用十六个字节。一亿个地址大约要 1.6GB,即十六亿字节的内存)。因此存贮几十亿个邮件地址可能需要上百 GB的内存。而Bloom Filter只需要哈希表 1/8到 1/4 的大小就能解决同样的问题。
public EsGoods getGoods(Long goodsId){
Object object = redisTemplate.opsForValue().get(String.valueOf(goodsId));
if(object != null){
return (EsGoods)Object;
}else {
//redis为空时查询数据库
EsGoods goods = esGoodsMapper.getGoods(goodsId);
if(goods != null){
redisTemplate.opsForValue().set(String.valueOf(goodsId),goods,60);
} else {//当数据库为空的时候也要存入redis
redisTemplate.opsForValue().set(String.valueOf(goodsId),null,60);
}
return goods;
}
}
2、缓存雪崩
缓存雪崩,是指在某一个时间段,缓存集中过期失效。
产生雪崩的原因之一,比如在写本文的时候,马上就要到双十二零点,很快就会迎来一波抢购,这波商品时间比较集中的放入了缓存,假设缓存一个小时。那么到了凌晨一点钟的时候,这批商品的缓存就都过期了。而对这批商品的访问查询,都落到了数据库上,对于数据库而言,就会产生周期性的压力波峰。
解决方案:一般是采取不同分类商品,缓存不同周期。在同一分类中的商品,加上一个随机因子。这样能尽可能分散缓存过期时间,而且,热门类目的商品缓存时间长一些,冷门类目的商品缓存时间短一些,也能节省缓存服务的资源。
3、缓存击穿
缓存击穿,是指一个key非常热点,在不停的扛着大并发,大并发集中对这一个点进行访问,当这个key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像在一个屏障上凿开了一个洞。
解决方案:
- 在电商项目中,对主打商品都是早早的做好了准备,让缓存永不过期。即便某些商品自己发酵成了爆款,也是直接设为永不过期就好了。
- 互斥锁更新,减小DB压力
- 随机退避方式,失效时随机sleep一个很短的时间,再次查询,如果失败则执行更新
redis是单进程单线程的,解决并发问题
Redis为单进程单线程模式,采用队列模式将并发访问变为串行访问。Redis本身没有锁的概念,Redis对于多个客户端连接并不存在竞争,但是在Jedis客户端对Redis进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题,这些问题均是由于客户端连接混乱造成。对此有2种解决方法:
1.客户端角度,为保证每个客户端间正常有序与Redis进行通信,对连接进行池化,同时对客户端读写Redis操作采用内部锁synchronized。
2.服务器角度,利用setnx实现锁。
注:对于第一种,需要应用程序自己处理资源的同步,可以使用的方法比较通俗,可以使用synchronized也可以使用lock;第二种需要用到Redis的setnx命令。
redis持久化的几种方式
- 1快照(snapshots)
缺省情况下,Redis把数据快照存放在磁盘上的二进制文件中,文件名为dump.rdb。你可以配置Redis的持久化策略,例如数据集中每N秒钟有超过M次更新,就将数据写入磁盘;或者你可以手工调用命令SAVE或BGSAVE。
工作原理- Redis forks.
- 子进程开始将数据写到临时RDB文件中。
- 当子进程完成写RDB文件,用新文件替换老文件。
- 这种方式可以使Redis使用copy-on-write技术。
- 2、AOF
快照模式并不十分健壮,当系统停止,或者无意中Redis被kill掉,最后写入Redis的数据就会丢失。这对某些应用也许不是大问题,但对于要求高可靠性的应用来说
Redis就不是一个合适的选择。
Append-only文件模式是另一种选择。你可以在配置文件中打开AOF模式 - 3、虚拟内存方式
当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大. 当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value.
vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的.可能会造成比较长时间的延迟,但是对数据完整性有很好的保证.
自己测试的时候发现用虚拟内存性能也不错。如果数据量很大,可以考虑分布式或者其他数据库。
Redis和Mamcache比较
MC特点
- 处理请求时使用多线程异步IO的方式,可以利用CPU多核的优势,性能优秀
- 功能简单,使用内存存储诗句
- 对缓存数据可以设置失效期,国企数据清除
- 失效策略采用延迟失效,就是当再次使用数据时检查是否失效
- 容量存满时,对缓存中的数据进行剔除
限制 - key不能超过250个字节
- value不能超过1M字节
- key的最大失效时间是30天
- 只支持K-V结构,不提供持久化和主从同步
Redis - 采用单线程模式处理请求
- 采用了非阻塞的异步事件处理机制
- 缓存数据都是内存操作,避免线程上下文切换锁产生的代价
- 支持持久化
- 除了K-V之外,支持多种数据格式
- 提供主从同步机制,以及Cluster集群部署能力。