系统架构面试题(8)Redis集群

系统架构面试题(8)Redis集群

1 谈谈Redis的使用场景和实践策略?

Redis是个KV内存数据库,支持多种数据结构、简单消息队列、磁盘持久化,特点是高性能、使用简单、稳定可靠。常见使用场景如下:
(1) 数据缓存:客户端访问服务器的时候,先检查redis是否有数据,Redis有数据直接反馈给客户端;如果没有数据再请求数据库,查询数据后缓存到Redis,下次就可以直接读Redis。
(2)分布式锁:微服务项目服务部署到不同的服务器上,单体架构的同步锁没办法锁住服务,利用Redis实现分布式锁,常用组件为Redisson。
(3)数据共享:将包含用户信息的令牌存储在Redis中,用户每次访问时从Redis中查询令牌,实现资源的共享,即分布式Session。

常用实践策略:
(1)节省内存:控制 key 的长度;选择合适的数据类型;务必设置过期时间;数据压缩后再写入
(2)高性能:开启 lazy-free 机制;不使用复杂度过高的命令;关注 DEL 时间复杂度;批量命令代替单个命令;避免集中过期 key;使用读写分离 + 分片集群; 不开启 AOF 或 AOF 配置为每秒刷盘
(3)可靠性:按业务线部署实例;部署主从集群;合理配置主从复制参数;部署哨兵集群,实现故障自动切换;
(4)运维:禁止使用 KEYS/FLUSHALL/FLUSHDB 命令; 扫描线上实例时,设置休眠时间;慎用 MONITOR 命令;从库必须设置为 slave-read-only; 合理配置 timeout 和 tcp-keepalive 参数;
(5)安全:不要把 Redis 部署在公网可访问的服务器上;部署时不使用默认端口 6379;以普通用户启动 Redis 进程,禁止 root 用户启动;限制 Redis 配置文件的目录访问权限;推荐开启密码认证;禁用/重命名危险命令(KEYS/FLUSHALL/FLUSHDB/CONFIG/EVAL)
(6)监控:做好机器 CPU、内存、带宽、磁盘监控,资源不足时及时报警,任意资源不足都会影响 Redis 性能;设置合理的 slowlog 阈值,并对其进行监控,slowlog 过多及时报警;监控组件采集Redis INFO 信息时,采用长连接,避免频繁的短连接;做好实例运行时监控,重点关注 expired_keys、evicted_keys、latest_fork_usec 指标,这些指标短时突增可能会有阻塞风险

2 说说Redis的几种基础数据结构?

(1)String字符串:String类型是二进制安全的,可以包含任何数据如数字、字符串、图片或者序列化的对象。
(2)List列表:双端链表实现List。使用List数据类型可以实现消息队列,利用List的 PUSH 操作,将任务存放在List中,然后工作线程再用 POP 操作将任务取出进行执行。
(3)Set集合:Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的,不能出现重复的数据。集合是通过哈希表实现的,所以添加,删除,查找的复杂度都是 O(1)。
(4)Hash散列:Redis hash 是一个 string 类型的 field(字段) 和 value(值) 的映射表,hash 特别适合用于存储对象。
(5)Zset有序集合: 有序集合不允许重复的成员。每个元素都会关联一个 double 类型的分数,通过分数来为集合成员排序。有序集合的成员是唯一的,但分数 score 却可以重复。

3 说说Redis如何持久化数据?

Redis 的数据都是存储在内存中,为了避免永久丢失数据,需要定期将 Redis 中的数据以某种形式从内存保存到硬盘。当下次 Redis 重启时,再利用持久化文件实现数据恢复。Redis 的持久化机制有两种:

  • RDB(Redis Data Base) 内存快照

RDB持久化是Redis默认的持久化方式,即通过创建快照(压缩的二进制文件)的方式进行持久化,保存某个时间点的全量数据。每次都是从 Redis 中生成一个快照进行数据的全量备份,包括手动触发与自动触发两种方式。

优点:存储紧凑,节省内存空间;恢复速度非常快;适合全量备份、全量复制的场景,经常用于灾难恢复,对数据的完整性和一致性要求相对较低的场合。

缺点:容易丢失数据,容易丢失两次快照之间服务器中变化的数据;RDB 通过 fork 子进程对内存快照进行全量备份,是一个重量级操作,频繁执行成本高。

  • AOF(Append Only File) 增量日志

AOF(Append-Only-File)持久化即记录所有变更数据库状态的指令,以append的形式追加保存到AOF文件中。在服务器下次启动时,就可以通过载入和执行AOF文件中保存的命令,来还原服务器关闭前的数据库状态。AOF 能够解决数据持久化实时性问题,是 Redis 持久化机制中主流的方案。

优点:数据的备份更加完整,丢失数据的概率更低,适合对数据完整性要求高的场景。AOF 可操作性更强,日志文件可读,可通过操作日志文件进行修复。

