john_zzl的专栏

#define AE_SETSIZE (1024*10)    /* Max number of fd supported */redis的网络模型处理的fd必须小于2048（在events结构体中放不下）；/* State of an event based program */ typedef struct aeEventLoop {    int maxfd;    lo

aeCreateFileEvent(server.el, server.io_ready_pipe_read, AE_READABLE, vmThreadedIOCompletedJob, NULL)主线程和后台线程通过pipe进行通信：    后台线程每处理完一个job，就会给server.io_ready_pipe_write发送一个字节数据；    主线程监听server

redis的dict是自动rehash的hash表，为了平衡性能，rehash不是一次做完的，而是分散到每次交互操作来做；typedef struct dictEntry {    void *key;    void *val;    struct dictEntry *next;} dictEntry;typedef struct dictType {

intset结构体：typedef struct intset {    uint32_t encoding;    uint32_t length;    int8_t contents[];} intset;encoding保存编码方式：INTSET_ENC_INT16、INTSET_ENC_INT32和INTSET_ENC_INT64；length保存元素个数

zipmap是用连续内存保存key,value对的结构；因为是连续内存保存的，所以每次插入或删除操作都可能会导致重新分配内存；为了缓解重新分配内存压力，为每个value保留一个free字段，表明可用空闲字节数（4）；存储结构："foo""bar""hello""world"zmlen表示key,value对数目，如果该数目大于或等于254，得遍历整个map才能得

本文剖析redis的ziplist的实现。ziplist是一个存储高效的双链表，存储的元素类型有字符串和整数；虽然存储高效，但每次插入或删除ziplist中的元素都会引起重新分配内存，所以，ziplist作为大型只读表非常高效，频繁的插入或删除ziplist不太合适；ziplist的内部结构：zlbytes是一个unsigned int数字，表示整个ziplist占用的

bio开线程来执行close和fdatasync操作；采用的是job list方式（每个线程一个job list，线程从job list取job执行），也就是生产者-消费者模型；

aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL);aeCreateFileEvent(server.el,server.ipfd,AE_READABLE,acceptTcpHandler,NULL);acceptTcpHandler每accept到一个clientfd，会为该fd调用createClient（有maxclient

void readQueryFromClient(aeEventLoop *el, int fd, void *privdata, int mask)读数据到redisClient::querybuf；读到数据超过client_max_querybuf_len时，直接freeClient(c)；processInputBuffer(c);1、输入以*开头，则reqtype为REDI

B树       即二叉搜索树：       1.所有非叶子结点至多拥有两个儿子（Left和Right）；       2.所有结点存储一个关键字；       3.非叶子结点的左指针指向小于其关键字的子树，右指针指向大于其关键字的子树；       如：              B树的搜索，从根结点开始，如果查询的关键字与结点的关