一：关系型数据库和非关系型数据库区别

1.关系型数据库最典型的数据结构是表，由二维表及其之间的联系所组成的一个数据组织

优点：

（1）易于维护：都是使用表结构，结构一致

（2）使用方便：SQL语言使得我们操作数据库更加方便

（3）支持SQL：可以通过SQL语句进行复杂查询

缺点

（1）读写性能比较差，尤其是海量数据的高效率读写

（2）固定的表的结构，灵活性差

（3）硬盘I/O要求高：网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈

2.非关系型数据库 不是数据库，而是数据结构化存储方法的集合，可以是文档或键值对等

优点

（1）格式灵活：存储数据格式可以是key，value格式，文档格式，图片格式等等，使用灵活，应用场景广泛，而关系型数据库只支持基础的数据类型

（2）速度快：nosql可以使用硬盘或者随机存储器作为载体，而关系型数据库只能使用硬盘；

（3）高扩展性；Nosql基于键值对，数据之间没有耦合性，所以非常容易水平扩展

缺点

(1)不支持事务的ACID特性

(2)不提供SQL支持，学习和使用成本较高

(3)只适合存储一些较为简单的数据，需要进行较复杂查询的数据，关系型数据库显的更为合适

二：什么是Redis

Redis是用C语言编写的，开源的高性能非关系型数据库（Nosql），是一个高性能的key--value数据库；

Redis可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值得类型可以为字符串，List列表，Set集合，Sorted set有序集合，Hash散列表。

与传统数据库不同的是Redis的数据库是存储与内存中的，所以读写速度非常快，所以Redis被广泛应用与缓存方向，每秒可以处理超过10w次读写操作，是已执性能最快的Key--value DB；

此外，Redis也经常用来做分布式锁。而且Redis还支持事务，持久化，LUA脚本，LRU驱动事件，多种集群方案。

三：Redis的优缺点

优点：

（1）读写性能优异

（2）支持数据持久化---AOF持久化和RDB持久化

（3）支持事务，Redis的所有操作都是原子性的

（4）数据结构丰富，除了支持String类型之外，还支持hash，set，zset，list等数据结构

（5）支持主从复制，主机会自动将数据同步到从机，可进行读写分离

缺点

（1）数据库容量容易受到物理内存的限制，不能用作高性能海量数据读写，因此Redis主要适用于较小数据量的高性能操作和运算上

（2）Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写需求失败，需要等待机器重启或者手动切换前端的IP才能恢复

（3）主机宕机，宕机前有部分数据未能同步到从机，切换IP后会引入数据不一致的问题

（4）Redis较难支持在线扩容，在集群容量达到上限时，扩容会变得很复杂；所有运维人员在系统上线时必须确保足够的空间，这对资源造成很大的浪费

四：Redis支持事务持久化--- RDB 和 AOF

RDB持久化可以在指定时间间隔内生成数据集的时间点快照

在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。

以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次 数据集： # save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可

AOF持久化是记录服务器执行的所有读写操作命令，并在服务器启动时，通过执行这些命令来还原数据集。AOF文件中的命令全部以Redis协议的格式来保存，新命令会被追加到文件的末尾；

你可以通过修改配置文件来打开 AOF 功能：

1 # appendonly yes

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。 有三个选项：

1 appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。

2 appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。

3 appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

Redis还可以在后台对AOF文件进行重写，使AOF文件的体积不会超出保存数据集状态所需的实际大小，。

Redis还可以同时使用RDB和AOF持久化。在这种情况下，当Redis重启时，他会优先使用AOF文件来还原数据集，因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。

五：为什么要用Redis/为什么要用缓存

主要从高性能和高并发这两个角度来看待问题

高性能：

假如用户第一次访问数据库中的某些数据，这个过程时比较慢的，因为使用硬盘上直接读取的。将该用户访问的数据存储在缓存中，这样下次再次访问这些数据的时候，就可以直接去缓存中拿了。操作缓存就是直接操作内存，所以速度特别快。如果数据库中的数据改变后，同步改变缓存中相对应得数据即可。

高并发：

直接操作缓存所能承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户中的一部分请求会直接到缓存中，而不是数据库。

六：为什么Redis这么快

（1）完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存 中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是 O(1)；

（2）数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的

（3）采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者 多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁 操作，没有因为可能出现死锁而导致的性能消耗；

