redis面试题

redis和memcached比较？

1、数据操作不同

与Memcached仅支持简单的key-value结构的数据记录不同，Redis支持的数据类型要丰富得多。Memcached基本只支持简单的key-value存储，不支持枚举，不支持持久化和复制等功能。Redis支持服务器端的数据操作相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，支持list、set、sorted set、hash等众多数据结构，还同时提供了持久化和复制等功能。而通常在Memcached里，使用者需要将数据拿到客户端来进行类似的修改再set回去，这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作， Redis会是更好的选择。

2、内存管理机制不同

在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。Redis只会缓存所有的key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以保持超过其机器本身内存大小的数据。

而Memcached默认使用Slab Allocation机制管理内存，其主要思想是按照预先规定的大小，将分配的内存分割成特定长度的块以存储相应长度的key-value数据记录，以完全解决内存碎片问题。

从内存利用率来讲，使用简单的key-value存储的话，Memcached的内存利用率更高。而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。

3、性能不同

由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis也在存储大数据的性能上进行了优化，但是比起Memcached，还是稍有逊色。

4、集群管理不同

Memcached是全内存的数据缓冲系统，Redis虽然支持数据的持久化，但是全内存毕竟才是其高性能的本质。作为基于内存的存储系统来说，机器物理内存的大小就是系统能够容纳的最大数据量。如果需要处理的数据量超过了单台机器的物理内存大小，就需要构建分布式集群来扩展存储能力。

Memcached本身并不支持分布式，因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。相较于Memcached只能采用客户端实现分布式存储，Redis更偏向于在服务器端构建分布式存储。

 

redis中数据库默认是多少个db 及作用？

edis默认有16个db，db0~db15（可以通过配置文件支持更多，无上限）

并且每个数据库的数据是隔离的不能共享

可以随时使用SELECT命令更换数据库：redis> SELECT 1

注意： 多个数据库之间并不是完全隔离的 比如FLUSHALL命令可以清空一个Redis实例中所有数据库中的数据。

python操作redis的模块？

 

如果redis中的某个列表中的数据量非常大，如果实现循环显示每一个值？

# 通过scan_iter分片取，减少内存压力
scan_iter(match=None,count=None)增量式迭代获取redis里匹配的的值
 match，匹配指定key
# count，每次分片最少获取个数
    r = redis.Redis(connection_pool=pool)
    for key in r.scan_iter(match='PREFIX_*',count=100000):
        print(key)

redis如何实现主从复制？以及数据同步机制？

实现主从复制：
'创建6379和6378配置文件'
redis.conf：6379为默认配置文件，作为Master服务配置；
redis_slave.conf：6378为同步配置，作为Slave服务配置；
'配置slaveof同步指令'
在Slave对应的conf配置文件中，添加以下内容：
slaveof 127.0.0.1 6379
数据同步步骤：
(1)Slave服务器连接到Master服务器.
(2)Slave服务器发送同步(SYCN)命令.
(3)Master服务器备份数据库到文件.
(4)Master服务器把备份文件传输给Slave服务器.
(5)Slave服务器把备份文件数据导入到数据库中.

redis中的sentinel的作用？

Redis SentinelSentinel(哨兵)是用于监控redis集群中Master状态的工具，其已经被集成在redis2.4+的版本中。

一、Sentinel作用：
　　1)：Master状态检测
　　2)：如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave
　　3)：Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换
　　二、Sentinel工作方式：
　　1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
　　2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
　　3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
　　4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
　　5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。

6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
　　7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
　　若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
　　主观下线和客观下线
　　主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
　　客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.
　　SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。
　　ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。

如何实现redis集群？

redis主从方案

redis主从模式是最简单的一种集群方案配置起来也比较简单，它的特点主要有：

• 一个master可以拥有多个slave
• 多个slave链接同一个master，也可以链接其它slave
• 主从复制不会阻塞master,在同步数据时，master可以继续处理client请求.
• slave 配置为slave-read-only on需要升级为主节点或者写入配置文件中,而不能在默认slave情况下直接设置master与slave断开后会检测心跳,从新建立连接.
• 可以直接copy DUMP文件从新重启master，在Master为空以后，slave同步数据会抹掉全部数据.

这种简单的主从读写分离方案的缺点也比较多，类似Mysql的主从方案，往Master节点写数据，同时Master节点会异步写入slave节点中。这种方案目前使用的越来越少，不过对于个体开发并且对缓存依赖度不高的系统还是可以使用的，毕竟搭建和维护简单。

 

