python面试题:redis数据库
来源链接：
https://www.cnblogs.com/jasontec/p/9699242.html
https://www.cnblogs.com/Java3y/p/10266306.html
介绍：Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API的非关系型数据库。
传统数据库遵循 ACID 规则。而 Nosql（Not Only SQL 的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称） 一般为分布式而分布式一般遵循 CAP 定理。
Github 源码：https://github.com/antirez/redis
Redis 官网：https://redis.io/
Redis支持的数据类型？
String字符串：
格式: set key value
string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。
string类型是Redis最基本的数据类型，一个键最大能存储512MB。
Hash（哈希）
格式: hmset name key1 value1 key2 value2
Redis hash 是一个键值(key=>value)对集合。
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
List（列表）
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）
格式: lpush name value
在 key 对应 list 的头部添加字符串元素
格式: rpush name value
在 key 对应 list 的尾部添加字符串元素
格式: lrem name index
key 对应 list 中删除 count 个和 value 相同的元素
格式: llen name
返回 key 对应 list 的长度
Set（集合）
格式: sadd name value
Redis的Set是string类型的无序集合。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。
zset(sorted set：有序集合)
格式: zadd name score value
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
zset的成员是唯一的,但分数(score)却可以重复。
什么是Redis持久化？Redis有哪几种持久化方式？优缺点是什么？
持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。
Redis 提供了两种持久化方式:RDB（默认） 和AOF
RDB：
rdb是Redis DataBase缩写
功能核心函数rdbSave(生成RDB文件)和rdbLoad（从文件加载内存）两个函数
AOF:
Aof是Append-only file缩写
每当执行服务器(定时)任务或者函数时flushAppendOnlyFile 函数都会被调用， 这个函数执行以下两个工作
aof写入保存：
WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件
SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。
存储结构:
内容是redis通讯协议(RESP )格式的命令文本存储。
比较：
1、aof文件比rdb更新频率高，优先使用aof还原数据。
2、aof比rdb更安全也更大
3、rdb性能比aof好
4、如果两个都配了优先加载AOF
刚刚上面你有提到redis通讯协议(RESP )，能解释下什么是RESP？有什么特点？（可以看到很多面试其实都是连环炮，面试官其实在等着你回答到这个点，如果你答上了对你的评价就又加了一分）
RESP 是redis客户端和服务端之前使用的一种通讯协议；
RESP 的特点：实现简单、快速解析、可读性好
For Simple Strings the first byte of the reply is "+" 回复
For Errors the first byte of the reply is "-" 错误
For Integers the first byte of the reply is ":" 整数
For Bulk Strings the first byte of the reply is "$" 字符串
For Arrays the first byte of the reply is "*" 数组
Redis 有哪些架构模式？讲讲各自的特点
单机版
特点：简单
问题：
1、内存容量有限 2、处理能力有限 3、无法高可用。
主从复制
Redis 的复制（replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制品则为从服务器（slave）。 只要主从服务器之间的网络连接正常，主从服务器两者会具有相同的数据，主服务器就会一直将发生在自己身上的数据更新同步 给从服务器，从而一直保证主从服务器的数据相同。
特点：
1、master/slave 角色
2、master/slave 数据相同
3、降低 master 读压力在转交从库
问题：
无法保证高可用
没有解决 master 写的压力
哨兵
Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。
特点：
1、保证高可用
2、监控各个节点
3、自动故障迁移
缺点：主从模式，切换需要时间丢数据
没有解决 master 写的压力
集群（proxy 型）：
Twemproxy 是一个 Twitter 开源的一个 redis 和 memcache 快速/轻量级代理服务器； Twemproxy 是一个快速的单线程代理程序，支持 Memcached ASCII 协议和 redis 协议。
特点：1、多种 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins
2、支持失败节点自动删除
3、后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致
缺点：增加了新的 proxy，需要维护其高可用。
failover 逻辑需要自己实现，其本身不能支持故障的自动转移可扩展性差，进行扩缩容都需要手动干预
集群（直连型）：
从redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。
特点：
1、无中心架构（不存在哪个节点影响性能瓶颈），少了 proxy 层。
2、数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。
3、可扩展性，可线性扩展到 1000 个节点，节点可动态添加或删除。
4、高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本
5、实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave到 Master 的角色提升。
缺点：
1、资源隔离性较差，容易出现相互影响的情况。
2、数据通过异步复制,不保证数据的强一致性
什么是一致性哈希算法？什么是哈希槽？
这两个问题篇幅过长 网上找了两个解锁的不错的文章
https://www.cnblogs.com/lpfuture/p/5796398.html
https://blog.csdn.net/z15732621582/article/details/79121213
Redis常用命令？
Keys pattern
*表示区配所有
以bit开头的
查看Exists key是否存在
Set
设置 key 对应的值为 string 类型的 value。
setnx
设置 key 对应的值为 string 类型的 value。如果 key 已经存在，返回 0，nx 是 not exist 的意思。
删除某个key
第一次返回1 删除了 第二次返回0
Expire 设置过期时间（单位秒）
TTL查看剩下多少时间
返回负数则key失效，key不存在了
Setex
设置 key 对应的值为 string 类型的 value，并指定此键值对应的有效期。
Mset
一次设置多个 key 的值，成功返回 ok 表示所有的值都设置了，失败返回 0 表示没有任何值被设置。
Getset
设置 key 的值，并返回 key 的旧值。
Mget
一次获取多个 key 的值，如果对应 key 不存在，则对应返回 nil。
Incr
对 key 的值做加加操作,并返回新的值。注意 incr 一个不是 int 的 value 会返回错误，incr 一个不存在的 key，则设置 key 为 1
incrby
同 incr 类似，加指定值 ，key 不存在时候会设置 key，并认为原来的 value 是 0
Decr
对 key 的值做的是减减操作，decr 一个不存在 key，则设置 key 为-1
Decrby
同 decr，减指定值。
Append
给指定 key 的字符串值追加 value,返回新字符串值的长度。
Strlen
取指定 key 的 value 值的长度。
persist xxx(取消过期时间)
选择数据库（0-15库）
Select 0 //选择数据库
move age 1//把age 移动到1库
Randomkey随机返回一个key
Rename重命名
Type 返回数据类型
08
使用过Redis分布式锁么，它是怎么实现的？
先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。
如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？
set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的！
09
使用过Redis做异步队列么，你是怎么用的？有什么缺点？
一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。
缺点：
在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。
能不能生产一次消费多次呢？
使用pub/sub主题订阅者模式，可以实现1:N的消息队列。
----------------------------突出问题-----------------------------
今天来分享一下Redis几道常见的面试题：
- 如何解决缓存雪崩？
- 如何解决缓存穿透？
- 如何保证缓存与数据库双写时一致的问题？
一、缓存雪崩
1.1什么是缓存雪崩？
回顾一下我们为什么要用缓存(Redis)：
现在有个问题，如果我们的缓存挂掉了，这意味着我们的全部请求都跑去数据库了。
在前面学习我们都知道Redis不可能把所有的数据都缓存起来(内存昂贵且有限)，所以Redis需要对数据设置过期时间，并采用的是惰性删除+定期删除两种策略对过期键删除。Redis对过期键的策略+持久化
如果缓存数据设置的过期时间是相同的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存同时失效，全部请求到数据库中。
这就是缓存雪崩：
- Redis挂掉了，请求全部走数据库。
- 对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。
缓存雪崩如果发生了，很可能就把我们的数据库搞垮，导致整个服务瘫痪！
1.2如何解决缓存雪崩？
对于“对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。”这种情况，非常好解决：
- 解决方法：在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。
对于“Redis挂掉了，请求全部走数据库”这种情况，我们可以有以下的思路：
- 事发前：实现Redis的高可用(主从架构+Sentinel 或者Redis Cluster)，尽量避免Redis挂掉这种情况发生。
- 事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)
- 事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。
二、缓存穿透
2.1什么是缓存穿透
比如，我们有一张数据库表，ID都是从1开始的(正数)：
但是可能有黑客想把我的数据库搞垮，每次请求的ID都是负数。这会导致我的缓存就没用了，请求全部都找数据库去了，但数据库也没有这个值啊，所以每次都返回空出去。
缓存穿透是指查询一个一定不存在的数据。由于缓存不命中，并且出于容错考虑，如果从数据库查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，失去了缓存的意义。
这就是缓存穿透：
- 请求的数据在缓存大量不命中，导致请求走数据库。
缓存穿透如果发生了，也可能把我们的数据库搞垮，导致整个服务瘫痪！
2.1如何解决缓存穿透？
解决缓存穿透也有两种方案：
- 由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter提前拦截，不合法就不让这个请求到数据库层！
- 当我们从数据库找不到的时候，我们也将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里边获取了。
- 这种情况我们一般会将空对象设置一个较短的过期时间。
参考资料：
- 缓存系列文章--5.缓存穿透问题
三、缓存与数据库双写一致
3.1对于读操作，流程是这样的
上面讲缓存穿透的时候也提到了：如果从数据库查不到数据则不写入缓存。
一般我们对读操作的时候有这么一个固定的套路：
- 如果我们的数据在缓存里边有，那么就直接取缓存的。
- 如果缓存里没有我们想要的数据，我们会先去查询数据库，然后将数据库查出来的数据写到缓存中。
- 最后将数据返回给请求
3.2什么是缓存与数据库双写一致问题？
如果仅仅查询的话，缓存的数据和数据库的数据是没问题的。但是，当我们要更新时候呢？各种情况很可能就造成数据库和缓存的数据不一致了。
- 这里不一致指的是：数据库的数据跟缓存的数据不一致
从理论上说，只要我们设置了键的过期时间，我们就能保证缓存和数据库的数据最终是一致的。因为只要缓存数据过期了，就会被删除。随后读的时候，因为缓存里没有，就可以查数据库的数据，然后将数据库查出来的数据写入到缓存中。
除了设置过期时间，我们还需要做更多的措施来尽量避免数据库与缓存处于不一致的情况发生。
3.3对于更新操作
一般来说，执行更新操作时，我们会有两种选择：
- 先操作数据库，再操作缓存
- 先操作缓存，再操作数据库
首先，要明确的是，无论我们选择哪个，我们都希望这两个操作要么同时成功，要么同时失败。所以，这会演变成一个分布式事务的问题。
所以，如果原子性被破坏了，可能会有以下的情况：
- 操作数据库成功了，操作缓存失败了。
- 操作缓存成功了，操作数据库失败了。
如果第一步已经失败了，我们直接返回Exception出去就好了，第二步根本不会执行。
下面我们具体来分析一下吧。
3.3.1操作缓存
操作缓存也有两种方案：
- 更新缓存
- 删除缓存
一般我们都是采取删除缓存缓存策略的，原因如下：
- 高并发环境下，无论是先操作数据库还是后操作数据库而言，如果加上更新缓存，那就更加容易导致数据库与缓存数据不一致问题。(删除缓存直接和简单很多)
- 如果每次更新了数据库，都要更新缓存【这里指的是频繁更新的场景，这会耗费一定的性能】，倒不如直接删除掉。等再次读取时，缓存里没有，那我到数据库找，在数据库找到再写到缓存里边(体现懒加载)
基于这两点，对于缓存在更新时而言，都是建议执行删除操作！
3.3.2先更新数据库，再删除缓存
正常的情况是这样的：
- 先操作数据库，成功；
- 再删除缓存，也成功；
如果原子性被破坏了：
- 第一步成功(操作数据库)，第二步失败(删除缓存)，会导致数据库里是新数据，而缓存里是旧数据。
- 如果第一步(操作数据库)就失败了，我们可以直接返回错误(Exception)，不会出现数据不一致。
如果在高并发的场景下，出现数据库与缓存数据不一致的概率特别低，也不是没有：
- 缓存刚好失效
- 线程A查询数据库，得一个旧值
- 线程B将新值写入数据库
- 线程B删除缓存
- 线程A将查到的旧值写入缓存
要达成上述情况，还是说一句概率特别低：
因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率基本并不大。
对于这种策略，其实是一种设计模式：Cache Aside Pattern
删除缓存失败的解决思路：
- 将需要删除的key发送到消息队列中
- 自己消费消息，获得需要删除的key
- 不断重试删除操作，直到成功
3.3.3先删除缓存，再更新数据库
正常情况是这样的：
- 先删除缓存，成功；
- 再更新数据库，也成功；
如果原子性被破坏了：
- 第一步成功(删除缓存)，第二步失败(更新数据库)，数据库和缓存的数据还是一致的。
- 如果第一步(删除缓存)就失败了，我们可以直接返回错误(Exception)，数据库和缓存的数据还是一致的。
看起来是很美好，但是我们在并发场景下分析一下，就知道还是有问题的了：
- 线程A删除了缓存
- 线程B查询，发现缓存已不存在
- 线程B去数据库查询得到旧值
- 线程B将旧值写入缓存
- 线程A将新值写入数据库
所以也会导致数据库和缓存不一致的问题。
并发下解决数据库与缓存不一致的思路：
- 将删除缓存、修改数据库、读取缓存等的操作积压到队列里边，实现串行化。
3.4对比两种策略
我们可以发现，两种策略各自有优缺点：
- 先删除缓存，再更新数据库
- 在高并发下表现不如意，在原子性被破坏时表现优异
- 先更新数据库，再删除缓存(
Cache Aside Pattern设计模式)- 在高并发下表现优异，在原子性被破坏时表现不如意
3.5其他保障数据一致的方案与资料
可以用databus或者阿里的canal监听binlog进行更新。
参考资料：
- 缓存更新的套路
- 如何保证缓存与数据库双写时的数据一致性？
- 分布式之数据库和缓存双写一致性方案解析
- Cache Aside Pattern
https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247484359&idx=1&sn=0994c6246990b7ad42a2d3f294042316&chksm=ebd742c6dca0cbd0a826ace13f4d4eeff282052f4a97b31654ef1b3b32f991374f5c67a45ae9&token=1834317504&lang=zh_CN#rd