前言

​我们将先从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标记列表的结束。

跳表:有序链表查询元素只能逐一查询,跳表本质上就是链表的基础上加了多级索引,通过多级索引的几个跳转,快递定位到元素所在位置。

Java进阶专题(十七) 系统缓存架构设计 (上)-LMLPHP

不同数据结构的查询时间复杂度

Java进阶专题(十七) 系统缓存架构设计 (上)-LMLPHP

上面从存储方面解释了,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() 方法接收到达的客户端连接,并返回已连接套接字。

Java进阶专题(十七) 系统缓存架构设计 (上)-LMLPHP

针对监听套接字,我们可以设置非阻塞模式:当 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来完成的,这个避免阻塞主线程,导致数据库性能下降。

Java进阶专题(十七) 系统缓存架构设计 (上)-LMLPHP

每次 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提供的主从模式,主从库之间采用了读写分离的方式。

Java进阶专题(十七) 系统缓存架构设计 (上)-LMLPHP

从库只读取,主库执行读与写,写的数据主库会同步给从库。之所以只让主库写,是因为,如果从库也写,那么当客户端对一个数据修改了3次,为了保证数据的正确性,就要设法让主从库对于写操作协同,这会带来巨额的开销。

主从库间如何进行第一次同步的?

当我们启动多个 Redis 实例的时候,它们相互之间就可以通过 replicaof(Redis 5.0 之前使用 slaveof)命令形成主库和从库的关系,之后会按照三个阶段完成数据的第一次同步。

Java进阶专题(十七) 系统缓存架构设计 (上)-LMLPHP

主库收到 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命令,则会被判定为“下线状态”,如果是主库下线,则开始自动切换主库的流程。但是一般如果只有一个哨兵,那么它的判断可能不具有可靠性,所以一般哨兵都是采用集群模式部署,称为哨兵集群。单多个哨兵均判断该主库下线了,那么可能他就真的下线了,这是一个少数服从多数的规则。

Java进阶专题(十七) 系统缓存架构设计 (上)-LMLPHP

选举: 哨兵选择新主库的过程称为“筛选 + 打分”。简单来说,我们在多个从库中,先按照一定的筛选条件,把不符合条件的从库去掉。然后,我们再按照一定的规则,给剩下的从库逐个打分,将得分最高的从库选为新主库,如下图所示:

Java进阶专题(十七) 系统缓存架构设计 (上)-LMLPHP

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命令),这样当实例异常时,哨兵切换后或者客户端断开重连,都可以从哨兵集群中拿到最新的实例地址。
Java进阶专题(十七) 系统缓存架构设计 (上)-LMLPHP

哨兵集群

部署哨兵集群的时候,我们知道只需要配置: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 命令,指定每个实例上的哈希槽个数。

11-27 05:53