Redis是一个基于Key-Value存储结构的开源内存数据库,也是一种NoSQL数据库。
它支持多种数据类型,包括String、Map、Set、ZSet和List,以满足不同应用场景的需求。
Redis以内存存储和优化的数据结构为基础,提供了快速的读写性能和高效的数据访问。常被用作应用与数据库之间的缓存组件,提升数据IO效率。
此外,Redis支持主从复制、哨兵机制和集群方式,实现高可用性和水平扩展。
要实现Redis的高可用性,可以采取以下几个关键步骤和措施:
- 主从复制:通过设置主从复制,将主节点的数据同步到多个从节点上。主节点负责处理写操作,并将写操作的日志复制给从节点,从节点则负责处理读请求。如果主节点发生故障,可以将一个从节点升级为新的主节点,从而实现故障转移和高可用。
- 哨兵机制:使用Redis 哨兵来监控主节点和从节点的状态。哨兵是一组独立运行的进程,它会监控Redis实例的健康状态,并在主节点出现故障时自动进行故障转移。它还能够监控从节点,并在需要时将其提升为主节点。
- 集群模式:Redis 集群是一种分布式方案,可以将多个Redis节点组成一个逻辑集群,提供数据分片和自动故障恢复。每个节点负责存储和处理部分数据,通过节点间的数据分片和分布式算法保证数据的可用性和负载均衡。当集群中的某个节点出现故障时,集群会自动进行故障转移和恢复。
Redis支持五种主要的数据类型:
- String:String是最常用的数据类型,在Redis中以二进制安全的方式存储字符串值。它可以包含任何类型的数据,比如文本、整数或二进制数据。
- Hash:Hash是一个键值对的集合,其中每个键都与一个值相关联。在Redis中,Hash可以用于存储和操作对象,每个键值对相当于对象的字段和值。
- List:List是一个按照插入顺序排序的字符串元素集合。集合中的元素可以重复,可以从列表的两端进行插入和删除操作,可用于实现队列、栈等数据结构。
- Set:Set是一个无序、唯一的字符串集合,不允许重复的成员。可以对集合执行添加、删除和判断成员是否存在等操作,也支持集合间的交集、并集和差集运算。
- Sorted Set:Sorted Set是一个有序的字符串集合,每个成员都关联着一个分数。集合中的成员根据分数的大小进行排序,可以进行范围查询和按分数排名操作。
除了这些主要的数据类型,Redis还提供了其他一些特殊的数据结构和功能,如HyperLogLog用于基数统计、Geo用于地理位置信息存储、Pub/Sub用于发布与订阅等。
通过这些不同的数据类型,Redis可以灵活地存储和操作各种类型的数据,满足不同应用场景下的需求。
Redis 的操作是原子性的,这是因为 Redis 的每个命令都是以单线程的方式执行的,整个命令的执行过程是不可中断的,要么全部执行成功,要么全部执行失败。
在 Redis 中,每个命令都会被转换成一个或多个底层操作,这些操作会基于数据结构的特定实现来执行。比如,对于字符串类型,获取一个键值对、设置一个键值对等操作都是原子性的。在执行这些底层操作时,Redis 会使用一些技术来保证原子性,主要包括以下两点:
- Redis 使用单线程模型,避免了多线程之间的竞争条件和锁开销,从而保证了操作的原子性。
- Redis 在执行一些复杂的操作时,比如事务、Lua 脚本等,会将多个底层操作打包成一个原子性操作,这些底层操作要么全部执行成功,要么全部执行失败。在事务和 Lua 脚本中,Redis 同时支持回滚操作,即当一些命令执行成功,后面的命令出错时,Redis 可以自动撤销已经执行的命令。
因此,Redis 的操作是原子性的,这得益于 Redis 单线程模型和底层操作的实现方式。这种原子性操作保证了 Redis 能够提供高效和可靠的服务。
Redis有两种持久化机制:RDB和AOF。
- RDB是一种快照持久化的方式,它会将Redis在某个时间点的数据状态以二进制的方式保存到硬盘上的一个文件中。RDB持久化可以通过配置定时或手动触发,也可以设置自动触发的条件。RDB的优点是生成的文件比AOF文件更小,恢复速度也更快,适合用于备份和灾难恢复。
- AOF是一种追加日志持久化方式,它会将Redis执行的写命令追加到一个文件的末尾。当Redis重启时,它会重新执行这些写命令来恢复数据状态。AOF提供了更可靠的持久化方式,因为它可以保证每个写操作都被记录下来,并且不会发生数据丢失的情况。AOF文件可以根据配置进行同步写入硬盘的频率,包括每秒同步、每写入命令同步和禁用同步三种模式。
在使用持久化机制时,可以选择同时使用RDB和AOF,也可以只使用其中一种。同时使用两种方式时,Redis在重启时会先加载AOF文件来恢复数据,如果AOF文件不存在或损坏,则会尝试加载RDB文件。因此,AOF具有更高的优先级。
Redis的常用应用场景主要包括:
- 缓存:作为高性能缓存层,提供快速数据访问。
- 分布式会话管理:实现跨服务器的会话共享。
- 消息队列:用作中间件实现异步通信和任务队列。
- 实时排行榜/计数器:用有序集合实现实时排名和计数功能。
- 地理位置信息存储与查询:支持存储地理位置信息并进行位置查询。
- 实时数据分析:存储实时生成的数据,进行快速统计和分析。
需要注意根据具体场景合理使用,充分考虑内存容量和数据持久化等因素。同时,Redis也可与其他存储系统结合使用构建复杂应用架构。
缓存击穿、缓存穿透和缓存雪崩是与缓存相关的一些常见问题,具体定义如下:
- 缓存击穿:指当一个缓存键(key)对应的数据在缓存中不存在,同时又有大量并发请求访问该缓存键时,这些请求会直接绕过缓存,查询数据库或其他存储系统,导致数据库压力增大。缓存击穿通常在缓存过期后发生。
- 缓存穿透:指当一个查询请求访问一个不存在于缓存中且也不存在于数据库中的数据时,这个请求会无效地继续访问数据库,而不会被缓存。如果黑客故意发送大量非法请求,则缓存层无法起到过滤作用,可能导致数据库负载过大。
- 缓存雪崩:指当缓存集中在某个时间点失效或由于某个原因发生故障,导致大量的请求直接打到后端数据库,造成数据库瞬时压力过大,甚至引起数据库崩溃。在缓存雪崩期间,系统性能急剧下降,无法正常提供服务。
为了应对以上问题,可以采取以下措施:
- 对热点数据采用永不过期策略,避免缓存击穿。
- 在缓存层进行空值缓存,即将查询结果为空的数据也缓存一段时间,避免缓存穿透。
- 设置合理的缓存过期时间,并使用分布式缓存的多节点部署,避免缓存雪崩。
- 引入限流、熔断等机制,控制并发访问量,保护后端系统。
- 对重要数据做冷备份,确保即使缓存失效或故障,仍能从其他系统中恢复数据。
缓存双写不一致是指在使用缓存的架构中,当数据更新时,由于缓存和数据库的写操作没有同步进行,导致数据在缓存和数据库之间出现不一致的情况。
使用redis做一个缓冲操作,让请求先访问到redis,而不是直接访问MySQL等数据库:
读取缓存步骤一般没有什么问题,但是一旦涉及到数据更新:数据库和缓存更新,就容易出现缓存(Redis)和数据库(MySQL)间的数据一致性问题。
不管是先写MySQL数据库,再删除Redis缓存;还是先删除缓存,再写库,都有可能出现数据不一致的情况。
?举一个例子:
如果更新Redis失败,可能仍然不一致
再次查询的时候在将数据添加到缓存中,这种方案能解决1方案的问题,但是在高并发下性能较低,而且仍然会出现数据不一致的问题,比如线程1删除了Redis缓存数据,正在更新Mysql,此时另外一个查询再查询,那么就会把Mysql中老数据又查到Redis中
因为写和读是并发的,没法保证顺序,就会出现缓存和数据库的数据不一致的问题
?
解决方案:
a. 延时双删
先删除Redis缓存数据,再更新Mysql,延迟几百毫秒再删除Redis缓存数据,这样就算在更新Mysql时,有其他线程读了Mysql,把老数据读到了Redis中,那么也会被删除掉,从而把数据保持一致。
b. 队列 + 重试机制
- ? ? 更新数据库数据;
- 继续重试删除操作,直到成功
- 自己消费消息,获得需要删除的key
- 将需要删除的key发送至消息队列
- 缓存因为种种问题删除失败
?对业务线代码造成大量的侵入。
c. 异步更新缓存(基于订阅binlog的同步机制)
?
MySQL中产生了新的写入、更新、删除等操作,就可以把binlog相关的消息推送至Redis,Redis再根据binlog中的记录,对Redis进行更新。
其实这种机制,很类似MySQL的主从备份机制,因为MySQL的主备也是通过binlog来实现的数据一致性。
?