（4）使用多路 I/O 复用模型，非阻塞 IO

七：Redis有哪些数据类型

Redis主要有5种数据类型，包括String，List，Set，Zset，Hash，满足大部分 的使用要求

String

常用命令 ：set/get/decr/incr/mget等；

应用场景 ：String是最常用的一种数据类型，普通的key/value存储都可以归为此类；

实现方式：String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr、decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。

List

常用命令 ：lpush/rpush/lpop/rpop/lrange等；

应用场景 ：Redis list的应用场景 非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现；

实现方式：Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。

Set

常用命令 ：sadd/spop/smembers/sunion等；

应用场景 ：Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的；

实现方式：set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。

Sorted Set

常用命令 ：zadd/zrange/zrem/zcard等；

应用场景 ：Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。

实现方式：Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

Hash

常用命令 ：hget/hset/hgetall等

应用场景 ：我们要存储一个用户信息对象数据，其中包括用户ID、用户姓名、年龄和生日，通过用户ID我们希望获取该用户的姓名或者年龄或者生日；

实现方式：Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口。如图所示，Key是用户ID, value是一个Map。这个Map的key是成员的属性名，value是属性值。这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field)，也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据。当前HashMap的实现有两种方式：当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，这时对应的value的redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap,此时redisObject的encoding字段为int。

八：Redis的过期键和删除策略

我们都知道，Redis是key-value数据库，我们可以设置Redis中缓存的key的过 期时间。Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理。

过期策略通常有以下三种

（1）定时过期：每个过期时间的Key都需要一个定时器，到过期期间就会立即清楚。该策略可以立即清楚过期的key，对内存很友好；但是会占用大量CPU去处理过期的数据，从而影响缓存的响应时间和吞吐量。

（2）惰性过期：只有当访问一个key时，才会去判断这个Key是否已经过期，过期则清除；该策略可以最大化的节省CPU资源，但对内存十分不友好，极端情况可能出现大量的 过期key没有再次被访问，从而不会被清除，占用大量内存

（3）定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数 量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定 时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达 到最优的平衡效果。

九：MySQL里有2000w数据，redis中只存20w的数据，如何 保证redis中的数据都是热点数据

Redis内存数据集大小上升到一定大小时，就会实施数据淘汰策略

十：Redis的内存淘汰策略有哪些

全局的键空间选择性移

no-eviction：当内存不足以容纳新写入数据时，新写入操作会报错。

allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用 的key。 （这个是最常用的）

allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

设置过期时间的键空间选择性移除

volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中， 移除最近最少使用的key。

volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空 间中，随机移除某个key。

volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除将要过期的key，ttl的值越大优先被移除。

Redis的内存淘汰策略的选取并不会影响过期的key的处理。内存淘汰策略用于 处理内存不足时的需要申请额外空间的数据；过期策略用于处理过期的缓存数据。

十一：Redis到底是不是单线程的

Redis是单线程的；通常说的单线程，主要是指Redis对外提供的键值存储服务的主要流程是单线程，也就是网络I/O和数据读写是由单个线程来完成的。

除此之外Redis的其他功能，例如持久化，异步删除，集群数据同步等，是由额外线程来执行的。

因此，严格来说Redis并不是全面单线程。

十二：Redis I/O多路复用

首先，Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。

I/O 多路复用其实是在单个线程中通过记录跟踪每一个sock（I/O流） 的状态来管理多个I/O流。

（1）select, poll, epoll 都是I/O多路复用的具体的实现

之所以有这三个鬼存在，其实是他们出现是有先后顺序的。

I/O多路复用这个概念被提出来以后， select是第一个实现 (1983 左右在BSD里面实现的)。

一、select 被实现以后，很快就暴露出了很多问题。

• select 会修改传入的参数数组，这个对于一个需要调用很多次的函数，是非常不友好的。
• select 如果任何一个sock(I/O stream)出现了数据，select 仅仅会返回，但是并不会告诉你是那个sock上有数据，于是你只能自己一个一个的找，10几个sock可能还好，要是几万的sock每次都找一遍，这个无谓的开销就颇有海天盛筵的豪气了。
• select 只能监视1024个链接， 这个跟草榴没啥关系哦，linux 定义在头文件中的，参见FD_SETSIZE。
• select 不是线程安全的