redis中默认有多少个哈希槽？

Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽。这种结构很容易添加或者删除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。

使用哈希槽的好处就在于可以方便的添加或移除节点。

当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；

当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；

在这一点上，我们以后新增或移除节点的时候不用先停掉所有的 redis 服务。

简述redis的有哪几种持久化策略及比较？

RDB 的优点

RDB 是一个非常紧凑(compact)的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

RDB 非常适用于灾难恢复(disaster recovery)：它只有一个文件，并且内容都非常紧凑，可以(在加密后)将它传送到别的数据中心，或者亚马逊 S3 中。

RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 的缺点

如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点(save point)来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。

每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端; 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF 的优点

使用 AOF 持久化会让 Redis 变得非常耐久(much more durable)：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求)。

AOF 文件是一个只进行追加操作的日志文件(append only log)， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令(比如写入时磁盘已满，写入中途停机，等等)， redis-check-aof 工具也可以轻易地修复这种问题。

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析(parse)也很轻松。 导出(export) AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 的缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间(latency)。

AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 (举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。) 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

列举redis支持的过期策略。

redis 中的默认的过期策略是volatile-lru 。设置方式   
config set maxmemory-policy volatile-lru

maxmemory-policy 六种方式
volatile-lru：只对设置了过期时间的key进行LRU（默认值） 
allkeys-lru ： 删除lru算法的key   
volatile-random：随机删除即将过期key   
allkeys-random：随机删除   
volatile-ttl ： 删除即将过期的   
noeviction ： 永不过期，返回错误 

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）中任意选择数据淘汰

写代码，基于redis的列表实现 先进先出、后进先出队列、优先级队列。

通常使用一个list来实现队列操作，这样有一个小限制，所以的任务统一都是先进先出，如果想优先处理某个任务就不太好处理了，这就需要让队列有优先级的概念，我们就可以优先处理高级别的任务。

实现方式：

（1）单一列表实现

队列正常的操作是 左进右出（lpush,rpop）

为了先处理高优先级任务，在遇到高级别任务时，可以直接插队，直接放入队列头部（rpush），这样，从队列头部（右侧）获取任务时，取到的就是高优先级的任务（rpop）

相当于普通任务按照队列结构，碰到高优先级任务，就按照堆栈结构

优点是实现简单，缺点是高级别任务总是后进先出，适用于简单的队列需求，高优先级任务较少的情况。

（2）多队列实现

使用两个队列，一个普通队列，一个高级队列，针对任务的级别放入不同的队列。

获取任务时也很简单，redis的BRPOP命令可以按顺序从多个队列中取值。

BRPOP会按照给出的 key 顺序查看，并在找到的第一个非空 list 的尾部弹出一个元素。

redis> BRPOP list1 list2 0

list1 做为高优先级任务队列

list2 做为普通任务队列

这样就实现了先处理高优先级任务，当没有高优先级任务时，就去获取普通任务。

（3）使用权值实现

如果优先级比较复杂，比如有10几个甚至更多的优先级别，方法2就不太方便了。

例如有3个级别（1 2 3），用权值来表示

有4个元素需要入队

a级别1，b级别2，c级别3，d级别3

使用 lpush 把他们入队，同时设置权值

redis> lpush mylist a
redis> set mylist_score_a 1

redis> lpush mylist b
redis> set mylist_score_b 2 lpush mylist c
redis> set mylist_score_c 3 lpush mylist d
redis> set mylist_score_d 3

根据权值排序，并取出排名第一的元素

redis> sort mylist by mylist_score_* limit 0 1

结果为：c，正是我们想要的，c 的级别最高，并且是先进入队列的

获取完成后，要移除此元素

redis> lrem mylist 0 c

总结：

方式1最简单，但实际应用比较局限，方式3可以实现复杂优先级，但实现比较复杂，不利于维护

方式2是推荐用法，实际应用最为合适 方式1、3可以作为redis应用思路的一个拓展

如何基于redis实现消息队列？

如何基于redis实现发布和订阅？以及发布订阅和消息队列的区别？

Pub/Sub功能（means Publish,Subscribe）即发布及订阅功能。基于事件的系统中，Pub/Sub是目前广泛使用的通信模型，它采用事件作为基本的通信机制，提供大规模系统所要求的松散耦合的交互模式：订阅者(如客户端)以事件订阅的方式表达出它有兴趣接收的一个事件或一类事件；发布者(如服务器)可将订阅者感兴趣的事件随时通知相关订阅者。

pub端（发布者）

#coding:utf-8
import time
import redis
 
