Redis面试题及分布式集群

Reference: http://blog.youkuaiyun.com/yajlv/article/details/73467865

 

1. 使用Redis有哪些好处?

(1) 速度快,因为数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1) 
(2) 支持丰富数据类型,支持string,list,set,sorted set,hash 
(3) 支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,要么全部不执行 
(4) 丰富的特性:可用于缓存,消息,按key设置过期时间,过期后将会自动删除

2. redis相比memcached有哪些优势?

(1) memcached所有的值均是简单的字符串,redis作为其替代者,支持更为丰富的数据类型 
(2) redis的速度比memcached快很多 
(3) redis可以持久化其数据

3. redis常见性能问题和解决方案:

(1) Master最好不要做任何持久化工作,如RDB内存快照和AOF日志文件 
(2) 如果数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次 
(3) 为了主从复制的速度和连接的稳定性,Master和Slave最好在同一个局域网内 
(4) 尽量避免在压力很大的主库上增加从库 
(5) 主从复制不要用图状结构,用单向链表结构更为稳定,即:Master <- Slave1 <- Slave2 <- Slave3… 
这样的结构方便解决单点故障问题,实现Slave对Master的替换。如果Master挂了,可以立刻启用Slave1做Master,其他不变。

4. MySQL里有2000w数据,redis中只存20w的数据,如何保证redis中的数据都是热点数据

相关知识:redis 内存数据集大小上升到一定大小的时候,就会施行数据淘汰策略。redis 提供 6种数据淘汰策略:

voltile-lru:从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰

volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰

volatile-random:从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰

allkeys-lru:从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰

allkeys-random:从数据集(server.db[i].dict)中任意选择数据淘汰

no-enviction(驱逐):禁止驱逐数据

5. Memcache与Redis的区别都有哪些?

1)、存储方式

Memecache把数据全部存在内存之中,断电后会挂掉,数据不能超过内存大小。

Redis有部份存在硬盘上,这样能保证数据的持久性。

2)、数据支持类型

Memcache对数据类型支持相对简单。

Redis有复杂的数据类型。

3)、使用底层模型不同

它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。

Redis直接自己构建了VM 机制 ,因为一般的系统调用系统函数的话,会浪费一定的时间去移动和请求。

4),value大小

redis最大可以达到1GB,而memcache只有1MB

6. Redis 常见的性能问题都有哪些?如何解决?

1).Master写内存快照,save命令调度rdbSave函数,会阻塞主线程的工作,当快照比较大时对性能影响是非常大的,会间断性暂停服务,所以Master最好不要写内存快照。

2).Master AOF持久化,如果不重写AOF文件,这个持久化方式对性能的影响是最小的,但是AOF文件会不断增大,AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作,包括内存快照和AOF日志文件,特别是不要启用内存快照做持久化,如果数据比较关键,某个Slave开启AOF备份数据,策略为每秒同步一次。

3).Master调用BGREWRITEAOF重写AOF文件,AOF在重写的时候会占大量的CPU和内存资源,导致服务load过高,出现短暂服务暂停现象。

4). Redis主从复制的性能问题,为了主从复制的速度和连接的稳定性,Slave和Master最好在同一个局域网内

7, redis 最适合的场景

Redis最适合所有数据in-momory的场景,虽然Redis也提供持久化功能,但实际更多的是一个disk-backed的功能,跟传统意义上的持久化有比较大的差别,那么可能大家就会有疑问,似乎Redis更像一个加强版的Memcached,那么何时使用Memcached,何时使用Redis呢? 
如果简单地比较Redis与Memcached的区别,大多数都会得到以下观点: 
1 、Redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,zset,hash等数据结构的存储。 
2 、Redis支持数据的备份,即master-slave模式的数据备份。 
3 、Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用。 
(1)、会话缓存(Session Cache)

最常用的一种使用Redis的情景是会话缓存(session cache)。用Redis缓存会话比其他存储(如Memcached)的优势在于:Redis提供持久化。当维护一个不是严格要求一致性的缓存时,如果用户的购物车信息全部丢失,大部分人都会不高兴的,现在,他们还会这样吗?

