我们项目中之所以选择Redis,主要是因为Redis有下面这些优点:
Redis最常见的数据类型有5种,分别是String、List、Hash、Set、ZSet,下面给您详细介绍一下:
String:简单的 key-value 类型,最大能存储512MB数据。场景:计数、缓存文章标题、微博内容等
List:底层是链表,特点是:增删容易,随机访问困难。场景:发布与订阅或者说消息队列
Hash:类似于Java中的HashMap,适合存储对象。场景:系统中对象数据的存储
Set:是一种无序集合,可以方便的求交、并、差集。 场景:共同关注、共同粉丝、共同喜好等功能
ZSet:相比于set来讲,多了1个权重参数 score,元素会按照score进行排序。场景:各种排行榜,弹幕消息
Redis之所以运行速度比较快,主要是由于这样一些原因:
纯内存操作:Redis的绝大部分请求是纯粹的内存操作,非常快速
单线程:Redis的核心部分是单线程运行的,避免了不必要的上下文切换,也不存在线程切换导致的 CPU消耗
使用 I/O 多路复用模型和非阻塞 IO
什么是 I/O 多路复用
I/O多路复用是指利用单个线程来同时监听多个Socket ,并在某个Socket可读、可写时得到通知,从而避免无效的等待,充分利用CPU资源
目前的I/O多路复用都是采用的epoll模式实现,它会在通知用户进程Socket就绪的同时,把已就绪的Socket写入用户空间,不需要挨个遍历Socket来判断是否就绪,提升了性能
其中Redis的网络模型就是使用I/O多路复用结合事件的处理器来应对多个Socket请求,比如,提供了连接应答处理器、命令回复处理器,命令请求处理器
在Redis6.0之后,为了提升更好的性能,在命令回复处理器使用了多线程来处理回复事件,在命令请求处理器中,将命令的转换使用了多线程,增加命令转换速度,在命令执行的时候,依然是单线程
Redis的过期删除策略指的是当Redis中的key过期之后在什么时候进行删除的处理方案,常用的删除策略就两个:
两者相比,定期删除对内存更加友好,惰性删除对 CPU 更加友好。两者各有千秋,所以 Redis 采用的是定期删除+惰性/懒汉式删除。
Redis的内存淘汰策略指的是当Redis的内存已经存满,又有新的数据需要保存时的处理方案,官方提供了8种淘汰策略:
Redis是一个基于内存的数据存储,为了保证数据安全,需要将内存中的数据备份到磁盘上,官方提供了两种数据持久化的方式,分别是RDB和AOF
RDB采用的是定期更新的方式,它会定期将Redis中的数据生成的快照同步到磁盘上,磁盘上保存的就是Redis的内存快照
优点是数据文件的大小相比于AOF较小,数据恢复速度较快
缺点是比较耗时,存在丢失数据的风险
AOF是将Redis所执行过的所有写指令都记录到磁盘上,在下次Redis重启时,只需要将指令重写一遍就可以了
优点是数据丢失的风险大大降低了
缺点是数据文件的大小相比于rdb较大,而且数据恢复的时候速度较慢
在我们公司是同时开启RDB和AOF 持久化机制的,这样做的好处是:
appendfsync
参数为 everysec
,保证每秒将AOF缓冲区中的写操作同步到 AOF 文件中,提高数据的持久化能力这样的配置可以充分利用RDB和AOF两种持久化机制的优势,提高数据的可靠性和恢复能力
Redis在进行RDB期间是可以同时处理写请求的,这得益于Redis使用操作系统的多进程写时复制技术来实现快照持久化
具体来说,就是Redis在持久化时会产生一个子进程,快照持久化完全交给子进程来处理,父进程继续处理客户端请求
当主线程执行写指令修改数据的时候,这个数据就会复制一份副本, 子进程读取这个副本数据写到 RDB 文件
这既保证了快照的完整性,也允许主线程同时对数据进行修改,避免了对正常业务的影响
在Redis中提供的集群主要有三种,分别是主从、哨兵和分片集群
主从集群主要用来解决Redis的并发问题,一般是一个主节点负责数据写入,多个从节点负责数据读取,主节点的数据会实时同步给从节点
哨兵集群主要用来解决Redis的高可用问题,哨兵会监控集群中节点的状态,并在主节点出现问题时进行重新选主
分片集群主要用来解决Redis的海量数据存储问题,它要求有多个主节点,然后数据写入的数据会经过计算落到其中一个上
在这个计算的过程中Redis引入了哈希槽的概念,Redis集群有16384个哈希槽,每个 key通过CRC16校验后对16384取模来决定放置哪个槽
而分片集群的每个节点负责一部分 hash 槽,这样就可以计算出一个key会出现在哪个节点上了,查询的时候也是同时的方式来定位即可
保证Redis和MySQL数据一致性的方案有很多,最常见的有三种
缓存预热是指系统上线后,提前将相关的缓存数据加载到缓存系统。
避免在用户请求的时候,先查询数据库,然后再将数据缓存的问题,用户直接查询事先被预热的缓存数据。
如果不进行预热,那么 Redis 初始状态数据为空,系统上线初期,对于高并发的流量,都会访问到数据库中,对数据库造成流量的压力。
缓存预热解决方案主要有下面几个:
在我们的项目中会将缓存放到数据库前面,查询的时候先查缓存,缓存有了就不用再去查数据库了,这样可以大大减轻数据库的访问压力
而缓存穿透指的是请求一直在查询一个数据库中不存在的数据,这样缓存中没有,请求就会到达数据库,而数据库也没有,也就没法缓存
所以每一次请求都会直接到数据库中查询,这就极有可能导致数据库被压垮
常用的解决方案有两个:
查询返回的数据为空,仍把这个空结果进行缓存,但过期时间尽量设置稍短一些
使用布隆过滤器:将所有可能存在的数据哈希到一个足够大的 bitmap 中,一个一定不存在的数据会被这个 bitmap 拦截掉,从而避免了对DB的查询
在我们的项目中会将缓存放到数据库前面,查询的时候先查缓存,缓存有了就不用再去查数据库了,这样可以大大减轻数据库的访问压力
缓存击穿指的是对于一个设置了过期时间的key,在其缓存失效的瞬间,有大量的请求访问这个它,这些请求在缓存找不到就会直接到数据,导致数据库被压垮
常用的解决方案有两个:
使用互斥锁:当缓存失效时,不立即去数据库查询,而是先去获取一把全局锁,那个线程获取到了,就去数据库查询,获取不到的就等待重试查询缓存
修改设置key有效期的逻辑,大体如下:
在设置key的时候,不给它设置过期时间,而是单独设置一个过期时间字段一块存入缓存中
当查询的时候,从redis取出数据后判断时间是否过期,如果过期则开通另外一个线程进行数据同步,当前线程正常返回数据
两种方案对比:
解决方案 | 优点 | 缺点 |
---|---|---|
互斥锁 | 没有额外的内存消耗 ,保证一致性 | 线程需要等待,性能受影响 |
逻辑过期 | 线程无需等待,性能较好 | 不保证一致性,有额外内存消耗 |
在我们的项目中会将缓存放到数据库前面,查询的时候先查缓存,缓存有了就不用再去查数据库了,这样可以大大减轻数据库的访问压力
缓存雪崩指的是大量的key在某一时刻同时失效,这样大量的请求全部转发到DB,DB 瞬时压力过重雪崩
解决方案也很简单,就是在设置key的过期时间的时候,尽量加一些随机值,这样缓存过期时间的重复率就会降低
Redis中本身是没有事务的概念的,但是他有几个命令组合起来能实现类似于事务的效果。也就是说,Redis事务的本质是一组命令的集合。
这里用到的命令主要有5个,分别是:
总结说:Redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。Reids中,单条命令式原子性执行的,但事务不保证原子性,且没有回滚。