memcached和redis，作为近年最经常运用的缓存效劳器，置信人人对它们再熟习不过了。前两年还在学校时，我曾读过它们的重要源码，如今写篇笔记从个人角度简朴对照一下它们的完成体式格局，权当作温习，有明白毛病的处所，迎接斧正。
文中运用的架构类的图片大多来自于收集，有部份图与最新完成有相差，文中已指出。
一. 综述
读一个软件的源码，起首要弄懂软件是用作干什么的，那memcached和redis是干啥的？尽人皆知，数据平常会放在数据库中，然则查询数据会相对照较慢，特别是用户许多时，频仍的查询，须要消耗大批的时候。如何办呢？数据放在那里查询快？那肯定是内存中。memcached和redis就是将数据存储在内存中，依据key-value的体式格局查询，可以大幅度进步效力。所以平常它们都用做缓存效劳器，缓存经常运用的数据，须要查询的时候，直接从它们那儿猎取，削减查询数据库的次数，进步查询效力。
二. 效劳体式格局
memcached和redis如何供应效劳呢？它们是自力的历程，须要的话，还可以让他们变成daemon历程，所以我们的用户历程要运用memcached和redis的效劳的话，就须要历程间通讯了。斟酌到用户历程和memcached和redis不肯定在一致台机械上，所以还须要支撑收集间通讯。因而，memcached和redis自身自身就是收集效劳器，用户历程经由历程与他们经由历程收集来传输数据，明显最简朴和最经常运用的就是运用tcp衔接了。别的，memcached和redis都支撑udp协定。而且当用户历程和memcached和redis在一致机械时，还可以运用unix域套接字通讯。
三. 事宜模子
下面最先讲他们细致是如何完成的了。起首来看一下它们的事宜模子。
自从epoll出来今后，险些一切的收集效劳器全都扬弃select和poll，换成了epoll。redis也一样，只不多它还供应对select和poll的支撑，可以自身设置运用哪一个，然则平常都是用epoll。别的针对BSD，还支撑运用kqueue。而memcached是基于libevent的，不过libevent底层也是运用epoll的，所以可以以为它们都是运用epoll。epoll的特征这里就不引见了，网上引见文章许多。
它们都运用epoll来做事宜轮回，不过redis是单线程的效劳器（redis也是多线程的，只不过除了主线程之外，其他线程没有event loop，只是会举行一些背景存储事变），而memcached是多线程的。 redis的事宜模子很简朴，只需一个event loop，是简朴的reactor完成。不过redis事宜模子中有一个亮点，我们晓得epoll是针对fd的，它返回的停当事宜也是只需fd，redis内里的fd就是效劳器与客户端衔接的socket的fd，然则处置惩罚的时候，须要依据这个fd找到细致的客户端的信息，如何找呢？一般的处置惩罚体式格局就是用红黑树将fd与客户端信息保留起来，经由历程fd查找，效力是lgn。不过redis比较特别，redis的客户端的数量上限可以设置，即可以晓得一致时候，redis所翻开的fd的上限，而我们晓得，历程的fd在一致时候是不会反复的（fd只需封闭后才复用），所以redis运用一个数组，将fd作为数组的下标，数组的元素就是客户端的信息，如许，直接经由历程fd就可以定位客户端信息，查找效力是O(1)，还省去了庞杂的红黑树的完成（我曾用c写一个收集效劳器，就因为要坚持fd和connect对应关联，不想自身写红黑树，然后用了STL内里的set，致使项目变成了c++的，末了项目运用g++编译，这事我不说谁晓得？）。明显这类体式格局只能针对connection数量上限已肯定，而且不是太大的收集效劳器，像nginx这类http效劳器就不实用，nginx就是自身写了红黑树。
而memcached是多线程的，运用master-worker的体式格局，主线程监听端口，竖立衔接，然后递次分派给各个事变线程。每一个从线程都有一个event loop，它们效劳差别的客户端。master线程和worker线程之间运用管道通讯，每一个事变线程都邑建立一个管道，然后保留写端和读端，而且将读端到场event loop，监听可读事宜。同时，每一个从线程都有一个停当衔接行列，主线程衔接衔接后，将衔接的item放入这个行列，然后往该线程的管道的写端写入一个connect敕令，如许event loop中到场的管道读端就会停当，从线程读取敕令，剖析敕令发明是有衔接，然后就会去自身的停当行列中猎取衔接，并举行处置惩罚。多线程的上风就是可以充分发挥多核的上风，不过编写顺序贫苦一点，memcached内里就有种种锁和前提变量来举行线程同步。
四. 内存分派
memcached和redis的中心使命都是在内存中操纵数据，内存治理自然是中心的内容。
起首看看他们的内存分派体式格局。memcached是有自身得内存池的，即预先分派一大块内存，然后接下来分派内存就从内存池中分派，如许可以削减内存分派的次数，进步效力，这也是大部份收集效劳器的完成体式格局，只不过各个内存池的治理体式格局依据细致状况而差别。而redis没有自身得内存池，而是直接运用时分派，即什么时候须要什么时候分派，内存治理的事交给内核，自身只担任取和开释（redis既是单线程，又没有自身的内存池，是不是是觉得完成的太简朴了？那是因为它的重点都放在数据库模块了）。不过redis支撑运用tcmalloc来替代glibc的malloc，前者是google的产物，比glibc的malloc快。
因为redis没有自身的内存池，所以内存请求和开释的治理就简朴许多，直接malloc和free即可，异常轻易。而memcached是支撑内存池的，所以内存请求是从内存池中猎取，而free也是还给内存池，所以须要许多分外的治理操纵，完成起来贫苦许多，细致的会在背面memcached的slab机制解说中剖析。
五. 数据库完成
接下来看看他们的最中心内容，各自数据库的完成。
1. memcached数据库完成
memcached只支撑key-value，即只能一个key关于一个value。它的数据在内存中也是如许以key-value对的体式格局存储，它运用slab机制。
起首看memcached是如何存储数据的，即存储key-value对。以下图，每一个key-value对都存储在一个item组织中，包括了相干的属性和key和value的值。
item是保留key-value对的，当item多的时候，如何查找特定的item是个题目。所以memcached保护了一个hash表，它用于疾速查找item。hash表实用开链法（与redis一样）处理键的争执，每一个hash表的桶内里存储了一个链表，链表节点就是item的指针，如上图中的h_next就是指桶内里的链表的下一个节点。 hash表支撑扩容（item的数量是桶的数量的1.5以上时扩容），有一个primary_hashtable，另有一个old_hashtable，其中一般实用primary_hashtable，然则扩容的时候，将old_hashtable = primary_hashtable，然后primary_hashtable设置为新请求的hash表（桶的数量乘以2），然后顺次将old_hashtable 内里的数据往新的hash表内里挪动，并用一个变量expand_bucket纪录以及挪动了若干个桶，挪动完成后，再free本来的old_hashtable 即可（redis也是有两个hash表，也是挪动，不过不是背景线程完成，而是每次挪动一个桶）。扩容的操纵，特地有一个背景扩容的线程来完成，须要扩容的时候，运用前提变量关照它，完成扩容后，它又测验壅塞守候扩容的前提变量。如许在扩容的时候，查找一个item可以会在primary_hashtable和old_hashtable的恣意一其中，须要依据比较它的桶的位置和expand_bucket的大小来比较肯定它在哪一个内外。
item是从那里分派的呢？从slab中。以下图，memcached有许多slabclass，它们治理slab，每一个slab现实上是trunk的鸠合，真正的item是在trunk中分派的，一个trunk分派一个item。一个slab中的trunk的大小一样，差别的slab，trunk的大小按比例递增，须要新请求一个item的时候，依据它的大小来挑选trunk，规则是比它大的最小的谁人trunk。如许，差别大小的item就分派在差别的slab中，归差别的slabclass治理。 如许的瑕玷是会有部份内存糟蹋，因为一个trunk可以比item大，如图2，分派100B的item的时候，挑选112的trunk，然则会有12B的糟蹋，这部份内存资本没有运用。
如上图，悉数组织就是如许，slabclass治理slab，一个slabclass有一个slab_list，可以治理多个slab，一致个slabclass中的slab的trunk大小都一样。slabclass有一个指针slot，保留了未分派的item已被free掉的item（不是真的free内存，只是不必了罢了），有item不必的时候，就放入slot的头部，如许每次须要在当前slab中分派item的时候，直接取slot取即可，不必管item是未分派过的照样被开释掉的。
然后，每一个slabclass对应一个链表，有head数组和tail数组，它们离别保留了链表的头节点和尾节点。链表中的节点就是改slabclass所分派的item，新分派的放在头部，链表越往后的item，示意它已良久没有被运用了。当slabclass的内存不足，须要删除一些逾期item的时候，就可以够从链表的尾部最先删除，没错，这个链表就是为了完成LRU。光靠它还不可，因为链表的查询是O（n）的，所以定位item的时候，运用hash表，这已有了，一切分派的item已在hash表中了，所以，hash用于查找item，然后链表有用存储item的近来运用递次，这也是lru的规范完成要领。
每次须要新分派item的时候，找到slabclass关于的链表，从尾部往前找，看item是不是已逾期，逾期的话，直接就用这个逾期的item当作新的item。没有逾期的，则须要从slab中分派trunk，假如slab用完了，则须要往slabclass中增添slab了。
memcached支撑设置逾期时候，即expire time，然则内部并不按期搜检数据是不是逾期，而是客户历程运用该数据的时候，memcached会搜检expire time，假如逾期，直接返回毛病。如许的长处是，不须要分外的cpu来举行expire time的搜检，瑕玷是有可以逾期数据良久不被运用，则一向没有被开释，占用内存。
memcached是多线程的，而且只保护了一个数据库，所以可以有多个客户历程操纵一致个数据，这就有可以发作题目。比方，A已把数据变动了，然后B也变动了改数据，那末A的操纵就被覆盖了，而可以A不晓得，A使命数据如今的状况时他改完后的谁人值，如许就可以发作题目。为了处理这个题目，memcached运用了CAS协定，简朴说就是item保留一个64位的unsigned int值，标记数据的版本，每更新一次（数据值有修改），版本号增添，然后每次对数据举行变动操纵，须要比对客户历程传来的版本号和效劳器这边item的版本号是不是一致，一致则可举行变动操纵，不然提醒脏数据。
以上就是memcached如何完成一个key-value的数据库的引见。
2. redis数据库完成
起首redis数据库的功用壮大一些，因为不像memcached只支撑保留字符串，redis支撑string， list， set，sorted set，hash table 5种数据组织。比方存储一个人的信息就可以够运用hash table，用人的名字做key，然后name super， age 24， 经由历程key 和 name，就可以够取到名字super，也许经由历程key和age，就可以够取到岁数24。如许，当只须要获得age的时候，不须要把人的悉数信息取回来，然后从内里找age，直接猎取age即可，高效轻易。
为了完成这些数据组织，redis定义了笼统的对象redis object，以下图。每一个对象有范例，一共5种：字符串，链表，鸠合，有序鸠合，哈希表。 同时，为了进步效力，redis为每种范例预备了多种完成体式格局，依据特定的场景来挑选适宜的完成体式格局，encoding就是示意对象的完成体式格局的。然后另有纪录了对象的lru，即上次被接见的时候，同时在redis 效劳器中会纪录一个当前的时候（近似值，因为这个时候只是每隔肯定时候，效劳器举行自动保护的时候才更新），它们两个只差就可以够盘算出对象多久没有被接见了。 然后redis object中另有援用计数，这是为了同享对象，然后肯定对象的删除时候用的。末了运用一个void*指针来指向对象的真正内容。正式因为运用了笼统redis object，使得数据库操纵数据时轻易许多，悉数一致运用redis object对象即可，须要辨别对象范例的时候，再依据type来推断。而且正式因为采纳了这类面向对象的要领，让redis的代码看起来很像c++代码，实在满是用c写的。
//#define REDIS_STRING 0 // 字符串范例
//#define REDIS_LIST 1 // 链表范例
//#define REDIS_SET 2 // 鸠合范例(无序的)，可以求差集，并集等
//#define REDIS_ZSET 3 // 有序的鸠合范例
//#define REDIS_HASH 4 // 哈希范例
//#define REDIS_ENCODING_RAW 0 /* Raw representation */ //raw 未加工
//#define REDIS_ENCODING_INT 1 /* Encoded as integer */
//#define REDIS_ENCODING_HT 2 /* Encoded as hash table */
//#define REDIS_ENCODING_ZIPMAP 3 /* Encoded as zipmap */
//#define REDIS_ENCODING_LINKEDLIST 4 /* Encoded as regular linked list */
//#define REDIS_ENCODING_ZIPLIST 5 /* Encoded as ziplist */
//#define REDIS_ENCODING_INTSET 6 /* Encoded as intset */
//#define REDIS_ENCODING_SKIPLIST 7 /* Encoded as skiplist */
//#define REDIS_ENCODING_EMBSTR 8 /* Embedded sds
string encoding */
typedef struct redisObject {
unsigned type:4; // 对象的范例，包括 /* Object types */
unsigned encoding:4; // 底部为了节约空间，一种type的数据，
// 可 以采纳差别的存储体式格局
unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */
int refcount; // 援用计数
void *ptr;
} robj;
说到底redis照样一个key-value的数据库，不管它支撑若干种数据组织，终究存储的照样以key-value的体式格局，只不过value可以是链表，set，sorted set，hash table等。和memcached一样，一切的key都是string，而set，sorted set，hash table等细致存储的时候也用到了string。 而c没有现成的string，所以redis的首要使命就是完成一个string，取名叫sds（simple dynamic string），以下的代码， 异常简朴的一个组织体，len存储改string的内存总长度，free示意另有若干字节没有运用，而buf存储细致的数据，明显len-free就是现在字符串的长度。
struct sdshdr {
int len;
int free;
char buf[];
};
字符串处理了，一切的key都存成sds就好了，那末key和value如何关联呢？key-value的花样在脚本语言中很优点置惩罚，直接运用字典即可，C没有字典，如何办呢？自身写一个呗（redis异常热衷于造轮子）。看下面的代码，privdata存分外信息，用的很少，最少我们发明。 dictht是细致的哈希表，一个dict对应两张哈希表，这是为了扩容（包括rehashidx也是为了扩容）。dictType存储了哈希表的属性。redis还为dict完成了迭代器（所以说看起来像c++代码）。
哈希表的细致完成是和mc相似的做法，也是运用开链法来处理争执，不过内里用到了一些小技能。比方运用dictType存储函数指针，可以动态设置桶内里元素的操纵要领。又比方dictht中保留的sizemask取size（桶的数量）-1，用它与key做&操纵来替代取余运算，加疾速度等等。总的来看，dict内里有两个哈希表，每一个哈希表的桶内里存储dictEntry链表，dictEntry存储细致的key和value。
前面说过，一个dict关于两个dictht，是为了扩容（实在另有缩容）。一般的时候，dict只运用dictht[0]，当dict[0]中已有entry的数量与桶的数量到达肯定的比例后，就会触发扩容和缩容操纵，我们统称为rehash，这时候，为dictht[1]请求rehash后的大小的内存，然后把dictht[0]里的数据往dictht[1]内里挪动，并用rehashidx纪录当前已挪动万的桶的数量，当一切桶都移完后，rehash完成，这时候将dictht[1]变成dictht[0], 将本来的dictht[0]变成dictht[1]，并变成null即可。差别于memcached，这里不必开一个背景线程来做，而是就在event loop中完成，而且rehash不是一次性完成，而是分红屡次，每次用户操纵dict之前，redis挪动一个桶的数据，直到rehash完成。如许就把挪动分红多个小挪动完成，把rehash的时候开支均分到用户每一个操纵上，如许避免了用户一个请求致使rehash的时候，须要守候很长时候，直到rehash完成才有返回的状况。不过在rehash时期，每一个操纵都变慢了点，而且用户还不晓得redis在他的请求中心增添了挪动数据的操纵，觉得redis太贱了 :-D
typedef struct dict {
dictType *type; // 哈希表的相干属性
void *privdata; // 分外信息
dictht ht[2]; // 两张哈希表，分主和副，用于扩容
int rehashidx; /* rehashing not in progress if rehashidx == -1 */ // 纪录当前数据迁徙的位置，在扩容的时候用的
int iterators; /* number of iterators currently running */ // 现在存在的迭代器的数量
} dict;
typedef struct dictht {
dictEntry **table; // dictEntry是item，多个item构成hash桶内里的链表，table则是多个链表头指针构成的数组的指针
unsigned long size; // 这个就是桶的数量
// sizemask取size - 1, 然后一个数据来的时候，经由历程盘算出的hashkey, 让hashkey & sizemask来肯定它要放的桶的位置
// 当size取2^n的时候，sizemask就是1...111，如许就和hashkey % size有一样的效果，然则运用&会快许多。这就是缘由
unsigned long sizemask;
unsigned long used; // 已数值的dictEntry数量
} dictht;
typedef struct dictType {
unsigned int (*hashFunction)(const void *key); // hash的要领
void *(*keyDup)(void *privdata, const void *key); // key的复制要领
void *(*valDup)(void *privdata, const void *obj); // value的复制要领
int (*keyCompare)(void *privdata, const void *key1, const void *key2); // key之间的比较
void (*keyDestructor)(void *privdata, void *key); // key的析构
void (*valDestructor)(void *privdata, void *obj); // value的析构
} dictType;
typedef struct dictEntry {
void *key;
union {
void *val;
uint64_t u64;
int64_t s64;
} v;
struct dictEntry *next;
} dictEntry;
有了dict，数据库就好完成了。一切数据读存储在dict中，key存储成dictEntry中的key（string），用void* 指向一个redis object，它可以是5种范例中的任何一种。以下图，组织组织是如许，不过这个图已过期了，有一些与redis3.0不相符的处所。
5中type的对象，每一个都最少有两种底层完成体式格局。string有3种：REDIS_ENCODING_RAW, REDIS_ENCIDING_INT, REDIS_ENCODING_EMBSTR， list有：一般双向链表和紧缩链表，紧缩链表简朴的说，就是讲数组改形成链表，一连的空间，然后经由历程存储字符串的大小信息来模仿链表，相对一般链表来讲可以节约空间，不过有副作用，因为是一连的空间，所以转变内存大小的时候，须要重新分派，而且因为保留了字符串的字节大小，一切有可以引发一连更新（细致完成请细致看代码）。set有dict和intset（满是整数的时候运用它来存储）， sorted set有：skiplist和ziplist， hashtable完成有紧缩列表和dict和ziplist。skiplist就是跳表，它有接近于红黑树的效力，然则完成起来比红黑树简朴许多，所以被采纳（新鲜，这里又不造轮子了，岂非因为这个轮子有点难？）。 hash table可以运用dict完成，则改dict中，每一个dictentry中key保留了key（这是哈希表中的键值对的key），而value则保留了value，它们都是string。 而set中的dict，每一个dictentry中key保留了set中细致的一个元素的值，value则为null。图中的zset（有序鸠合）有误，zset运用skiplist和ziplist完成，起首skiplist很好明白，就把它当作红黑树的替代品就行，和红黑树一样，它也可以排序。如何用ziplist存储zset呢？起首在zset中，每一个set中的元素都有一个分值score，用它来排序。所以在ziplist中，依据分值大小，先存元素，再存它的score，再存下一个元素，然后score。如许一连存储，所以插进去也许删除的时候，都须要重新分派内存。所以当元素凌驾肯定数量，也许某个元素的字符数凌驾肯定数量，redis就会挑选运用skiplist来完成zset（假如当前运用的是ziplist，会将这个ziplist中的数据掏出，存入一个新的skiplist，然后删除改ziplist，这就是底层完成转换，其他范例的redis object也是可以转换的）。 别的，ziplist如何完成hashtable呢？实在也很简朴，就是存储一个key，存储一个value，再存储一个key，再存储一个value。照样递次存储，与zset完成相似，所以当元素凌驾肯定数量，也许某个元素的字符数凌驾肯定数量时，就会转换成hashtable来完成。种种底层完成体式格局是可以转换的，redis可以依据状况挑选最适宜的完成体式格局，这也是如许运用相似面向对象的完成体式格局的优点。
须要指出的是，运用skiplist来完成zset的时候，实在还用了一个dict，这个dict存储一样的键值对。为何呢？因为skiplist的查找只是lgn的（可以变成n），而dict可以到O(1)， 所以运用一个dict来加快查找，因为skiplist和dict可以指向一致个redis object，所以不会糟蹋太多内存。别的运用ziplist完成zset的时候，为何不必dict来加快查找呢？因为ziplist支撑的元素个数很少（个数多时就转换成skiplist了），递次遍历也很快，所以不必dict了。
如许看来，上面的dict，dictType，dictHt，dictEntry，redis object都是很有考量的，它们合营完成了一个具有面向对象颜色的天真、高效数据库。不得不说，redis数据库的设想照样很凶猛的。
与memcached差别的是，redis的数据库不止一个，默许就有16个，编号0-15。客户可以挑选运用哪一个数据库，默许运用0号数据库。 差别的数据库数据不同享，即在差别的数据库中可以存在一样的key，然则在一致个数据库中，key必需是唯一的。
redis也支撑expire time的设置，我们看上面的redis object，内里没有保留expire的字段，那redis如何纪录数据的expire time呢？ redis是为每一个数据库又增添了一个dict，这个dict叫expire dict，它内里的dict entry内里的key就是数对的key，而value满是数据为64位int的redis object，这个int就是expire time。如许，推断一个key是不是逾期的时候，去expire dict内里找到它，掏出expire time比对当前时候即可。为何如许做呢？ 因为并非一切的key都邑设置逾期时候，所以，关于不设置expire time的key来讲，保留一个expire time会糟蹋空间，而是用expire dict来零丁保留的话，可以依据须要天真运用内存（检测到key逾期时，会把它从expire dict中删除）。
redis的expire 机制是如何的呢？ 与memcahed相似，redis也是惰性删除，即要用到数据时，先搜检key是不是逾期，逾期则删除，然后返回毛病。纯真的靠惰性删除，上面说过可以会致使内存糟蹋，所以redis也有补充计划，redis内里有个定时实行的函数，叫servercron，它是保护效劳器的函数，在它内里，会对逾期数据举行删除，注重不是全删，而是在肯定的时候内，对每一个数据库的expire dict内里的数据随机选掏出来，假如逾期，则删除，不然再选，直到划定的时候到。即随机拔取逾期的数据删除，这个操纵的时候分两种，一种较长，一种较短，平常实行短时候的删除，每隔肯定的时候，实行一次长时候的删除。如许可以有用的减缓光采纳惰性删除而致使的内存糟蹋题目。
以上就是redis的数据的完成，与memcached差别，redis还支撑数据耐久化，这个下面引见。
4.redis数据库耐久化
redis和memcached的最大差别，就是redis支撑数据耐久化，这也是许多人挑选运用redis而不是memcached的最大缘由。 redis的耐久化，分为两种战略，用户可以设置运用差别的战略。
4.1 RDB耐久化 用户实行save也许bgsave的时候，就会触发RDB耐久化操纵。RDB耐久化操纵的中心头脑就是把数据库一成不变的保留在文件里。
那如何存储呢？以下图， 起首存储一个REDIS字符串，起到考证的作用，示意是RDB文件，然后保留redis的版本信息，然后是细致的数据库，然后存储完毕符EOF，末了用磨练和。症结就是databases，看它的名字也晓得，它存储了多个数据库，数据库依据编号递次存储，0号数据库存储完了，才轮到1，然后是2, 一向到末了一个数据库。
每一个数据库存储体式格局以下，起首一个1字节的常量SELECTDB，示意切换db了，然后下一个接上数据库的编号，它的长度是可变的，然后接下来就是细致的key-value对的数据了。
int rdbSaveKeyValuePair(rio *rdb, robj *key, robj *val,
long long expiretime, long long now)
{
/* Save the expire time */
if (expiretime != -1) {
/* If this key is already expired skip it */
if (expiretime < now) return 0;
if (rdbSaveType(rdb,REDIS_RDB_OPCODE_EXPIRETIME_MS) == -1) return -1;
if (rdbSaveMillisecondTime(rdb,expiretime) == -1) return -1;
}
/* Save type, key, value */
if (rdbSaveObjectType(rdb,val) == -1) return -1;
if (rdbSaveStringObject(rdb,key) == -1) return -1;
if (rdbSaveObject(rdb,val) == -1) return -1;
return 1;
}
由上面的代码也可以看出，存储的时候，先搜检expire time，假如已逾期，不存就好了，不然，则将expire time存下来，注重，及时是存储expire time，也是先存储它的范例为REDIS_RDB_OPCODE_EXPIRETIME_MS，然后再存储细致逾期时候。接下来存储真正的key-value对，起首存储value的范例，然后存储key（它依据字符串存储），然后存储value，以下图。
在rdbsaveobject中，会依据val的差别范例，依据差别的体式格局存储，不过从基础上来看，终究都是转换成字符串存储，比方val是一个linklist，那末先存储悉数list的字节数，然后遍历这个list，把数据掏出来，顺次依据string写入文件。关于hash table，也是先盘算字节数，然后顺次掏出hash table中的dictEntry，依据string的体式格局存储它的key和value，然后存储下一个dictEntry。 总之，RDB的存储体式格局，对一个key-value对，会先存储expire time（假若有的话），然后是value的范例，然后存储key（字符串体式格局），然后依据value的范例和底层完成体式格局，将value转换成字符串存储。这内里为了完成数据紧缩，以及可以依据文件恢复数据，redis运用了许多编码的技能，有些我也没太看懂，不过症结照样要明白头脑，不要在乎这些细节。
保留了RDB文件，当redis再启动的时候，就依据RDB文件来恢复数据库。因为以及在RDB文件中保留了数据库的号码，以及它包括的key-value对，以及每一个key-value对中value的细致范例，完成体式格局，和数据，redis只需递次读取文件，然后恢复object即可。因为保留了expire time，发明当前的时候已比expire time大了，即数据已超时了，则不恢复这个key-value对即可。
保留RDB文件是一个很庞大的工程，所以redis还供应背景保留的机制。即实行bgsave的时候，redis fork出一个子历程，让子历程来实行保留的事变，而父历程继续供应redis一般的数据库效劳。因为子历程复制了父历程的地点空间，即子历程具有父历程fork时的数据库，子历程实行save的操纵，把它从父历程那儿继续来的数据库写入一个temp文件即可。在子历程复制时期，redis会纪录数据库的修改次数（dirty）。当子历程完成时，发送给父历程SIGUSR1信号，父历程捕捉到这个信号，就晓得子历程完成了复制，然后父历程将子历程保留的temp文件改名为真正的rdb文件（即真正保留胜利了才改成目的文件，这才是保险的做法）。然后纪录下这一次save的完毕时候。
这里有一个题目，在子历程保留时期，父历程的数据库已被修改了，而父历程只是纪录了修改的次数（dirty），被没有举行修改操纵。好像使得RDB保留的不是及时的数据库，有点不太嵬峨上的模样。 不过背面要引见的AOF耐久化，就处理了这个题目。
除了客户实行sava也许bgsave敕令，还可以设置RDB保留前提。即在设置文件中设置，在t时候内，数据库被修改了dirty次，则举行背景保留。redis在serve cron的时候，会依据dirty数量和上次保留的时候，来推断是不是相符前提，相符前提的话，就举行bg save，注重，恣意时候只能有一个子历程来举行背景保留，因为保留是个很费io的操纵，多个历程大批io效力不可，而且不好治理。
4.2 AOF耐久化 起首想一个题目，保留数据库肯定须要像RDB那样把数据库内里的一切数据保留下来么？有无别的要领？
RDB保留的只是终究的数据库，它是一个效果。效果是如何来的？是经由历程用户的各个敕令竖立起来的，所以可以不保留效果，而只保留竖立这个效果的敕令。 redis的AOF就是这个头脑，它差别RDB保留db的数据，它保留的是一条一条竖立数据库的敕令。
我们起首来看AOF文件的花样，它内里保留的是一条一条的敕令，起首存储敕令长度，然后存储敕令，细致的分隔符什么的可以自身深入研讨，这都不是重点，横竖晓得AOF文件存储的是redis客户端实行的敕令即可。
redis server中有一个sds aof_buf, 假如aof耐久化翻开的话，每一个修改数据库的敕令都邑存入这个aof_buf（保留的是aof文件中敕令花样的字符串），然后event loop没轮回一次，在server cron中挪用flushaofbuf，把aof_buf中的敕令写入aof文件（现实上是write，真正写入的是内核缓冲区），再清空aof_buf，进入下一次loop。如许一切的数据库的变化，都可以经由历程aof文件中的敕令来复原，到达了保留数据库的效果。
须要注重的是，flushaofbuf中挪用的write，它只是把数据写入了内核缓冲区，真正写入文件时内核自身决议的，可以须要延后一段时候。 不过redis支撑设置，可以设置每次写入后sync，则在redis内里挪用sync，将内核中的数据写入文件，这不过这要消耗一次体系挪用，消耗时候罢了。还可以设置战略为1秒钟sync一次，则redis会开启一个背景线程（所以说redis不是单线程，只是单eventloop罢了），这个背景线程会每一秒挪用一次sync。这里要问了，RDB的时候为何没有斟酌sync的事变呢？因为RDB是一次性存储的，不像AOF如许屡次存储，RDB的时候挪用一次sync也没什么影响，而且运用bg save的时候，子历程会自身退出（exit），这时候候exit函数内会冲洗缓冲区，自动就写入了文件中。
再来看，假如不想运用aof_buf保留每次的修改敕令，也可以运用aof耐久化。redis供应aof_rewrite，即依据现有的数据库生成敕令，然后把敕令写入aof文件中。很奇异吧？对，就是这么凶猛。举行aof_rewrite的时候，redis变量每一个数据库，然后依据key-value对中value的细致范例，生成差别的敕令，比方是list，则它生成一个保留list的敕令，这个敕令里包括了保留该list所须要的的数据，假如这个list数据太长，还会分红多条敕令，先建立这个list，然后往list内里增添元素，总之，就是依据数据反向生成保留数据的敕令。然后将这些敕令存储aof文件，如许不就和aof append到达一样的效果了么？
再来看，aof花样也支撑背景形式。实行aof_bgrewrite的时候，也是fork一个子历程，然后让子历程举行aof_rewrite，把它复制的数据库写入一个临时文件，然后写完后用新号关照父历程。父历程推断子历程的退出信息是不是准确，然后将临时文件改名成终究的aof文件。好了，题目来了。在子历程耐久化时期，可以父历程的数据库有更新，如何把这个更新关照子历程呢？岂非要用历程间通讯么？是不是是有点贫苦呢？你猜redis如何做的？它基础不关照子历程。什么，不关照？那更新如何办？ 在子历程实行aof_bgrewrite时期，父历程会保留一切对数据库有变动的操纵的敕令（增，删除，改等），把他们保留在aof_rewrite_buf_blocks中，这是一个链表，每一个block都可以保留敕令，存不下时，新请求block，然后放入链表背面即可，当子历程关照完成保留后，父历程将aof_rewrite_buf_blocks的敕令append 进aof文件就可以够了。何等幽美的设想，想想自身当初还斟酌用历程间通讯，他人直接用最简朴的要领就圆满的处理了题目，有句话说得真对，越优异的设想越趋于简朴，而庞杂的东西每每都是靠不住的。
至于aof文件的载入，也就是一条一条的实行aof文件内里的敕令罢了。不过斟酌到这些敕令就是客户端发送给redis的敕令，所以redis痛快生成了一个假的客户端，它没有和redis竖立收集衔接，而是直接实行敕令即可。起首搞清楚，这里的假的客户端，并非真正的客户端，而是存储在redis内里的客户端的信息，内里有写和读的缓冲区，它是存在于redis效劳器中的。所以，以下图，直接读入aof的敕令，放入客户端的读缓冲区中，然后实行这个客户端的敕令即可。如许就完成了aof文件的载入。
// 建立伪客户端
fakeClient = createFakeClient();
while(敕令不为空) {
// 猎取一条敕令的参数信息 argc， argv
...
// 实行
fakeClient->argc = argc;
fakeClient->argv = argv;
cmd->proc(fakeClient);
}
悉数aof耐久化的设想，个人以为相称出色。其中有许多处所，值得敬拜。
5. redis的事件
redis另一个比memcached壮大的处所，是它支撑简朴的事件。事件简朴说就是把几个敕令兼并，一次性实行悉数敕令。关于关联型数据库来讲，事件另有回滚机制，即事件敕令要么悉数实行胜利，只需有一条失利就回滚，回到事件实行前的状况。redis不支撑回滚，它的事件只保证敕令顺次被实行，纵然中心一条敕令失足也会继续往下实行，所以说它只支撑简朴的事件。
起首看redis事件的实行历程。起首实行multi敕令，示意最先事件，然后输入须要实行的敕令，末了输入exec实行事件。 redis效劳器收到multi敕令后，会将对应的client的状况设置为REDIS_MULTI，示意client处于事件阶段，并在client的multiState组织体内里坚持事件的敕令细致信息（固然起首也会搜检敕令是不是可否辨认，毛病的敕令不会保留），即敕令的个数和细致的各个敕令，当收到exec敕令后，redis会递次实行multiState内里保留的敕令，然后保留每一个敕令的返回值，当有敕令发作毛病的时候，redis不会住手事件，而是保留毛病信息，然后继续往下实行，当一切的敕令都实行完后，将一切敕令的返回值一同返回给客户。redis为何不支撑回滚呢？网上看到的诠释涌现题目是因为客户顺序的题目，所以没必要效劳器回滚，同时，不支撑回滚，redis效劳器的运转高效许多。在我看来，redis的事件不是传统关联型数据库的事件，请求CIAD那末异常严厉，也许说redis的事件都不是事件，只是供应了一种体式格局，使得客户端可以一次性实行多条敕令罢了，就把事件当作一般敕令就好了，支撑回滚也就没必要了。
我们晓得redis是单event loop的，在真正实行一个事物的时候（即redis收到exec敕令后），事物的实行历程是不会被打断的，一切敕令都邑在一个event loop中实行完。然则在用户逐一输入事件的敕令的时候，这时期，可以已有别的客户修改了事件内里用到的数据，这就可以发作题目。所以redis还供应了watch敕令，用户可以在输入multi之前，实行watch敕令，指定须要视察的数据，如许假如在exec之前，有其他的客户端修改了这些被watch的数据，则exec的时候，实行到处置惩罚被修改的数据的敕令的时候，会实行失利，提醒数据已dirty。 这是如何是完成的呢？ 本来在每一个redisDb中另有一个dict watched_keys，watched_kesy中dictentry的key是被watch的数据库的key，而value则是一个list，内里存储的是watch它的client。同时，每一个client也有一个watched_keys，内里保留的是这个client当前watch的key。在实行watch的时候，redis在对应的数据库的watched_keys中找到这个key（假如没有，则新建一个dictentry），然后在它的客户列表中到场这个client，同时，往这个client的watched_keys中到场这个key。当有客户实行一个敕令修改数据的时候，redis起首在watched_keys中找这个key，假如发明有它，证实有client在watch它，则遍历一切watch它的client，将这些client设置为REDIS_DIRTY_CAS，外表有watch的key被dirty了。当客户实行的事件的时候，起首会搜检是不是被设置了REDIS_DIRTY_CAS，假如是，则表明数据dirty了，事件没法实行，会马上返回毛病，只需client没有被设置REDIS_DIRTY_CAS的时候才够实行事件。 须要指出的是，实行exec后，该client的一切watch的key都邑被消灭，同时db中该key的client列表也会消灭该client，即实行exec后，该client不再watch任何key（纵然exec没有实行胜利也是一样）。所以说redis的事件是简朴的事件，算不上真正的事件。
以上就是redis的事件，觉得完成很简朴，现实用途也不是太大。
6. redis的宣布定阅频道
redis支撑频道，即到场一个频道的用户相称于到场了一个群，客户往频道内里发的信息，频道里的一切client都能收到。
完成也很简朴，也watch_keys完成差不多，redis server中保留了一个pubsub_channels的dict，内里的key是频道的称号（明显要唯一了），value则是一个链表，保留到场了该频道的client。同时，每一个client都有一个pubsub_channels，保留了自身关注的频道。当用用户往频道发音讯的时候，起首在server中的pubsub_channels找到改频道，然后遍历client，给他们发音讯。而定阅，作废定阅频道不够都是操纵pubsub_channels罢了，很好明白。
同时，redis还支撑形式频道。即经由历程正则婚配频道，若有形式频道p, 1, 则向一般频道p1发送音讯时，会婚配p，1，除了往一般频道发音讯外，还会往p，1形式频道中的client发音讯。注重，这里是用宣布敕令内里的一般频道来婚配已有的形式频道，而不是在宣布敕令里制订形式频道，然后婚配redis内里保留的频道。完成体式格局也很简朴，在redis server内里有个pubsub_patterns的list（这里为何不必dict？因为pubsub_patterns的个数平常较少，不须要运用dict，简朴的list就好了），它内里存储的是pubsubPattern组织体，内里是形式和client信息，以下所示，一个形式，一个client，所以假若有多个clint监听一个pubsub_patterns的话，在list面会有多个pubsubPattern，保留client和pubsub_patterns的对应关联。 同时，在client内里，也有一个pubsub_patterns list，不过内里存储的就是它监听的pubsub_patterns的列表（就是sds），而不是pubsubPattern组织体。
typedef struct pubsubPattern {
redisClient *client; // 监听的client
robj *pattern; // 形式
} pubsubPattern;
当用户往一个频道发送音讯的时候，起首会在redis server中的pubsub_channels内里查找该频道，然后往它的客户列表发送音讯。然后在redis server内里的pubsub_patterns内里查找婚配的形式，然后往client内里发送音讯。 这里并没有去除反复的客户，在pubsub_channels可以已给某一个client发过message了，然后在pubsub_patterns中可以还会给用户再发一次（以至更屡次）。 预计redis以为这是客户顺序自身的题目，所以不处置惩罚。
/* Publish a message */
int pubsubPublishMessage(robj *channel, robj *message) {
int receivers = 0;
dictEntry *de;
listNode *ln;
listIter li;
/* Send to clients listening for that channel */
de = dictFind(server.pubsub_channels,channel);
if (de) {
list *list = dictGetVal(de);
listNode *ln;
listIter li;
listRewind(list,&li);
while ((ln = listNext(&li)) != NULL) {
redisClient *c = ln->value;
addReply(c,shared.mbulkhdr[3]);
addReply(c,shared.messagebulk);
addReplyBulk(c,channel);
addReplyBulk(c,message);
receivers++;
}
}
/* Send to clients listening to matching channels */
if (listLength(server.pubsub_patterns)) {
listRewind(server.pubsub_patterns,&li);
channel = getDecodedObject(channel);
while ((ln = listNext(&li)) != NULL) {
pubsubPattern *pat = ln->value;
if (stringmatchlen((char*)pat->pattern->ptr,
sdslen(pat->pattern->ptr),
(char*)channel->ptr,
sdslen(channel->ptr),0)) {
addReply(pat->client,shared.mbulkhdr[4]);
addReply(pat->client,shared.pmessagebulk);
addReplyBulk(pat->client,pat->pattern);
addReplyBulk(pat->client,channel);
addReplyBulk(pat->client,message);
receivers++;
}
}
decrRefCount(channel);
}
return receivers;
}
六. 总结
总的来看，redis比memcached的功用多许多，完成也更庞杂。 不过memcached更专注于保留key-value数据（这已能满足大多数运用场景了），而redis供应更雄厚的数据组织及其他的一些功用。不能说redis比memcached好，不过从源码浏览的角度来看，redis的代价也许更大一点。 别的，redis3.0内里支撑了集群功用，这部份的代码还没有研讨，后续再跟进。
以上就是Redis与Memcached有何辨别 ？redis和Memcached的辨别比较的细致内容，更多请关注ki4网别的相干文章！
