redis常见问题

什么是redis？

redis是一个基于内存的高性能key-value数据库，全称Remote Dictionary Server。

redis和memcached的区别？

1）持久化

memcached把数据全部存在内存中，断电后会挂掉，数据不能超过内存大小

redis支持持久化，持久化的数据存在硬盘上

2）支持的数据类型

memchached支持的数据类型相对简单，redis支持string、list、set、zset、hash

3）value大小

redis单个value最大可以达到1G，而memcached只有1MB

4）底层模型不同

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

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

redis为什么快？

基于内存，避免了磁盘I/O的瓶颈。

单进程单线程，减少了线程上下文切换的开销。

利用队列技术将并行访问变为串行访问，消除了传统数据库并发访问控制锁的开销。

redis全程使用hash结构，读取速度快，还有一些

Redis内存数据集大小上升到一定大小的时候，就会实行数据淘汰策略（回收策略）。redis提供6种数据策略：

LRU最近最久未使用

 

volatile-lru:从已设置过期时间的数据集（sever.db[I].expires）中挑选最近最少使用的数据淘汰

volatile-ttl:从已设置过期时间的数据集（sever.db[I].expires）中挑选将要过期的数据淘汰

volatile-random:从已设置过期时间的数据集（sever.db[I].expires）中任意选择数据淘汰

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

allkeys-random:从数据集（server.db[I].dict）中任意选择数据淘汰

no-enviction:禁止驱逐数据

 

 

AOF vs RDB

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，现将数据集写入临时文件，写入成功后，在替换之前的文件，用二进制压缩存储

 

AOF持久化一日之的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

 

RDB存在哪些优势

1>灵活设置备份频率和周期。你可能打算每个小时归档一次最近24小时的数据，同事还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复

 

2>对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松地讲一个单独的文件压缩后再转移到其他存储介质上

 

3>性能最大化。对于redis的服务进程而言，在开始持久化时，他唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化工作，这样就可以极大地避免服务进程执行IO操作了。

 

4>相对于AOF机制，如果数据集很大，RDB的启动效率会更高

 

RDB的缺点

1>如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定是持久化之前出现宕机现象，此前没有来得及写入磁盘的数剧都将丢失。

 

2>由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1s

 

AOF的优势

1>该机制可以代码更高的数据安全性，即数据持久性。redis中提供了3种同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是一步完成的，其效率也是非常高的，所查的是一旦系统出现宕机现象，那么这一秒之内修改的数据将会丢失，而没修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上市最低的。

 

2>由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中及时出现当即现象，也不会破坏文件中已经存在的内容。然后如果我们本次操作知识写入了一般数据就出现了系统崩溃问题，不用担心，在redis下一次启动之前，我们可以通过redis-check-aof工具来帮我们解决数据一致性的问题。

 

3>如果日志过大，redis可以自动启用rewrite机制。即redis以append模式不断地将修改的数据写入到老的磁盘文件中，同时，redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好地保证数据安全性

 

4>AOF包含一个格式清晰，易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

 

AOF不足

1>对于形同数量的数据集而言，AOF文件通常要大于RDB文件。RDB在恢复大数据集时的速度比AOF的恢复速度要快。

2>根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高

 

 

 

Redis最适合的场景

1>会话缓存 session cache

 

2>全页缓存(FPC)

 

3>队列

 

4>排行榜/计数器（zset/set）,获取排行前10的用户

 

ZRANGE user_scores 0 10 WITHSCORES

 

5>发布、订阅

 

Redis常见的性能问题

1>master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件。

 

假如redis里面有1亿个key，其中有10w个key是以某个固定的一致的前缀开头的，如何将他们全部找出来？

使用keys指令可以扫除指定模式的key列表，如果是线上redis，因为redis是单线程的。keys指令会导致线程组赛一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复，这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次驱虫就可以了，但是整体所花费的时间会比直接使用keys指令长。

 

Redis过期键的删除策略

Redis有三种不同的删除策略

1>立即删除，在设置键的过期时间时，创建一个回调事件，当过期时间达到时，有时间处理器自动执行键的删除操作

2>惰性删除，键过期了就过期了，不管。从此从dict字典中按key取值时，先检查此key是否已经过期，如果过期了就删除它，并返回nil，如果没过期，就返回键值。

3>定时删除，每间隔一段时间，对expires字典进行检查，删除里面的过期键。

 

可以看到，第二种为被动删除，第一种和第三种为主动删除，且第一种实时性更高。

 

立即删除

立即删除能保证内存中数据的最大新鲜度。因为他保证过期键值会在过期后马上被删除，其所占用的内存也会随之释放，但是立即删除对cpu是嘴不友好的。因为删除操作会占用cpu的时间，如果刚好碰上了cpu很忙的时候，比如正在做交集或者排序等计算的时候，就会给cpu造成额外的压力

 

而且目前redis时间处理器随时间的处理方式-无序链表，超找一个key的时间复杂度为O(n)，所以并不适合用来处理大量的时间事件

 

 

惰性删除

惰性删除是指，某个键值过期后，此键值不会马上被删除，而是等到下次被使用时候，才会被检查到过期，此时才能得到删除，所以惰性删除的缺点很明显：浪费内存。dict字典和expires字段都需要保存这个键值信息

 

定时删除

从上面分析来看，立即删除会短时间内占用大量cpu，惰性删除会在一段时间内浪费内存，所以定是删除时一个折中的办法。

定是删除时：每个一段时间执行一次删除操作，并通过限制删除操作执行的时长和频率，来减少操作删除对cpou的影响。另一方面定是删除也有效的减少了因惰性删除到来的内存浪费

 

Redis使用的策略

Redis使用的过期键值策略是：惰性删除加上定时删除，两者配合使用

 

Redis设置过期时间

expire 秒

pexpire 毫秒

expireat 将过期时间设为timestamp所指定的秒数时间戳

pexpireat 将过期时间设为timestamp所指定的毫秒数时间戳

 

保存过期时间

在数据库结构中redisDb中的expires字典中保存了数据库中所有键的过期时间，我们称expires这个字典为过期字典

 

Dict字典中保存着数据库所有的键值对

 

Redis分布式锁

setnx 只有键key不存在的情况下，将键key的值设为value。若键key已经存在，则setnx命令不做任何操作

首先，锁要要加上过期时间，避免生成锁却未删除的情况

其次，请求在更新缓存的时间可能很长，超过锁的过期时间，此时，锁值是随机值，可以避免删除其他请求创建的锁。

//php单机锁

$ok = $redis->set($key,$random,array(‘nx’,’ex’=>$ttl));



if($ok){

$cache->update();

if($redis->get($key) == $random){

$redis->del($key);

}

}

Redis常见性能问题和解决方案

1>master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件

2>如果数据比较重要，某个slave开启AOF备份数据，策略设置为每秒同步一次

3>为了主从复制的速度和连接的稳定性，master和slave最好在一个局域网内

4>尽量避免在压力很大的主库上增加从库

5>主从复制不要用图状结构，用单向链表结构更加稳定，即master<-slave1<-slave2<-slave3…

这样的结构域方便解决单点故障，实现slave对master的替换。如果master挂了，可以立即启用slave1作为master，其他不变