幸运的是,随着 Redis 这些年的改进,很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。

(2)、全页缓存(FPC)

除基本的会话token之外,Redis还提供很简便的FPC平台。回到一致性问题,即使重启了Redis实例,因为有磁盘的持久化,用户也不会看到页面加载速度的下降,这是一个极大改进,类似PHP本地FPC。

再次以Magento为例,Magento提供一个插件来使用Redis作为全页缓存后端。

此外,对WordPress的用户来说,Pantheon有一个非常好的插件 wp-redis,这个插件能帮助你以最快速度加载你曾浏览过的页面。

(3)、队列

Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作,这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作,就类似于本地程序语言(如Python)对 list 的 push/pop 操作。

如果你快速的在Google中搜索“Redis queues”,你马上就能找到大量的开源项目,这些项目的目的就是利用Redis创建非常好的后端工具,以满足各种队列需求。例如,Celery有一个后台就是使用Redis作为broker,你可以从这里去查看。

(4),排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。集合(Set)和有序集合(Sorted Set)也使得我们在执行这些操作的时候变的非常简单,Redis只是正好提供了这两种数据结构。所以,我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”,我们只需要像下面一样执行即可:

当然,这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数,你需要这样执行:

ZRANGE user_scores 0 10 WITHSCORES

Agora Games就是一个很好的例子,用Ruby实现的,它的排行榜就是使用Redis来存储数据的,你可以在这里看到。

(5)、发布/订阅

最后(但肯定不是最不重要的)是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用,还可作为基于发布/订阅的脚本触发器,甚至用Redis的发布/订阅功能来建立聊天系统!(不,这是真的,你可以去核实)。

Redis提供的所有特性中,我感觉这个是喜欢的人最少的一个,虽然它为用户提供如果此多功能。

高可用分布式集群

一,高可用

高可用(High Availability),是当一台服务器停止服务后,对于业务及用户毫无影响。 停止服务的原因可能由于网卡、路由器、机房、CPU负载过高、内存溢出、自然灾害等不可预期的原因导致,在很多时候也称单点问题。

(1)解决单点问题主要有2种方式:

主备方式 
这种通常是一台主机、一台或多台备机,在正常情况下主机对外提供服务,并把数据同步到备机,当主机宕机后,备机立刻开始服务。 
Redis HA中使用比较多的是keepalived,它使主机备机对外提供同一个虚拟IP,客户端通过虚拟IP进行数据操作,正常期间主机一直对外提供服务,宕机后VIP自动漂移到备机上。

优点是对客户端毫无影响,仍然通过VIP操作。 
缺点也很明显,在绝大多数时间内备机是一直没使用,被浪费着的。

主从方式 
这种采取一主多从的办法,主从之间进行数据同步。 当Master宕机后,通过选举算法(Paxos、Raft)从slave中选举出新Master继续对外提供服务,主机恢复后以slave的身份重新加入。 
主从另一个目的是进行读写分离,这是当单机读写压力过高的一种通用型解决方案。 其主机的角色只提供写操作或少量的读,把多余读请求通过负载均衡算法分流到单个或多个slave服务器上。

缺点是主机宕机后,Slave虽然被选举成新Master了,但对外提供的IP服务地址却发生变化了,意味着会影响到客户端。 解决这种情况需要一些额外的工作,在当主机地址发生变化后及时通知到客户端,客户端收到新地址后,使用新地址继续发送新请求。

(2)数据同步 
无论是主备还是主从都牵扯到数据同步的问题,这也分2种情况:

同步方式:当主机收到客户端写操作后,以同步方式把数据同步到从机上,当从机也成功写入后,主机才返回给客户端成功,也称数据强一致性。 很显然这种方式性能会降低不少,当从机很多时,可以不用每台都同步,主机同步某一台从机后,从机再把数据分发同步到其他从机上,这样提高主机性能分担同步压力。 在redis中是支持这杨配置的,一台master,一台slave,同时这台salve又作为其他slave的master。

异步方式:主机接收到写操作后,直接返回成功,然后在后台用异步方式把数据同步到从机上。 这种同步性能比较好,但无法保证数据的完整性,比如在异步同步过程中主机突然宕机了,也称这种方式为数据弱一致性。

