redis设计思想.doc
免费下载
不同于
nginx
的精雕细琢，
redis
代码的风格趋向于简洁实用。简洁启事，下面所述不再列
举任何源码，不拼凑任何外来资料。去除末枝，下面直入
redis
主题，尽可能简洁地描述
redis
的设计思想。
整体模型：单进程单线程事件驱动模式。
Redis
在主处理流程中，采用了单进程接受各种
client
请求并返回结果，整体处理流程采用
事件驱动的方式进行。通过其
IO
复用的方式监听
aeEventLoop
事件，在事件处理的过程中，
这种模式对处理函数的要求：进行一次事件处理需要尽可能地快。因此会有以下几种处理
方法：
1.
对于非长时间处理事件，直接处理。如
set
命令；
2.
对于需要长时间处理的事件，分步处理，直至完成。如
rehash
过程，在单次事件处理过
程中，每次只移动一个桶。
3.
对于阻塞函数，如从磁盘读取
vm
数据等，采用异步的模式。从磁盘
load
数据，是一个较
为耗时的操作，如处理函数中直接读取数据，将会阻塞整体的单线程处理其他的
client
请
求。
多线程开发的复杂性是我们所清楚的。采用单进程单线程的模式，可以避免很多复杂性，
另外事务性操作，无须额外加锁，大大降低了开发难度。
IO
复用
Redis
的
IO
复 用 层 ， 可 以 看 作 是 一 个
tiny libevent
， 其 实 现 只 有 四 个 文 件 ，
ae.c
，
ae_select.c
，
ae_kqueue.c
，
ae_epoll.c
。 一 目 了 然 ，
ae
是 事 件 监 听 总 的
interface
，
select
、
kqueque
、
epoll
是三种可选的
IO
复用方式。小而够用，简洁高效，充分
体现了
redis
的设计理念。
Redis Default
：
select
，
C10K max
。
事件监听
在单线程事件驱动模型中，往往会遇到两种任务，定时处理任务及事件触发任务，于是会
有如下问题：事件触发任务在无任务时，会处于阻塞状态；定时任务要求定时处理，于是
往往会有如下两种处理方式：
1.
如果定时任务时间间隔为
t
，一般设
IO
复用层的超时时间为
t/10
，这样可以保证定时任
务得到及时处理，在调用所有
cron
任务时，会做间隔时间判断。
2.
计算当前事件与最近的定时任务开始时间的间隔，设置
IO
复用超时时间为该事件。这样
定时任务也能得到及时处理。
注意：以上定时任务的处理时间，都为估约时间，非精确时间。前一种方式每轮计算量少
当容易引起空转，后一种计算量大，但减少了空转次数。
Redis
采用的是后一种方式。
这里也许有人会问：为什么不采用
sigaction
、
setitimer
等设置精确时钟，以后再也不用为
cron
事件做额外处理。原因如下：
定时时钟，往往会让进程陷入内核态，内核软中断往往会打破用户态一个函数的完整性，
因此会破坏相关的状态转移；另外加入软中断的程序，将可能为程序带来不可避免地复杂
性。
以曾经做过一个项目的一段挫折经历为例：
一个电话多路呼转的项目，采用的是单线程异步事件驱动模型，每次定时任务有个让空闲
通道“挂机”的任务。先前采用预制的驱动时钟，时钟信号为实时信号（信号宏值取
32-64
之
间的一个数），信号在
sigqueue
中排队，这样如果任务阻塞返回后，会瞬间抛出大量时钟
事件，造成空闲通道多次挂机失败。后改用
setitimer
设置系统时钟，软中断打断了用户态
的一次
mutex_lock
和
mutex_unlock
，并且挂机时使用了该锁，造成整个进程时有时无的死
锁现象。
数据结构
Intset
，该
set
不同于
hash set
数据结构，该数据结构其实是一个有序数组，对于：
插入 操作 ：二 分 查 找 该有 序数 组— —
>
找到 位置 ——
>
有则 返回 ，无 则插 入 该位 置 ，
memmove
后续元素。
查找操作：二分查找。
相对于以
hash table
为基础的
set
而言，该模型简单且更省空间。时间复杂度，在作者的
presentation
中提及在
size 20-50k
的数据量下，基本与
hashset
无异。这里可以认为，
hash
set
遍历链表的时间，与
intset
二分查找的时间基本差不多。但其实另一方面，作者没有提
及的，
intset
的插入速度，实际降低了，因为需要
memmove
的数据量，是
O(n)
的；但较
hash set
更有优势的是，该
array set
，是有序的。
Ziplist
，该数据结构是针对
small size
数据设计的数组
list
，好比常见的索引数组，不同于
linked list
，其保存在一个数组中，且用
value-header
保存链接项及其本身的偏移、长度，
encoding
等，用于遍历
list
。在需求上，
encoding
保证多种不同的数据，可以保存在同一个
list
中，如
int16
、
int32
、
str
等。
zset
：
hash dict + skip list
。常见的有序
set
以
rb tree
为基础。而在整个
redis
中，我们很难发
现任何复杂数据结构
tree
的踪影。
Redis
以
hash dict
保证散列查找的效率，以跳表结构保证
有序及范围查找需求的快速满足，范围查找抛弃了
rb tree
，
b+-* tree
，也体现了其不想复杂
的简洁美学。
......
整个
redis
中，没有任何专门的内存池结构。所有内存分配，不像
stl
，
niginx
，内存分配都
有其内存池机构分配，
redis
没有！
Redis
全是
size+malloc
的
zmalloc
分配，其常见的小对象，
在
intset
，
ziplist
等数据结构地以数组方式申请，并不断用
realloc
的方式
resize
，间接地体
现了内存池的思想，但却没有实现一个内存池管理模块，作者简单暴力的美学，体现得淋
漓尽致。
持久化模块
持久化是
redis
这种内存数据库的拓展功能，如
memcachedb
对
memcached
一样。其借鉴却
大大削减了
OS
的
vm
处理机制（复杂程度较
memecached
远不在数量级），以够用的理念
拿为己用，在某些地方按照需求定制。其思想为一个大的磁盘文件，作为
vm
文件，
bitmap
保存所有
block
的使用情况，
redisObject
与
vmPointer
为同型异构体，后者指明
value
在
vm
文件中的位置等信息，且对大的
value
进行
lzf
压缩解压以减少磁盘
IO
所带来的性能开销；
而
Key
作为索引永远保存在内存中。
常见的
LRU
实现有如下几种：
如
memcached
，有专门的
lru list
数据结构，保存着数据的
LRU
信息（存入的时间戳，链
表），每次使用会改变这个链表，最终淘汰置换该
list
末尾的数据。
如
Linux
内核，分为
active
和
inactive
两个
list
，根据相应的计算经验规则，将页放入相应
的
list
，并对
inactive
中的
page
进行再激活或淘汰置换。
而
redis
没有相应的
lru
数据结构，其
lru
机制为：整个
redis
有一个时钟，每隔一段时间更
新一次，每一个数据都会保存它们最近使用时当前的时钟，随机选出
dict
中几个数据，根
据其
value
的大小和最后更新的系统时钟值，确定其
swap
的能力，超过某个阈值，则将其
更换出去。
Vm
的思想，对于
redis
这种崇尚简洁实效为美的设计来说，多少还是有些复杂，因此作者
一直在考虑另外一种实现方式去替代
vm
的持久化机制，可见
http://groups.google.com/group/redis-
db/browse_thread/thread/d444bc786689bde9/1565b7570ffbb268?
show_docid=1565b7570ffbb268#
主辅同步模块：
redis
的弱项，目前只能同到辅，而辅不能到主，有待继续开发，对此模块
感兴趣的可以参考
mysql
的实现。
结语：
redis
崇尚简洁、实效、暴力的美学，让
redis
成为
kv-db
中效率的代表，而所有
db
的
source code
中，恐怕很难找到比
redis
更简单易读的代码了。这很多方面，值得我们设计
开发借鉴。
of 3
免费下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
最新上传
相关文档
评论