前言
我们将先从Redis、Nginx+Lua等技术点出发,了解缓存应用的场景。通过使用缓存相关技术，解决高并发的业务场景案例，来深入理解一套成熟的企业级缓存架构如何设计的。本文Redis部分总结于蒋德钧老师的《Redis核心技术与实战》。
Redis基础
简介
Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
它通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Hash), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。
Redis 与其他 key - value 缓存产品有以下三个特点：
- Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
- Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
- Redis支持数据的备份，即master-slave模式的数据备份。
优势
- 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
- 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
- 原子 – Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。
- 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。
数据类型
String（字符串）
string 是 redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个 key 对应一个 value。
string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。
string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。
redis 127.0.0.1:6379> SET runoob "laowang"
OK
redis 127.0.0.1:6379> GET runoob
"laowang"
Hash（哈希）
Redis hash 是一个键值(key=>value)对集合。
Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。
每个 hash 可以存储 2^32 -1 键值对（40多亿）。
redis 127.0.0.1:6379> HMSET runoob field1 "Hello" field2 "World"
"OK"
redis 127.0.0.1:6379> HGET runoob field1
"Hello"
redis 127.0.0.1:6379> HGET runoob field2
"World"
List（列表）
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。
列表最多可存储 2^32 - 1 元素 (4294967295, 每个列表可存储40多亿)。
redis 127.0.0.1:6379> lpush runoob redis
(integer) 1
redis 127.0.0.1:6379> lpush runoob mongodb
(integer) 2
redis 127.0.0.1:6379> lpush runoob rabitmq
(integer) 3
redis 127.0.0.1:6379> lrange runoob 0 10
1) "rabitmq"
2) "mongodb"
3) "redis"
Set（集合）
Redis 的 Set 是 string 类型的无序集合。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。
sadd 命令 :添加一个 string 元素到 key 对应的 set 集合中，成功返回 1，如果元素已经在集合中返回 0。
集合中最大的成员数为 2^32 - 1(4294967295, 每个集合可存储40多亿个成员)。
redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> sadd runoob redis
(integer) 1
redis 127.0.0.1:6379> sadd runoob mongodb
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 0
redis 127.0.0.1:6379> smembers runoob
1) "redis"
2) "rabitmq"
3) "mongodb"
zset(sorted set：有序集合)
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
zset的成员是唯一的,但分数(score)却可以重复。
zadd 命令 :添加元素到集合，元素在集合中存在则更新对应score
redis 127.0.0.1:6379> zadd runoob 0 redis
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 mongodb
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 0
redis 127.0.0.1:6379> > ZRANGEBYSCORE runoob 0 1000
1) "mongodb"
2) "rabitmq"
3) "redis"
Redis深入：带着问题出发？
如果让你设计一个KV数据库,该如何设计
对这个问题的思考,将有助于我们从整体架构上去学习Redis。
假设现在我们已经设计好了一个KV数据库，首先如果我们要使用，是不是得有入口，我们是通过动态链接库还是通过网络socket对外提供访问入口，这就涉及到了访问模块。Redis就是通过
通过访问模块访问KV数据库之后，我们的数据存储在哪里？为了保证访问的高性能，我们选在存储在内存中，这又需要有存储模块。存在内存中的数据，虽然访问速度快，但存在的的问题就是断电后，无法恢复数据，所以我们还需要支持持久化操作。
有了存储模块，我们还需要考虑，数据是以什么样的形式存储？怎样设计才能让数据操作更优，这就设计到了，数据类型的支持，索引模块。 索引的作用是让键值数据库根据 key 找到相应 value 的存储位置，进而执行操作。
有了以上模块的只是，我们是不是要对数据进行操作了？比如往KV数据库中插入或更新一条数据，删除和查询，这就是需要有操作模块了。
至此我们已经构造除了一个KV数据库的基本框架了，带着这些架构，我们再深入到每个点中去探究，这样就会轻松很多，不会迷失在末枝细节中了。
Redis为什么那么快
我们都知道Redis访问快，这是因为redis的操作都是在内存上的，内存的访问本身就很快，另外Redis底层的数据结构也对“快”起到了至关重要的作用。
我们平常所以所说Redis的5种数据结构：String、Hash、Set、ZSet和List指的只是键值对中值的数据结构，而我这里所说的数据结构，指的是它们底层实现。
Redis的底层数据结构有：简单动态字符串、整数数组、压缩列表、跳表、hash表、双向列表6种。
简单动态数组:就是String的底层实现
其中整数数组、hash表、双向列表都是我们常见的数据结构
压缩列表和跳表属于特殊的数据结构
压缩列表是Redis实现的特殊的数组:它本质就是一个数组,只不过,我们常见的数组的每个元素分配的空间大小是一致的,这样就会导致有多余的内存空间被浪费了。压缩列表就是为了解决这样的问题，他的每个元素大小是按实际大小分配的，避免了内存的浪费，同时在压缩列表的表头还存了关于改列表的相关属性：用于记录列表个数zllen，表尾偏移量zltail和列表长度zlbytes。表尾还有一个zlend标记列表的结束。
跳表：有序链表查询元素只能逐一查询，跳表本质上就是链表的基础上加了多级索引，通过多级索引的几个跳转，快递定位到元素所在位置。
不同数据结构的查询时间复杂度
上面从存储方面解释了,redis为什么快.
为什么用单线程
逆向思维可以说为什么不用多线程，这个我们得先看下多线程存在哪些问题？在正常应用操作中，使用多线程可以大大提高处理的时间。那是不是可以无限的加大线程数量，以获取更快的处理速度？实际试验后，发现在机器资源有限的情况下，不断增加线程处理时间，并没有像我们想象的那样成线性增长，而是到达一定阶段就趋于平衡，甚至有下降的趋势，这是为什么呢？
其实主要有两个方面，我们知道线程是CPU调度的最小单元，当线程多的时候，CPU需要不停的切换线程，线程切换是需要消耗时间的，当大量线程需要来回切换，那么CPU在这切换的损耗了很多时间。
另外当多个线程，需要对共享资源进行操作的时候，为了保证并发安全性，需要有额外的机制保证，比如加锁。这样就使得当多个线程再操作共享数据时，变成了串行。
所以为了避免这些问题，Redis采用了单线程操作数据。
单线程为什么还真这么快
我们知道Redis单线程操作的,但是只是指的Redis对外提供键值对存储服务是单线程的。Redis的其他功能并不是，比如持久化，异步删除，集群同步等，都是由额外的线程去执行的。
除了上面说的，Redis的大部分操作都是在内存上完成的，加上高效的数据结构，是他实现高性能的一方面。另外一方面Redis采用的多路复用机制，使其在网络IO操作中能并发处理大量的客户端请求。
在网络 IO 操作中，有潜在的阻塞点，分别是 accept() 和 recv()。当 Redis 监听到一个客户端有连接请求，但一直未能成功建立起连接时，会阻塞在 accept() 函数这里，导致其他客户端无法和 Redis 建立连接。类似的，当 Redis 通过 recv() 从一个客户端读取数据时，如果数据一直没有到达，Redis 也会一直阻塞在 recv()。 这就导致 Redis 整个线程阻塞，无法处理其他客户端请求，效率很低。不过，幸运的是，socket 网络模型本身支持非阻塞模式。
Socket 网络模型的非阻塞模式设置，主要体现在三个关键的函数调用上，如果想要使用 socket 非阻塞模式，就必须要了解这三个函数的调用返回类型和设置模式。接下来，我们就重点学习下它们。在 socket 模型中，不同操作调用后会返回不同的套接字类型。socket() 方法会返回主动套接字，然后调用 listen() 方法，将主动套接字转化为监听套接字，此时，可以监听来自客户端的连接请求。最后，调用 accept() 方法接收到达的客户端连接，并返回已连接套接字。
针对监听套接字，我们可以设置非阻塞模式：当 Redis 调用 accept() 但一直未有连接请求到达时，Redis 线程可以返回处理其他操作，而不用一直等待。但是，你要注意的是，调用 accept() 时，已经存在监听套接字了。
类似的，我们也可以针对已连接套接字设置非阻塞模式：Redis 调用 recv() 后，如果已连接套接字上一直没有数据到达，Redis 线程同样可以返回处理其他操作。我们也需要有机制继续监听该已连接套接字，并在有数据达到时通知 Redis。这样才能保证 Redis 线程，既不会像基本 IO 模型中一直在阻塞点等待，也不会导致 Redis 无法处理实际到达的连接请求或数据。
Linux 中的 IO 多路复用机制是指一个线程处理多个 IO 流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听套接字和已连接套接字。内核会一直监听这些套接字上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。为了在请求到达时能通知到 Redis 线程，select/epoll 提供了基于事件的回调机制，即针对不同事件的发生，调用相应的处理函数。
Redis是如何保证数据不丢失的
因为Redis是操作是基于内存的，所有一点系统宕机存在内存中的数据就会丢失，为了实现数据的持久化，Redis中存在两个持久化机制AOF和RBD。
AOF（Append Only File）介绍
AOF的原理就是，通过记录下Redis的所有命令操作，在需要数据恢复的时候，再按照顺序把所有命令执行一次，从而恢复数据。
但跟数据库的写前日志不同的，AOF采用的写后日志，也就是在Redis执行过操作之后，再写入AOF日志。之所以为什么采用写后日志，可以避免因为写日志的占用redis调用的时间，另外为了保证Redis的高性能，在写aof日志的时候，不会做校验，若采用写前日志，如果命令是错误非法的，在恢复数据的时候就会出现异常。采用写后日志，只有命令执行成功的才会被保存。
AOF策略
AOF的执行策略有三种
all:每次写入/删除命令都会被写入日志文件中,保证了数据可靠性,但是写入日志,涉及到了磁盘的IO,必然会影响性能
everysec:每秒钟执行一次日志写入,在一秒之内的命令操作会记录在aof内存缓冲区,每一秒会写回到日志文件中,相对于每次写入性能得以提升,但是在aof缓冲区没有来得及回写到日志文件中时,系统发生宕机就会丢失这部分数据。
no:内存缓冲区的命令记录不会不主动写回到日志文件中,而交给操作系统决定。这种策略性能最高，但是丢失数据的风险也最大。
AOF重写机制
但是AOF文件过大，会带来性能问题，所有AOF重写机制就登场了。
AOF重写的原理是，将多个命令对同一个key的操作合并成一个，因为数据恢复时，我们只要关心数据最后的状态就可以了。
需要注意的是，与AOF日志由主线程写回不同，重写过程是由后台子线程bgwriteaof来完成的,这个避免阻塞主线程,导致数据库性能下降。
每次 AOF 重写时，Redis 会先执行一个内存拷贝，用于重写；然后，使用两个日志保证在重写过程中，新写入的数据不会丢失。而且，因为 Redis 采用额外的线程进行数据重写，所以，这个过程并不会阻塞主线程。
内存快照RDB
RDB Redis DataBase
所谓内存快照，就是指内存中的数据在某一个时刻的状态记录。对 Redis 来说，就是把某一时刻的状态以文件的形式写到磁盘上。
Redis执行RDB的策略是什么？
Redis进行快照的时候，是进行全量的快照，并且为了不阻塞主线程，会默认使用bgsave命令创建一个子线程,专门用于写入RDB文件。
快照期间数据还能修改吗?
如果不能修改，那么在快照期间，这块数据就会只能读取不能修改，那么必然影响使用。如果可以修改，那么Redis是如何实现的？其实Redis是借助操作系统的写时复制，在执行快照期间，让修改的数据，会在内存中拷贝出一份副本，副本的数据可以被写入rdb文件中，而主线程仍然可以修改原数据。
多久执行一次呢？
跟aof同样的问题，如果快照频率低，那么在两次快照期间出现宕机，就会出现数据不完整的情况，如果快照频率过快，那么又会出现两个问题，一个是不停的对磁盘写出，增大磁盘压力，可能上一次写入还没完成，新的快照又来了，造成恶性循环.另外虽然执行快照是主线程fork出来的,但是不停的fork的过程是阻塞主线程的。
那么如何配置才合适呢？
其实我们只需要第一次全量快照，后续只快照有数据变动的地方就可以大大降低快照的资源损耗了，那么如何记录这变动的数据呢，这里我们可以想到aof具有这样的功能。Redis4.0就提使用RDB+AOF混合模式来完成Redis的持久化。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。
主从库是如何实现数据一致的？
前面我们通过Redis的持久化机制，来保证服务器宕机之后，通过回放日志和重新读取RDB文件恢复数据,减少数据丢失的风险。
但是在单台及其的情况下，机器发生宕机，就无法对外提供服务了。我们所说的Redis具有高可靠性，指的一是，数据尽量少丢失，之前持久化机制就解决了这一问题，另一个是服务尽量少中断，Redis的做法是增加副本冗余量。Redis提供的主从模式，主从库之间采用了读写分离的方式。
从库只读取，主库执行读与写，写的数据主库会同步给从库。之所以只让主库写，是因为，如果从库也写，那么当客户端对一个数据修改了3次，为了保证数据的正确性，就要设法让主从库对于写操作协同，这会带来巨额的开销。
主从库间如何进行第一次同步的？
当我们启动多个 Redis 实例的时候，它们相互之间就可以通过 replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系，之后会按照三个阶段完成数据的第一次同步。
主库收到 psync 命令后，会用 FULLRESYNC 响应命令带上两个参数：主库 runID 和主库目前的复制进度 offset，返回给从库。从库收到响应后，会记录下这两个参数。
这里有个地方需要注意，FULLRESYNC 响应表示第一次复制采用的全量复制，也就是说，主库会把当前所有的数据都复制给从库。
在第二阶段，主库将所有数据同步给从库。从库收到数据后，在本地完成数据加载。这个过程依赖于内存快照生成的 RDB 文件。
具体来说，主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。从库接收到 RDB 文件后，会先清空当前数据库，然后加载 RDB 文件。这是因为从库在通过 replicaof 命令开始和主库同步前，可能保存了其他数据。为了避免之前数据的影响，从库需要先把当前数据库清空。
在主库将数据同步给从库的过程中，主库不会被阻塞，仍然可以正常接收请求。否则，Redis 的服务就被中断了。但是，这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。为了保证主从库的数据一致性，主库会在内存中用专门的 replication buffer，记录 RDB 文件生成后收到的所有写操作。
最后，也就是第三个阶段，主库会把第二阶段执行过程中新收到的写命令，再发送给从库。具体的操作是，当主库完成 RDB 文件发送后，就会把此时 replication buffer 中的修改操作发给从库，从库再重新执行这些操作。这样一来，主从库就实现同步了。
Redis如何保证高可用的
主库挂了之后,还能接收写操作吗?
Redis在有了主从集群后，如果从库挂了，Redis对外提供服务不受影响，主库和其他从库，依然可以提供读写服务，但是当主库挂了之后，因为是读写分离的，如果此时有写的请求，那么就无法处理了。Redis是如果解决这样的问题的呢，这就要引入哨兵机制了。
当主库挂了，我们需要从从库中选出一个当做主库，这样就可以正常对外提供服务了。哨兵的本质就是一个Redis示例，只不过它是运行在特殊模式下的Redis进程。它主要有三个作用：监控、选举、通知。
哨兵在监控到主库下线的时候，会从从库中通过一定的规则，选举出适合的从库当主库，并通知其他从库变更主库的信息，让他们执行replicaof命令，和新主库建立连接，并进行数据复制。那么具体每一步都是怎么做的呢？
监控：哨兵会周期性向主从库发送PING命令，检测主库是否正常运行，如果主从库没有在规定的时间内回应哨兵的PING命令，则会被判定为“下线状态”，如果是主库下线，则开始自动切换主库的流程。但是一般如果只有一个哨兵，那么它的判断可能不具有可靠性，所以一般哨兵都是采用集群模式部署，称为哨兵集群。单多个哨兵均判断该主库下线了，那么可能他就真的下线了，这是一个少数服从多数的规则。
选举： 哨兵选择新主库的过程称为“筛选 + 打分”。简单来说，我们在多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。然后，我们再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库，如下图所示：
1、排除那些已经下线的从库，以及连接不稳定的从库。连接不稳定是通过配置项down-after-milliseconds，当主从连接超时达到一定阈值，就会被记录下来，比如设置的10次，那么就会标记该从库网络不好，不适合做为主库。
2、筛选出从库后，第二部就要开始打分了，主要从三方面打分，
1.从库优先级，这是可以通过slave-property设置的，设置的高，打分的就高，就会被选为主库，比如你可以给从库中内存带宽资源充足设置高优先级，当主库挂了之后被优先选举为主库。
2.从库与旧主库之间的复制进度，之前我们知道主从之间增量复制，有个参数slave-repl-offset记录当前的复制进度。这个数值越大，说明与主库复制进度约靠近，打分也会越高。
3.每个从库创建实例的时候，会随机生成一个id，id越小的得分越高。
通知：哨兵提升一个从库为新主库后，哨兵会把新主库的地址写入自己实例的pubsub（switch-master）中。客户端需要订阅这个pubsub，当这个pubsub有数据时，客户端就能感知到主库发生变更，同时可以拿到最新的主库地址，然后把写请求写到这个新主库即可，这种机制属于哨兵主动通知客户端。
如果客户端因为某些原因错过了哨兵的通知，或者哨兵通知后客户端处理失败了，安全起见，客户端也需要支持主动去获取最新主从的地址进行访问。
所以，客户端需要访问主从库时，不能直接写死主从库的地址了，而是需要从哨兵集群中获取最新的地址（sentinel get-master-addr-by-name命令），这样当实例异常时，哨兵切换后或者客户端断开重连，都可以从哨兵集群中拿到最新的实例地址。
哨兵集群
部署哨兵集群的时候，我们知道只需要配置：sentinel monitor
Redis有提供了pub/sub机制，哨兵跟主库建立了连接之后，将自己的信息发布到 “sentinel:hello”频道上，其他哨兵发布并订阅了该频道，就可以获取其他哨兵的信息，那么哨兵之间就可以相互通信了。
那么哨兵如何知道从库的连接信息呢，那是因为INFO命令，哨兵向主库发送该命令后，获得了所有从库的连接信息，就能分从库建立连接，并进行监控了。
从本质上说，哨兵就是一个运行在特定模式下的 Redis 实例，只不过它并不服务请求操作，只是完成监控、选主和通知的任务。所以，每个哨兵实例也提供 pub/sub 机制，客户端可以从哨兵订阅消息。哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。
切片集群
与mysql一样，当一张表的数据很大时，查询耗时可能就会越来越大，我们采取的措施是分表分库。同样的Redis也样，当数据量很大时，比如高达25G，在单分片下，我们需要机器有32G的内存。但是我们会发现，有时候redis响应会变的很慢，通过INFO查询Redis的latest_fork_usec指标,最近fork耗时,发现耗时很大,快到秒级别了,fork这个动作会阻塞主线程，于是就导致了Redis变慢了。
于是就有redis分片集群， 启动多个 Redis 实例组成一个集群，然后按照一定的规则，把收到的数据划分成多份，每一份用一个实例来保存。回到我们刚刚的场景中，如果把 25GB 的数据平均分成 5 份（当然，也可以不做均分），使用 5 个实例来保存，每个实例只需要保存 5GB 数据。
那么，在切片集群中，实例在为 5GB 数据生成 RDB 时，数据量就小了很多，fork 子进程一般不会给主线程带来较长时间的阻塞。采用多个实例保存数据切片后，我们既能保存 25GB 数据，又避免了 fork 子进程阻塞主线程而导致的响应突然变慢。
那么数据是如何决定存在在哪个分片上的呢？
Redis Cluster 方案采用哈希槽（Hash Slot，接下来我会直接称之为 Slot），来处理数据和实例之间的映射关系。在 Redis Cluster 方案中，一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中。具体的映射过程分为两大步：首先根据键值对的 key，按照CRC16 算法计算一个 16 bit 的值；然后，再用这个 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽。
我们在部署 Redis Cluster 方案时，可以使用 cluster create 命令创建集群，此时，Redis 会自动把这些槽平均分布在集群实例上。例如，如果集群中有 N 个实例，那么，每个实例上的槽个数为 16384/N 个。 也可以使用 cluster meet 命令手动建立实例间的连接，形成集群，再使用 cluster addslots 命令，指定每个实例上的哈希槽个数。