|
23 | 23 |
|
24 | 24 | 这样的结构方便解决单点故障问题,实现Slave对Master的替换。如果Master挂了,可以立刻启用Slave1做Master,其他不变。 |
25 | 25 |
|
26 | | -## mySQL里有2000w数据,redis中只存20w的数据,如何保证redis中的数据都是热点数据 |
27 | | - |
28 | | -相关知识:redis 内存数据集大小上升到一定大小的时候,就会施行数据淘汰策略。redis 提供 6种数据淘汰策略: |
29 | | - |
30 | | -- volatile-lru:从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰 |
31 | | -- volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰 |
32 | | -- volatile-random:从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰 |
33 | | -- allkeys-lru:从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰 |
34 | | -- allkeys-random:从数据集(server.db[i].dict)中任意选择数据淘汰 |
35 | | -- no-enviction(驱逐):禁止驱逐数据 |
36 | | - |
37 | | -## Redis 常见的性能问题都有哪些?如何解决? |
38 | | - |
39 | | -1. Master写内存快照,save命令调度rdbSave函数,会阻塞主线程的工作,当快照比较大时对性能影响是非常大的,会间断性暂停服务,所以Master最好不要写内存快照。 |
40 | | -1. Master AOF持久化,如果不重写AOF文件,这个持久化方式对性能的影响是最小的,但是AOF文件会不断增大,AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作,包括内存快照和AOF日志文件,特别是不要启用内存快照做持久化,如果数据比较关键,某个Slave开启AOF备份数据,策略为每秒同步一次。 |
41 | | -1. Master调用BGREWRITEAOF重写AOF文件,AOF在重写的时候会占大量的CPU和内存资源,导致服务load过高,出现短暂服务暂停现象。 |
42 | | -1. Redis主从复制的性能问题,为了主从复制的速度和连接的稳定性,Slave和Master最好在同一个局域网内 |
43 | | - |
44 | 26 | ## redis 最适合的场景 |
45 | 27 |
|
46 | 28 | Redis最适合所有数据in-momory的场景,虽然Redis也提供持久化功能,但实际更多的是一个disk-backed的功能,跟传统意义上的持久化有比较大的差别,那么可能大家就会有疑问,似乎Redis更像一个加强版的Memcached,那么何时使用Memcached,何时使用Redis呢? |
@@ -105,10 +87,79 @@ redis利用队列技术将并发访问变为串行访问,消除了传统数据 |
105 | 87 | 1. 如果数据呈现幂律分布,也就是一部分数据访问频率高,一部分数据访问频率低,则使用allkeys-lru |
106 | 88 | 1. 如果数据呈现平等分布,也就是所有的数据访问频率都相同,则使用allkeys-random |
107 | 89 |
|
108 | | -## Redis 有哪些类型 |
| 90 | +## mySQL里有2000w数据,redis中只存20w的数据,如何保证redis中的数据都是热点数据 |
| 91 | + |
| 92 | +相关知识:redis 内存数据集大小上升到一定大小的时候,就会施行数据淘汰策略。redis提供6种数据淘汰策略见上面一条 |
| 93 | + |
| 94 | +## 假如Redis里面有1亿个key,其中有10w个key是以某个固定的已知的前缀开头的,如果将它们全部找出来? |
| 95 | + |
| 96 | +使用keys指令可以扫出指定模式的key列表。 |
| 97 | + |
| 98 | +对方接着追问:如果这个redis正在给线上的业务提供服务,那使用keys指令会有什么问题? |
| 99 | + |
| 100 | +这个时候你要回答redis关键的一个特性:redis的单线程的。keys指令会导致线程阻塞一段时间,线上服务会停顿,直到指令执行完毕,服务才能恢复。这个时候可以使用scan指令,scan指令可以无阻塞的提取出指定模式的key列表,但是会有一定的重复概率,在客户端做一次去重就可以了,但是整体所花费的时间会比直接用keys指令长。 |
| 101 | + |
| 102 | +## Redis 常见的性能问题都有哪些?如何解决? |
| 103 | + |
| 104 | +1. Master写内存快照,save命令调度rdbSave函数,会阻塞主线程的工作,当快照比较大时对性能影响是非常大的,会间断性暂停服务,所以Master最好不要写内存快照。 |
| 105 | +2. Master AOF持久化,如果不重写AOF文件,这个持久化方式对性能的影响是最小的,但是AOF文件会不断增大,AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作,包括内存快照和AOF日志文件,特别是不要启用内存快照做持久化,如果数据比较关键,某个Slave开启AOF备份数据,策略为每秒同步一次。 |
| 106 | +3. Master调用BGREWRITEAOF重写AOF文件,AOF在重写的时候会占大量的CPU和内存资源,导致服务load过高,出现短暂服务暂停现象。 |
| 107 | +4. Redis主从复制的性能问题,为了主从复制的速度和连接的稳定性,Slave和Master最好在同一个局域网内 |
| 108 | + |
| 109 | +## Redis有哪些数据结构? |
| 110 | + |
| 111 | +字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。 |
| 112 | + |
| 113 | +如果你是Redis中高级用户,还需要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub。 |
| 114 | + |
| 115 | +如果你说还玩过Redis Module,像BloomFilter,RedisSearch,Redis-ML,面试官得眼睛就开始发亮了。 |
| 116 | + |
| 117 | +## 使用过Redis分布式锁么,它是什么回事? |
| 118 | + |
| 119 | +先拿setnx来争抢锁,抢到之后,再用expire给锁加一个过期时间防止锁忘记了释放。 |
| 120 | + |
| 121 | +这时候对方会告诉你说你回答得不错,然后接着问如果在setnx之后执行expire之前进程意外crash或者要重启维护了,那会怎么样? |
| 122 | + |
| 123 | +这时候你要给予惊讶的反馈:唉,是喔,这个锁就永远得不到释放了。紧接着你需要抓一抓自己得脑袋,故作思考片刻,好像接下来的结果是你主动思考出来的,然后回答:我记得set指令有非常复杂的参数,这个应该是可以同时把setnx和expire合成一条指令来用的!对方这时会显露笑容,心里开始默念:摁,这小子还不错。 |
| 124 | + |
| 125 | +## 使用过Redis做异步队列么,你是怎么用的? |
| 126 | + |
| 127 | +一般使用list结构作为队列,rpush生产消息,lpop消费消息。当lpop没有消息的时候,要适当sleep一会再重试。 |
| 128 | + |
| 129 | +如果对方追问可不可以不用sleep呢?list还有个指令叫blpop,在没有消息的时候,它会阻塞住直到消息到来。 |
| 130 | + |
| 131 | +如果对方追问能不能生产一次消费多次呢?使用pub/sub主题订阅者模式,可以实现1:N的消息队列。 |
| 132 | + |
| 133 | +如果对方追问pub/sub有什么缺点?在消费者下线的情况下,生产的消息会丢失,得使用专业的消息队列如rabbitmq等。 |
| 134 | + |
| 135 | +如果对方追问redis如何实现延时队列?我估计现在你很想把面试官一棒打死如果你手上有一根棒球棍的话,怎么问的这么详细。但是你很克制,然后神态自若的回答道:使用sortedset,拿时间戳作为score,消息内容作为key调用zadd来生产消息,消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。 |
| 136 | + |
| 137 | +到这里,面试官暗地里已经对你竖起了大拇指。但是他不知道的是此刻你却竖起了中指,在椅子背后。 |
| 138 | + |
| 139 | +## 如果有大量的key需要设置同一时间过期,一般需要注意什么? |
| 140 | + |
| 141 | +如果大量的key过期时间设置的过于集中,到过期的那个时间点,redis可能会出现短暂的卡顿现象。一般需要在时间上加一个随机值,使得过期时间分散一些。 |
109 | 142 |
|
110 | 143 | ## Redis 持久化机制 |
111 | 144 |
|
| 145 | +bgsave做镜像全量持久化,aof做增量持久化。因为bgsave会耗费较长时间,不够实时,在停机的时候会导致大量丢失数据,所以需要aof来配合使用。在redis实例重启时,会使用bgsave持久化文件重新构建内存,再使用aof重放近期的操作指令来实现完整恢复重启之前的状态。 |
| 146 | + |
| 147 | +对方追问那如果突然机器掉电会怎样?取决于aof日志sync属性的配置,如果不要求性能,在每条写指令时都sync一下磁盘,就不会丢失数据。但是在高性能的要求下每次都sync是不现实的,一般都使用定时sync,比如1s1次,这个时候最多就会丢失1s的数据。 |
| 148 | + |
| 149 | +对方追问bgsave的原理是什么?你给出两个词汇就可以了,fork和cow。fork是指redis通过创建子进程来进行bgsave操作,cow指的是copy on write,子进程创建后,父子进程共享数据段,父进程继续提供读写服务,写脏的页面数据会逐渐和子进程分离开来。 |
| 150 | + |
| 151 | +## Pipeline有什么好处,为什么要用pipeline? |
| 152 | + |
| 153 | +可以将多次IO往返的时间缩减为一次,前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。 |
| 154 | + |
| 155 | +## Redis的同步机制了解么? |
| 156 | + |
| 157 | +Redis可以使用主从同步,从从同步。第一次同步时,主节点做一次bgsave,并同时将后续修改操作记录到内存buffer,待完成后将rdb文件全量同步到复制节点,复制节点接受完成后将rdb镜像加载到内存。加载完成后,再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。 |
| 158 | + |
112 | 159 | ## Redis 集群方案与实现 |
113 | 160 |
|
| 161 | +Redis Sentinal着眼于高可用,在master宕机时会自动将slave提升为master,继续提供服务。 |
| 162 | + |
| 163 | +Redis Cluster着眼于扩展性,在单个redis内存不足时,使用Cluster进行分片存储。 |
| 164 | + |
114 | 165 | ## Redis 为什么是单线程的 |
0 commit comments