qq_62309585的博客

通过encoding属性来设定对象所使用的编码，而不是为特定类型的对象关联一种固定的编码，极大地提升了Redis的灵活性和效率，因为Redis可以根据不同的使用场景来为一个对象设置不同的编码，从而优化对象在某一场景下的效率

结构是指在一个系统或者材料之中，互相关联的元素的排列、组织。结构按类别可分为等级结构（有层次的一对多）、网格结构（多对多）、晶格结构（临近的个体互相连接）等。

压缩列表（ziplist）是列表键和哈希键的底层实现之一。列表键里面包含的都是1、3、5、10086这样的小整数值，以 及"hello"、"world"这样的短字符串。另外，当一个哈希键只包含少量键值对，比且每个键值对的键和值 要么就是小整数值，要么就是长度比较短的字符串，那么Redis就会使 用压缩列表来做哈希键的底层实现。

redis的整数集合 升级 降级

跳跃表是有序集合的底层实现之一。·Redis的跳跃表实现由zskiplist和zskiplistNode两个结构组成，其中zskiplist用于保存跳跃表信息（比如表头节点、表尾节点、长度），而zskiplistNode则用于表示跳跃表节点。·每个跳跃表节点的层高都是1至32之间的随机数。·在同一个跳跃表中，多个节点可以包含相同的分值，但每个节点的成员对象必须是唯一的。·跳跃表中的节点按照分值大小进行排序，当分值相同时，节点按照成员对象的大小进行排序。

·字典被广泛用于实现Redis的各种功能，其中包括数据库和哈希键。·Redis中的字典使用哈希表作为底层实现，每个字典带有两个哈希 表，一个平时使用，另一个仅在进行rehash时使用。·当字典被用作数据库的底层实现，或者哈希键的底层实现时， Redis使用MurmurHash2算法来计算键的哈希值。·哈希表使用链地址法来解决键冲突，被分配到同一个索引上的多 个键值对会连接成一个单向链表。·在对哈希表进行扩展或者收缩操作时，程序需要将现有哈希表包 含的所有键值对rehash到新哈希表里面，并且

双端：链表节点带有prev和next指针，获取某个节点的前置节点和 后置节点的复杂度都是（1）。·无环：表头节点的prev指针和表尾节点的next指针都指向NULL， 对链表的访问以NULL为终点。·带表头指针和表尾指针：通过list结构的head指针和tail指针，程序获取链表的表头节点和表尾节点的复杂度为O（1）。·带链表长度计数器：程序使用list结构的len属性来对list持有的链表 节点进行计数，程序获取链表中节点数量的复杂度为O（1）。

Redis没有直接使用C语言传统的字符串表示（以空字符结尾的字符 数组，以下简称C字符串），而是自己构建了一种名为简单动态字符串 （simple dynamic string，SDS）的抽象类型，并将SDS用作Redis的默认 字符串表示C字符串只会作为字符串字面量（string literal）用在 一些无须对字符串值进行修改的地方sds1.当Redis需要的不仅仅是一个字符串字面量，而是一个可以被修改 的字符串值时，Redis就会使用SDS来表示字符串值那么Redis将在数据库中创建一个

在sql中，必须定义好地段和表结构之后，才能够添加数据，例如定义表的主键、索引、外键等。表结构可以在定义之后更新，但是如果有比较大的结构变更，就会变的比较复杂。在Nosql数据库中，数据可以在任何时候任何地方添加。不需要预先定义。

通常， 在启动upstream时， 我们将决定以何种方式处理上游响应的包体， 前文说过， 我们会原封不动地转发百度的响应包体到客户端， 这一行为是由ngx_http_request_t结构体中的subrequest_in_memory标志位决定的， 默认情况subrequest_in_memory为0， 即表示将转发上游的包体到下游。这两个方法也是通用的， 它们适用于解析所有的HTTP响应包， 而且这个方法的代码ngx_http_proxy_module模块的实现几乎是完全一致的。

1.Unix使用了四种和文件系统相关的传统抽象概念:文件、目录项、索引节点和安装点( mount point)。从本质上讲文件系统是特殊的数据分层存储结构，它包含文件、目录和相关的控制信息。文件系统的通用操作包含创建、删除和安装等。2.在 Unix中，文件系统被安装在一个特定的安装点上该安装点在全局层次结构中被称作命名空间，所有的已安装文件系统都作为根文件系统树的枝叶出现在系统中。3.文件：文件其实可以做一个有序字节串，字节串中第一个字节是文件的头，最后一个字节是文件的尾。

process_header可能会被多次调用， 它的调用次数与process_header的返回值有关如果process_header返回NGX_AGAIN， 这意味着还没有接收到完整的响应头部， 如果再次接收到上游服务器发来的TCP流， 还会把它当做头部， 仍然调用process_header处理，而在下图中， 如果process_header返回NGX_OK（ 或者其他非NGX_AGAIN的值） ， 那么在这次连接的后续处理中将不会再次调用process_header。

4） 在http模块中， 调用ngx_http_upstream_init方法即可启动upstream机制。注意，自己的模板回调方法此时必须返回NGX_DONE，

1.简单地讲， 就是在一个请求的处理过程中，

可以看到， 如果只是想把相应的信息记录到日志文件中， 那么完全不需要关心ngx_log_t类型的log参数是如何构造的。特别是在编写HTTP模块时， HTTP框架要求所有的HTTP模块都使用它提供的log， 如果重定义ngx_log_t中的handler方法， 或者修改data指向的地址， 那么很可能会造成一系列问题。

在开发功能灵活的Nginx模块时，需要从配置文件中获取特定的信息，不过，不需要再 编写一套读取配置的系统，Nginx已经为用户提供了强大的配置项解析机制，同时它还支持“- s reload”命令——在不重启服务的情况下可使配置生效例子：总体解析:1.test_str这个配置项在http块内出现的值为main，在监听80端口的 server块内test_str值为server80，该server块内有两个location由mytest模块处理的且每个location中又重新设置了test_str的值，分

例子：参数解析：1.参数conf就是HTTP框架传给用户的在ngx_http_mytest_create_loc_conf回调方法中分配的结构体ngx_http_mytest_conf_t（相当一座桥梁）2.cf->args是1个ngx_array_t队列，它的成员都是ngx_str_t结构。我们用value指向ngx_array_t的elts内容，其中value[1]就是第1个参数，同理，value[2]是第2个参数 （int main（char*arg....））

ngx_conf_set_path_slot

因为HTTP框架可以使用预设的14种方法自动 地将解析出的配置项写入HTTP模块代码定义的结构体中，但HTTP模块中可能会定义3个结 构体，分别用于存储main、srv、loc级别的配置项（对应于create_main_conf、 create_srv_conf、create_loc_conf方法创建的结构体），如果需要在解析完配置项后回调某个方法，就要实现 上面的ngx_conf_post_handler_pt，并将包含post_handler的ngx_conf_post_t结构体传给post指 针。

发送文件时完全可以先把 文件读取到内存中再向用户发送数据，但是这样做会有两个缺点：·为了不阻塞Nginx，每次只能读取并发送磁盘中的少量数据，需要反复持续多次。·Linux上高效的sendfile系统调用不需要先把磁盘中的数据读取到用户态内存再发送到 网络中note:1.fd是打开文件的句柄描述符，打开文件这一步需要用户自己来做。Nginx简单封装了一个宏用来代替open系统的调用。