缺点:AOF 日志记录在长期运行中逐渐庞大,恢复起来非常耗时,需要定期对 AOF 日志进行瘦身处理;恢复备份速度比较慢,同步写操作频繁会带来性能压力。

4 如何解决Redis缓存单机热点问题?

(1)预估热点key:预估哪些是热key,比如某商品在做秒杀,那商品编号就是热key。但是并非所有业务都能预估出key的冷热。
(2)程序统计:在客户端埋点收集,缺点是有代码入侵。
(3)Redis 自带功能:Redis 4.0以上开启 Redis 自带系统监控,比如monitor命令。

解决热点问题的方案:
(1)二级缓存:把热key加载到系统的JVM中,比如Ehcache、HashMap等
(2)Key 添加随机数:把热点 Key 分布到不同机器,给 Key 加一个随机后缀。

5 Redis的集群方案有哪些?

  • 主从方案

一个master可以有多个salve节点,salve节点可以有slave节点。主从结构具有读写分离,提高效率、数据备份,提供多个副本等优点。最大的不足就是主从模式不具备自动容错和恢复功能,主节点故障,集群则无法进行工作,可用性比较低,从节点升主节点需要人工手动干预。

  • 哨兵模式

也是主从模式,在主节点宕机导致不可写的情况下增加竞选机制,从所有的从节点竞选出新的主节点。通过发送命令返回监控服务器的运行状态,处理监控主服务器、从服务器外,哨兵之间也相互监控。当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换master,有问题的旧主也会变为新主的从。

  • Redis Cluster

redis在3.0上加入了 Cluster 集群模式,实现了 Redis 的分布式存储,也就是说每台 Redis 节点上存储不同的数据。cluster模式为了解决单机Redis容量有限的问题,将数据按一定的规则分配到多台机器,内存/QPS不受限于单机,可受益于分布式集群高扩展性。

Redis Cluster是一种服务器Sharding技术(分片和路由都是在服务端实现),采用多主多从,每一个分区都是由一个Redis主机和多个从机组成,片区和片区之间是相互平行的。Redis Cluster集群采用了P2P的模式,完全去中心化。

redis cluster主要是针对海量数据+高并发+高可用的场景,海量数据,如果你的数据量很大,那么建议就用redis cluster,数据量不是很大时,使用sentinel就够了。redis cluster的性能和高可用性均优于哨兵模式。

Redis Cluster采用虚拟哈希槽分区而非一致性hash算法,预先分配一些卡槽,所有的键根据哈希函数映射到这些槽内,每一个分区内的master节点负责维护一部分槽以及槽所映射的键值数据。

  • 其他实现

Redis在3.0版本前只支持单实例模式,虽然Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能,但3.0版本等到2015年才发布正式版。各大企业等不急了,在3.0版本还没发布前为了解决Redis的存储瓶颈,纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片(sharding)存储在多个Redis实例中,每一片就是一个Redis实例。

(1)客户端分片

客户端分片是把分片的逻辑放在Redis客户端实现,(比如:jedis已支持Redis Sharding功能,即ShardedJedis),通过Redis客户端预先定义好的路由规则(使用一致性哈希),把对Key的访问转发到不同的Redis实例中,查询数据时把返回结果汇集。

客户端sharding技术使用hash一致性算法分片的好处是所有的逻辑都是可控的,不依赖于第三方分布式中间件。服务端的Redis实例彼此独立,相互无关联,每个Redis实例像单服务器一样运行,非常容易线性扩展,系统的灵活性很强。开发人员清楚怎么实现分片、路由的规则。

(2)代理分片

Redis代理分片用得最多的就是Twemproxy,其基本原理是:通过中间件的形式,Redis客户端把请求发送到Twemproxy,Twemproxy根据路由规则发送到正确的Redis实例,最后Twemproxy把结果汇集返回给客户端。Twemproxy通过引入一个代理层,将多个Redis实例进行统一管理,使Redis客户端只需要在Twemproxy上进行操作,而不需要关心后面有多少个Redis实例,从而实现了Redis集群。

客户端像连接Redis实例一样连接Twemproxy,不需要改任何的代码逻辑,支持无效Redis实例的自动删除。Twemproxy与Redis实例保持连接,减少了客户端与Redis实例的连接数。由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器,这个过程中会产生性能损失。

Twemproxy最大的痛点是无法平滑地扩容/缩容。对于运维人员来说,当业务需要增加Redis实例时工作量非常大。Twemproxy作为最被广泛使用、最久经考验、稳定性最高的Redis代理,在业界被广泛使用。

参考(摘抄的文字版权属于原作者)
https://www.cnblogs.com/xingxia/p/redis_compare_memcache.html
https://blog.csdn.net/jjclove/article/details/124922628
https://www.cnblogs.com/shenStudy/p/16859463.html
https://blog.csdn.net/An1090239782/article/details/127203348
https://www.cnblogs.com/dragonsuc/p/6885495.html
https://zhuanlan.zhihu.com/p/518594810

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注