Redis主从同步采用的是异步方式,因此会有少量丢数据的危险。还有种弱一致性的特例叫最终一致性,这块详细内容可参见CAP原理及一致性模型。

(3)方案选择 
keepalived方案配置简单、人力成本小,在数据量少、压力小的情况下推荐使用。 如果数据量比较大,不希望过多浪费机器,还希望在宕机后,做一些自定义的措施,比如报警、记日志、数据迁移等操作,推荐使用主从方式,因为和主从搭配的一般还有个管理监控中心。

宕机通知这块,可以集成到客户端组件上,也可单独抽离出来。 Redis官方Sentinel支持故障自动转移、通知等,详情见低成本高可用方案设计(四)。

逻辑图: 
这里写图片描述

二,分布式

分布式(distributed), 是当业务量、数据量增加时,可以通过任意增加减少服务器数量来解决问题。

集群时代 
至少部署两台Redis服务器构成一个小的集群,主要有2个目的:

高可用性:在主机挂掉后,自动故障转移,使前端服务对用户无影响。 
读写分离:将主机读压力分流到从机上。 
可在客户端组件上实现负载均衡,根据不同服务器的运行情况,分担不同比例的读请求压力。

逻辑图: 
这里写图片描述

三,分布式集群时代

当缓存数据量不断增加时,单机内存不够使用,需要把数据切分不同部分,分布到多台服务器上。 
可在客户端对数据进行分片,数据分片算法详见C#一致性Hash详解、C#之虚拟桶分片。

逻辑图: 
这里写图片描述

大规模分布式集群时代 
当数据量持续增加时,应用可根据不同场景下的业务申请对应的分布式集群。 这块最关键的是缓存治理这块,其中最重要的部分是加入了代理服务。 应用通过代理访问真实的Redis服务器进行读写,这样做的好处是:

避免越来越多的客户端直接访问Redis服务器难以管理,而造成风险。 
在代理这一层可以做对应的安全措施,比如限流、授权、分片。 
避免客户端越来越多的逻辑代码,不但臃肿升级还比较麻烦。 
代理这层无状态的,可任意扩展节点,对于客户端来说,访问代理跟访问单机Redis一样。 
目前楼主公司使用的是客户端组件和代理两种方案并存,因为通过代理会影响一定的性能。 代理这块对应的方案实现有Twitter的Twemproxy和豌豆荚的codis。

逻辑图: 
这里写图片描述

四,总结

分布式缓存再向后是云服务缓存,对使用端完全屏蔽细节,各应用自行申请大小、流量方案即可,如淘宝OCS云服务缓存。 
分布式缓存对应需要的实现组件有:

一个缓存监控、迁移、管理中心。 
一个自定义的客户端组件,上图中的SmartClient。 
一个无状态的代理服务。 
N台服务器。

 

转自:http://dy.163.com/v2/article/detail/DHKAHKBG0516W1GE.html

