最近参加阿里实习被问redis架构,瞬间懵逼了!!所特意去学习了下Redis免得下次又被问懵逼!!!!!!!!!!!
Redis是一个开源的先进的键值存储系统(Redis是一种高级key-value数据库。它跟memcached类似,不过数据可以持久化,而且支持的数据类型很丰富。)。它通常可以用作数据结构服务器,因为它的键可以包含字符串(String)、哈希值(hash)、列表(list)、集合(set)和有序集合(sorted set)。而且Redis使用内存数据集合,你可以根据自身需求定时的将数据持久化在磁盘中,或将日志持久化在日志中。下面从redis的网络模型、数据结构和内存管理、持久化、多机和集群四个方面来理解redis架构:
一,网络模型:
Redis是典型的单进程单线程的事件驱动模型。(异步非阻塞网络I/O?)
Redis流程上整体分为接受请求处理器、响应处理器和应答处理器三个同步模块,每个请求都有经历这三个模块
Redis集成了libevent/epoll/Kqueue/select等多种事件处理机制。不了解网络编程I/O模型的可以参考:http://www.cnblogs.com/wujing-hubei/p/6111347.html
二、数据结构与内存管理
1.字符串
1.1 结构
Redis的字符串是对C语言原始字符串的二次封装,结构如下:
struct sdshdr {
long len;
long free;
char buf[];
};
可以看出,每当定义一个字符串时,除了保存字符的空间,Redis还分配了额外的空间用于管理属性字段。
1.2 内存管理方式
动态内存管理方式,动态方式最大的好处就是能够较为充分的利用内存空间,减少内存碎片化,与此同时带来的劣势就是容易引起频繁的内存抖动,通常采用“空间预分配”和“惰性空间释放”两种优化策略来减少内存抖动,redis也不例外。
每次修改字符串内容时,首先检查内存空间是否符合要求,否则就扩大2倍或者按M增长;减少字符串内容时,内存并不会立刻回收,而是按需回收。
关于内存管理的优化,最基本的出发点就是浪费一点空间还是牺牲一些时间的权衡,像STL、tcmalloc、protobuf3的arena机制等采用的核心思路都是“预分配迟回收”,Redis也是一样的。
1.3 二进制安全
判断字符串结束与否的标识是len字段,而不是C语言的'\0',因此是二进制安全的。
放心的将pb序列化后的二进制字符串存入redis。
简而言之,通过redis的简单封装,redis的字符串的操作更加方便,性能更友好,并且屏蔽了C语言字符串的一些需要用户关心的问题。
2.字典(哈希)
字典的底层一定是hash,涉及到hash一定会涉及到hash算法、冲突的解决方法和hash表扩容和缩容。
2.1 hash算法
Redis使用的就是常用的Murmurhash2,Murmurhash算法能够给出在任意输入序列下的散列分布性,并且计算速度很快。之前做共享内存的Local-Cache的需求时也正是利用了Murmurhash的优势,解决了原有结构的hash函数散列分布性差的问题。
2.2 hash冲突解决方法
链地址法解决hash冲突,通用解决方案没什么特殊的。多说一句,如果选用链地址解决冲突,那么势必要有一个散列性非常好的hash函数,否则hash的性能将会大大折扣。Redis选用了Murmurhash,所以可以放心大胆的采用链地址方案。
2.3 hash扩容和缩容
维持hash表在一个合理的负载范围之内,简称为rehash过程。
rehash的过程也是一个权衡的过程,在做评估之前首先明确一点,不管中间采用什么样的rehash策略,rehash在宏观上看一定是:分配一个新的内存块,老数据搬到新的内存块上,释放旧内存块。
老数据何时搬?怎么搬?就变成了一个需要权衡的问题。
第一部分的网络模型上明确的指出Redis的事件驱动模型特点,不适合玩长耗时操作。如果一个hashtable非常大,需要进行扩容就一次性把老数据copy过去,那就会非常耗时,违背事件驱动的特点。所以Redis依旧采用了一种惰性的方案:
新空间分配完毕后,启动rehashidx标识符表明rehash过程的开始;之后所有增删改查涉及的操作时都会将数据迁移到新空间,直到老空间数据大小为0表明数据已经全部在新空间,将rehashidx禁用,表明rehash结束。
将一次性的集中问题分而治之,在Redis的设计哲学中体现的淋漓尽致,主要是为了避免大耗时操作,影响Redis响应客户请求。
3.整数集合
变长整数存储,整数分为16/32/64三个变长尺度,根据存入的数据所属的类型,进行规划。
每次插入新元素都有可能导致尺度升级(例如由16位涨到32位),因此插入整数的时间复杂度为O(n)。这里也是一个权衡,内存空间和时间的一个折中,尽可能节省内存。
4.跳跃表
Redis的skilplist和普通的skiplist没什么不同,都是冗余数据实现的从粗到细的多层次链表,Redis中应用跳表的地方不多,常见的就是有序集合。
Redis的跳表和普通skiplist没有什么特殊之处。
5.链表
Redis的链表是双向非循环链表,拥有表头和表尾指针,对于首尾的操作时间复杂度是O(1),查找时间复杂度O(n),插入时间复杂度O(1)。
Redis的链表和普通链表没有什么特殊之处。
AOF持久化日志,RDB持久化实体数据,AOF优先级大于RDB。但是默认的 是RDB.
1.AOF持久化
机制:通过定时事件将aof缓冲区内的数据定时写到磁盘上。
基于语句追加方式(aof):
aof方式实际类似mysql的基于语句的binlog方式,即每条会使Redis内存数据发生改变的命令都会追加到一个log文件中,也就是说这个log文件就是Redis的持久化数据。
Append-only:filesnapshotting方法在redis异常死掉时, 最近的数据会丢失(丢失数据的多少视你save策略的配置),所以这是它最大的缺点,当业务量很大时,丢失的数据是很多的。Append-only方法可 以做到全部数据不丢失,但redis的性能就要差些。AOF就可以做到全程持久化,只需要在配置文件中开启(默认是no),appendonly yes开启AOF之后,redis每执行一个修改数据的命令,都会把它添加到aof文件中,当redis重启时,将会读取AOF文件进行“重放”以恢复到 redis关闭前的最后时刻。
2.RDB持久化
默认redis是会以快照的形式将数据持久化到磁盘的(一个二进 制文件,dump.rdb,这个文件名字可以指定),在配置文件中的格式是:save N M表示在N秒之内,redis至少发生M次修改则redis抓快照到磁盘。当然我们也可以手动执行save或者bgsave(异步)做快照。
工作原理简单介绍一下:当redis需要做持久化时,redis会fork一个子进程;子进程将数据写到磁盘上一个临时RDB文件中;当子进程完成写临时文件后,将原来的RDB替换掉,这样的好处就是可以copy-on-write
四.多机和集群
1.主从服务器
避免单点是所有服务的通用问题,Redis也不例外。解决单点就要有备机,有备机就要解决固有的数据同步问题。
1.1 sync——原始版主从同步
Redis最初的同步做法是sync指令,通过sync每次都会全量数据,显然每次都全量复制的设计比较消耗资源。改进思路也是常规逻辑,第一次全量,剩下的增量,这就是现在的psync指令的活。
1.2 psync
部分重同步实现的技术手段是“偏移序号+积压缓冲区”,具体做法如下:
(1)主从分别维护一个seq,主每次完成一个请求便seq+1,从每同步完后更新自己seq;
(2)从每次打算同步时都是携带着自己的seq到主,主将自身的seq与从做差结果与积压缓冲区大小比较,如果小于积压缓冲区大小,直接从积压缓冲区取相应的操作进行部分重同步;
(3)否则说明积压缓冲区不能够cover掉主从不一致的数据,进行全量同步。
本质做法用空间换时间,显然在这里牺牲部分空间换回高效的部分重同步,收益比很大。