二、于是14年以后(1997年）一帮人又实现了poll, poll 修复了select的很多问题，比如

• poll 去掉了1024个链接的限制，于是要多少链接呢， 主人你开心就好。
• poll 从设计上来说，不再修改传入数组

但是poll仍然不是线程安全的， 这就意味着，不管服务器有多强悍，你也只能在一个线程里面处理一组I/O流。你当然可以那多进程来配合了，不过然后你就有了多进程的各种问题。

于是5年以后, 在2002, 大神 Davide Libenzi 实现了epoll.

三、epoll 可以说是I/O 多路复用最新的一个实现，epoll 修复了poll 和select绝大部分问题, 比如：

• epoll 现在是线程安全的。
• epoll 现在不仅告诉你sock组里面数据，还会告诉你具体哪个sock有数据，你不用自己去找了。

可是epoll 有个致命的缺点，只有linux支持。

虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只注册自己感兴趣的socket或者IO请求，然后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率。

IO多路复用模型使用了Reactor设计模式实现了这一机制。

（2）IO多路复用(Reactor)

通过Reactor的方式，可以将用户线程轮询IO操作状态的工作统一交给handle_events事件循环进行处理。用户线程注册事件处理器之后可以继续执行做其他的工作（异步），而Reactor线程负责调用内核的select函数检查socket状态。当有socket被激活时，则通知相应的用户线程（或执行用户线程的回调函数），执行handle_event进行数据读取、处理的工作。由于select函数是阻塞的，因此多路IO复用模型也被称为异步阻塞IO模型。

注意，*这里的所说的阻塞是指select函数执行时线程被阻塞，而不是指socket。*一般在使用IO多路复用模型时，socket都是设置为NONBLOCK的，不过这并不会产生影响，因为用户发起IO请求时，数据已经到达了，用户线程一定不会被阻塞。

十三：Redis事务相关的命令

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的 Redis会将一个事务中的所有命令序列化，然后按顺序执行。

（1）redis不支持回滚：““Redis 在事务失败时不进行回滚，而是继续执行 余下的命令”

（2）如果一个事务的命令出现错误，那么所有的命令都不会再执行

（3）如果在一个事务中出现运行错误，那么正确的命令会被执行

• WATCH 命令是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS） 行为。 可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务 就不会执行，监控一直持续到EXEC命令。
• MULTI命令用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以 继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列 中，当EXEC命令被调用时，所有队列中的命令才会被执行。
• EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执 行的先后顺序排列。 当操作被打断时，返回空值 nil 。 通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端 会从事务状态中退出。
• UNWATCH命令可以取消watch对所有key的监控。

十四：事务与Redis

Redis的事务总是具有ACID中的一致性和隔离性，其他特性是不支持的。当服 务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，事务 也具有耐久性。

Redis事务支持隔离性吗

Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可 以运行直到执行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有 隔离性的。

Redis事务保证原子性吗，支持回滚吗

Redis中单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务 中任意命令执行失败，其余的命令仍会被执行。

Redis事务其他实现

基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行， 其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是 会继续运行完

基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时 先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐

十五：Redis主从复制

如果你为master配置了一个slave，不管这个slave是否是第一次连接上Master，它都会发送一个PSYNC 命令给master请求复制数据。

master收到PSYNC命令后，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件，持久化期 间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。

当持久化进行完 毕以后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后 再加载到内存中。

然后，master再将之前缓存在内存中的命令发送给slave。

当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多 个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送 给多个并发连接的slave。

数据部分复制

当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，redis改用可以支 持部分数据复制的命令PSYNC去master同步数据，slave与master能够在网络连接断开重连后只进行部分数据复制(断点续传)。

master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的 slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master 继续进行未完成的复制，从所记录的数据下标开始。如果master进程id变化了，或者从节点数据下标 offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。

十六：Redis哨兵模式

有以下功能：

（1）集群监控：负责监控 redis master 和 slave 进程是否正常工作。

（2）消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给 管理员。 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。

（3）配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

（4）哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去 运行，互相协同工作。 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可 用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

哨兵的核心知识

（1）哨兵至少需要 3 个实例，来保证自己的健壮性。

（2）哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群 的高可用性。

（3）对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进 行充足的测试和演练。

十七：redis缓存穿透

理 解

• 重在穿透吧，也就是访问透过redis直接经过mysql，通常是一个不存在的key,在数据库查询为null。每次请求落在数据库、并且高并发。数据库扛不住会挂掉。

解决方案

• 可以将查到的null设成该key的缓存对象。
• 当然，也可以根据明显错误的key在逻辑层就就行验证。
• 同时，你也可以分析用户行为，是否为故意请求或者爬虫、攻击者。针对用户访问做限制。
• 其他等等，比如采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层 存储系统的查询压力

十八：redis缓存雪崩

是指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库 上，造成数据库短时间内承受大量请求而崩掉。

解决方案

• 通常的解决方案是将key的过期时间后面加上一个随机数，让key均匀的失效。
• 考虑用队列或者锁让程序执行在压力范围之内，当然这种方案可能会影响并发量。
• 热点数据可以考虑不失效

十九：缓存击穿

缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，好像蛮力击穿一样。

击穿和穿透不同，穿透的意思是想法绕过redis去使得数据库崩掉。而击穿你可以理解为正面刚击穿,这种通常为大量并发对一个key进行大规模的读写操作。这个key在缓存失效期间大量请求数据库，对数据库造成太大压力使得数据库崩掉。就比如在秒杀场景下10000块钱的mac和100块的mac这个100块的那个订单肯定会被抢到爆，不断的请求(当然具体秒杀有自己处理方式这里只是举个例子)。所以缓存击穿就是针对某个常用key大量请求导致数据库崩溃。

解决方法

• 可以使用互斥锁避免大量请求同时落到db。
• 可以将缓存设置永不过期(适合部分情况)

二十：Redis分片

redis的主从复制和哨兵可以解决高并发，高可用读的问题，但是还有两个没有解决

（1）高并发写

（2）海量数据存储

但是redis的分片可以解决以上问题

二十一：Redis是单线程的，如何提高多核CPU的利用率？

可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的， 所以，如果你想使用多个CPU，你可以考虑一下分片（shard）。

二十二：Redis分区有什么缺点？

（1） 涉及多个key的操作通常不会被支持。例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例（实际上这种情况也有办法，但是不能直接使用交集指令）。
同时操作多个key,则不能使用Redis事务.
（2）分区使用的粒度是key，不能使用一个非常长的排序key存储一个数据集
（3）当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的Redis实例和主机同时收集RDB / AOF文件。
（4）分区时动态扩容或缩容可能非常复杂。Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。然而，有一种预分片的技术也可以较好的解决这个问题。

二十三：如何解决 Redis 的并发竞争 Key 问题

所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作，但是最后执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同！

推荐一种方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。（如果不存在 Redis 的并发竞争 Key 问题，不要使用分布式锁，这样会影响性能）

基于zookeeper临时有序节点可以实现的分布式锁。大致思想为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流程后，删除对应的子节点释放锁。

在实践中，当然是从以可靠性为主。所以首推Zookeeper。

二十四：分布式Redis是前期做还是后期规模上来了再做好？为什么？

既然Redis是如此的轻量（单实例只使用1M内存），为防止以后的扩容，最好的办法就是一开始就启动较多实例。即便你只有一台服务器，你也可以一开始就让Redis以分布式的方式运行，使用分区，在同一台服务器上启动多个实例。

一开始就多设置几个Redis实例，例如32或者64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的。

这样的话，当你的数据不断增长，需要更多的Redis服务器时，你需要做的就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已（而不用考虑重新分区的问题）。一旦你添加了另一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器。

二十五：如何保证缓存与数据库双写时的数据一致性？

1.先写缓存，再写数据库

先写缓存，当我们写入缓存成功的时候，突然网络出现异常，导致写数据库失败，这时候数据库没有新的数据，缓存有新的数据，此时缓存中的数据就变成了脏数据

2.先写数据库，再写缓存

如果先更新缓存成功，但是数据库更新失败，则肯定会造成数据不一致

3.先删缓存，再更新数据库

假设在高并发的场景中，同一个用户的同一条数据，有一个读数据请求c，还有另一个写数据请求d（一个更新操作），同时请求到业务系统。如下图所示：

上图流程如下：

1.请求d先过来，把缓存删除了。但由于网络原因，卡顿了一下，还没来得及写数据库。
2.这时请求c过来了，先查缓存发现没数据，再查数据库，有数据，但是旧值。
3.请求c将数据库中的旧值，更新到缓存中。
4.此时，请求d卡顿结束，把新值写入数据库。
在这个过程当中，请求d的新值并没有被请求c写入缓存，同样会导致缓存和数据库的数据不一致的情况。

解决方法：

缓存双删

针对上面这种场景有一种很简单的处理办法，思路很简单：
当d请求写入成功之后，我们在将缓存重删一次。

这就是我们所说的缓存双删，即：

即在写数据库之前删除一次，写完数据库后，再删除一次。

该方案有个非常关键的地方是：第二次删除缓存，并非立马就删，而是要在一定的时间间隔之后。

有了缓存删除方案之后，我们在回顾一下高并发下的场景问题：

1.请求d先过来，把缓存删除了。但由于网络原因，卡顿了一下，还没来得及写数据库。
2.这时请求c过来了，先查缓存发现没数据，再查数据库，有数据，但是旧值。
3.请求c将数据库中的旧值，更新到缓存中。
4.此时，请求d卡顿结束，把新值写入数据库。
5.一段时间之后，比如：500ms，请求d将缓存删除。

这样看确实解决了缓存不一致的问题，但是为什么我们非得等一会在删除缓存呢？
请求d卡顿结束，把新值写入数据库后，请求c将数据库中的旧值，更新到缓存中。
此时，如果请求d删除太快，在请求c将数据库中的旧值更新到缓存之前，就已经把缓存删除了，这次删除就没任何意义。我们必须要搞清楚，我们之所以要再删除一次缓存的原因是因为c请求导致缓存中更新了数据库中旧值，我们需要把这个旧值删除掉，所以必须要在请求c更新缓存之后，再删除缓存，才能把旧值及时删除了，删除删除太快，可能后面。

现在解决了一个问题之后，又遇到一个问题：如果第二次删除缓存时，删除失败了该怎么办呢？

4.先跟新数据库，后删除缓存

这一种情况也会出现问题，比如更新数据库成功了，但是在删除缓存的阶段出错了没有删除成功，那么此时再读取缓存的时候每次都是错误的数据了。

此时解决方案就是利用消息队列进行删除的补偿。具体的业务逻辑用语言描述如下：

1. 请求 A 先对数据库进行更新操作
2. 在对 Redis 进行删除操作的时候发现报错，删除失败
3. 此时将Redis 的 key 作为消息体发送到消息队列中
4. 系统接收到消息队列发送的消息后再次对 Redis 进行删除操作

5. 但是这个方案会有一个缺点就是会对业务代码造成大量的侵入，深深的耦合在一起，所以这时会有一个优化的方案，我们知道对 Mysql 数据库更新操作后再 binlog 日志中我们都能够找到相应的操作，那么我们可以订阅 Mysql 数据库的 binlog 日志对缓存进行操作。

   

二十六：redis的大key有什么影响

（1）客户端超时阻塞：因为redis命令是单线程处理的，操作大Key的时候比较耗时，就会阻塞redis，从客户端这个视角来看，就是很久很久没响应

（2）引发网络阻塞：获取 bigkey 时，传输的数据量比较大，会增加带宽的压力

（3）内存分布不均匀：集群模型在slot分片均匀情况下，会出现数据和查询倾斜的情况

（1）持久化影响

首先，我们要知道redis提供了三种AOF日志回写硬盘的策略，分别是

• always：每写入AOF文件数据后，就会执行fysnc（）函数
• Everysec：创建一个异步策略，每秒执行一次fsync（) 函数
• No策略：永不执行fsync（）函数

如果使用的是Always策略，如果写入的是一个大Key，那么主线在执行fynsc（）函数的时候，阻塞的时间就会比较长，因为当写入的数据很大的时候，那么数据同步到这个硬盘还是很耗时的

当使用Everysec策略的时候，由于是异步执行fsync（）函数，所以大key对持久化没用影响

当使用No策略的时候，永不执行fsync（）函数，所以大Key持久化过程不影响主线

AOF的重写机制和RDB快照（besave命令）的过程，都会通过一个fork（）函数创建一个子进程来处理任务，有两个阶段会导致阻塞

1. 创建子进程途中，由于要复制父进程的页表等数据结构，阻塞的时间跟页表的大小有关，页表越大，阻塞时间越长
2. 创建完子进程后，如果父进程修改了共享数据中的大Key，就会发生写时复制，这个期间会拷贝物理内存，如果物理内存越大，那么阻塞的时间自然越长