number_list = [300033300032300031300030']
signal = [1-1]
 
rc = redis.StrictRedis(host=***63793,password=********)
for i in range(len(number_list)):
    value_new = str(number_list[i]) + ' ' + str(signal[i])
    rc.publish("liao",value_new)  #发布消息到liao

sub端（订阅者）：

#coding:utf-
import redis
 
rc = redis.StrictRedis(host=**********ps = rc.pubsub()
ps.subscribe()  #从liao订阅消息
for item in ps.listen():        #监听状态：有消息发布了就拿过来
    if item[type'] == message:
        print item[channel]
        print item[data']

关于数据结构，也就是item，是类似于：{'pattern': None,'type': 'message','channel': 'liao','data': '300033 1'}这样的，所以可以通过channel来判断这个消息是属于哪一个队列里的。（运行程序的时候，先运行订阅者，在运行发布者程序）

总结，要点有两个：

• 一是连接方式。使用python连接redis有三种方式：①使用库中的Redis类（或StrictRedis类，其实差不多）；②使用ConnectionPool连接池（可保持长连接）；③使用Sentinel类（如果有多个redis做集群时，程序会自己选择一个合适的连接）。
• 二是订阅方法。这里使用的是StrictRedis类中的pubsub方法。连接好之后，可使用subscribe或psubscribe方法来订阅redis消息。其中subscribe是订阅一个频道，psubscribe可订阅多个频道（这样写的时候，作为参数的频道应该是一个列表）。之后就可以开始监听了

什么是codis及作用？

什么是twemproxy及作用？

写代码实现redis事务操作。

python中通过管道Pipeline实现Redis事务。当我们要使用事务时，首先实例化一个Pipeline类，可以先实例化StrictRedis类，然后调用实例的pipeline()方法；也可以直接实例化Pipeline类。两种方法都会创建BasePipeLine实例。Redis事务中对应的MULTI， EXEC, DISCARD, WATCH操作都对应到BasePipeLine中的相应方法。

redis = Redis(host=127.0.0.1)
pipe = redis.pipeline()
pipe = Pipeline(host=
try:
    pipe.watch(key1)
    pipe.multi()
    pipe.set(key2)
    pipe.incr()
    pipe.set(key3)
    pipe.execute()
except redis.exceptions.WatchError:
     发生watcherror时业务应该怎样处理，丢弃事务或者重试
    pass

看一下python中execute()方法的源码：

def execute(self,raise_on_error=True):
        Execute all the commands in the current pipeline"
        stack = self.command_stack
        if not stack:
            return []
        if self.scripts:
            self.load_scripts()
        if self.transaction or self.explicit_transaction:
            execute = self._execute_transaction
        else:
            execute = self._execute_pipeline

        conn = self.connection
         conn:
            conn = self.connection_pool.get_connection(MULTI,self.shard_hint)
             assign to self.connection so reset() releases the connection
             back to the pool after we're done
            self.connection = conn

        :
             execute(conn,stack,raise_on_error)
         (ConnectionError,TimeoutError) as e:
            conn.disconnect()
             self.watching:
                raise WatchError(A ConnectionError occured on while watching "
                                 one or more keys)
            finally:
            self.reset()

redis中的watch的命令的作用？

基于redis如何实现商城商品数量计数器？

INCR key

将 key 中储存的数字值增一。

如果 key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作。

如果值包含错误的类型，或字符串类型的值不能表示为数字，那么返回一个错误。

本操作的值限制在 64 位(bit)有符号数字表示之内。

计数器是 Redis 的原子性自增操作可实现的最直观的模式了，它的想法相当简单：每当某个操作发生时，向 Redis 发送一个 INCR 命令。

简述redis分布式锁和redlock的实现机制。

什么是一致性哈希？Python中是否有相应模块？

首先安装python的一致性hash实现库hash_ring

pip install hash_ring

然后使用hash_ring

from hash_ring import HashRing
memcache_servers = [192.168.0.246:11212192.168.0.247:11212192.168.0.249:11212]
 
ring = HashRing(memcache_servers)
server = ring.get_node(my_key')

一致性hash可以用在服务器的负载均衡下，用来多服务器或多数据库提供服务时，可以将请求平均分发给每个server

可以提供第二个参数用来设置每个服务的权重

]
servers_weights = {':1':2':3}
ring = HashRing(memcache_servers,weights=servers_weights)
server = ring.get_node(')

如何高效的找到redis中所有以oldboy开头的key？

原文地址：https://www.cnblogs.com/tracydzf