### Redis 集群分布式缓存锁相关面试题 以下是关于 Redis 集群分布式缓存锁的常见面试问题,涵盖理论知识、实际应用以及潜在问题解决方法。 --- #### 1. Redis 集群的工作原理是什么? Redis 集群采用无中心结构,每个节点保存数据和整个集群状态,每个节点都与其他所有节点连接。集群预分好 16384 个槽位,当需要在 Redis 集群中放置一个 key-value 对时,根据 key 的哈希算法与槽位取模,然后确定放置在哪个槽位[^2]。 --- #### 2. Redis 集群在网络分区时如何保证可用性? 根据 CAP 理论,Redis 集群更倾向于 AP(Available and Partition-tolerant)模型。这意味着在网络分割的情况下,Redis 集群始终能够响应请求(尽管可能不保证最终一致性)。分区容忍性确保 Redis 在节点之间的网络分区时仍能保持运行并处理数据的读写请求[^1]。 --- #### 3. Redis 分布式锁的基本实现方式有哪些? Redis 分布式锁可以通过 `SETNX` 命令实现。该命令尝试设置一个键值对,如果键不存在则成功返回 1,否则返回 0。业务代码执行完成后通过 `DEL` 命令释放锁。此外,Redisson 是一种基于 Redis 实现的 Java 驻内存数据网格,提供了多种分布式锁的实现,包括可重入锁[^4]。 --- #### 4. 分布式锁可能存在哪些问题?如何解决? 分布式锁可能存在的问题及解决方案如下: - **超时问题**:业务代码执行时间超过锁时间可能导致锁提前释放。解决方案是使用 WatchDog 机制动态延长锁的有效期。 - **主从一致性问题**:主机将数据异步同步给从机时,若主机宕机可能导致死锁。解决方案是使用 Redisson 等工具,提供更可靠的锁实现。 - **不可重入问题**:获得锁的线程无法再次进入相同的锁代码块。解决方案是使用可重入锁,如 Redisson 提供的实现[^4]。 --- #### 5. 如何避免缓存穿透、击穿和雪崩? - **缓存穿透**:查询的数据在数据库和缓存中均不存在,导致大量请求直接访问数据库。解决方案包括在缓存中存储空对象或使用布隆过滤器[^3]。 - **缓存击穿**:热点数据过期瞬间,大量请求同时访问数据库。解决方案是为热点数据设置永不过期或加互斥锁。 - **缓存雪崩**:大量数据在同一时刻过期,导致数据库压力过大。解决方案包括上线前预热数据、分散过期时间和使用集群[^3]。 --- #### 6. Redis 持久化的方式有哪些?各自的特点是什么? Redis 持久化有以下两种方式: - **RDB(Redis Database Backup)**:快照方式,在指定的时间间隔内将内存中的数据集快照写入磁盘。特点是性能高,但可能会丢失最后一次快照后的数据。 - **AOF(Append Only File)**:记录服务器执行的所有写操作命令,重启时重新执行这些命令恢复数据。特点是数据完整性更高,但文件较大且恢复速度较慢。 --- #### 7. Redis 支持的数据类型有哪些?它们的应用场景是什么? Redis 支持以下数据类型及其应用场景: - **String**:用于存储简单的键值对,支持递增递减操作。 - **Hash**:适用于存储对象属性,如用户信息。 - **List**:适用于消息队列、最新 N 条数据等场景。 - **Set**:适用于去重、好友推荐等场景。 - **ZSet(Sorted Set)**:适用于排行榜、优先级队列等场景。 --- #### 8. Redis 单线程模型为什么性能如此高效? Redis 的单线程模型基于事件驱动和 I/O 多路复用技术,充分利用了内存操作的优势。CPU 不是 Redis 的瓶颈,瓶颈最有可能是机器内存大小和网络带宽。因此,单线程模型不仅易于实现,还能避免多线程带来的上下文切换开销。 --- #### 9. Redis 集群模式下如何进行数据分片? Redis 集群模式下通过哈希槽机制进行数据分片。集群预分配 16384 个槽位,每个 key 根据哈希算法映射到某个槽位,槽位再分配到具体的节点上。官方推荐使用三主三从的架构以提高容错能力。 --- #### 10. Redis 分布式锁的优化方案有哪些? Redis 分布式锁的优化方案包括: - 使用 Redisson 提供的高级锁功能,如可重入锁、公平锁等。 - 引入 WatchDog 机制动态延长锁的有效期,避免因业务执行时间过长而导致锁提前释放。 - 设置合理的锁超时时间,防止死锁发生[^4]。 --- ```python # 示例代码:使用 Redis 实现分布式锁 import redis client = redis.StrictRedis(host='localhost', port=6379, db=0) def acquire_lock(lock_name, acquire_timeout=10): identifier = str(uuid.uuid4()) end = time.time() + acquire_timeout while time.time() < end: if client.setnx(lock_name, identifier): return identifier time.sleep(0.001) return False def release_lock(lock_name, identifier): with client.pipeline() as pipe: while True: try: pipe.watch(lock_name) if pipe.get(lock_name) == identifier: pipe.multi() pipe.delete(lock_name) pipe.execute() return True pipe.unwatch() break except redis.WatchError: pass return False ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值