nginx源码阅读
‘壹’ 为什么说学习计算机首先要学会“抽象”
学计算机的过程，是一个从抽象到具体的过程，等将一切具象化以后，再重新理解抽象，将得到前所未有的酣畅。
以HTTP协议为例
抽象过程学习
在学HTTP协议的时候，很多人都是从“文字描述”（书本或者文章）开始，顶多是配合一些实践，例如：如何发送一个HTTP请求，如何接受一个HTTP请求。当具有这些知识以后，再加上这个世界HTTP相关的轮子太多了，大部分情况下不需要我们亲自去造。
客户端想用一个网络框架，找找开源的，发现有一堆：Apache的HTTPClient、Square的OKHTTP，就算没有，一些语言的系统库也提供的一些基本的封装（例如Java的HttpURLConnection）
服务端要用搭建一个简单的web站点，找找开源的HTTP服务器，也是有不少：Apache、Nginx、Tomcat等
经过一些实践之后，对HTTP这个协议里面包含的一些内容肯定有比较宽的了解，知道了如下内容：
URIs/URLs/URNs，
HTTP Request，并且知道HTTP Request里面包含请求起始行（Request start line）、请求头（Request Headers）和请求体（Request Bodys）；请求起始行里面又包含HTTP Method（GET POST PUT等），HTTP协议版本等
HTTP Respone，并且知道HTTP Response里面包含响应起始行（Response start line）、响应头（Response Headers）和响应体（Response Bodys）；响应起始行里面包含响应状态码，常用的状态码有200、304、404、500、502等
- In telecommunication, a communication protocol is a system of rules that allow two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. The protocol defines the rules syntax,semantics and synchronization of communication and possible error recovery methods. Protocols may be implemented by hardware,software, or a combination of both.[1]
具象过程学习
如果HTTP协议学到此处，那么还只是停留在表象（抽象层），当被问及一些稍微深的问题或者进行操刀HTTP通信方面优化时，依然无从作答或者无法下手。
你可以通过以下问题（都是各大公司经典的面试题），检测下自己对HTTP协议（网络知识）的理解程度：
1. get和post方法的区别？
我想这个问题的答案有一定了解的你能回答出如下重要的两点：
（1）get用于获取数据，post用于提交数据
（2）get不安全，post相对来说安全
那再问更深一点，get能用于提交数据吗？为什么？
post能用于获取数据吗？为什么？
post提交的数据放在哪儿？
你觉得这个两种请求的方法，哪一种更高效，还是说效率上没有差别，为什么？
2. 当在浏览器地址栏键入：http://www.taobao.com，回车之后，后续发生了哪些事情？
3. 如果让你着手进行一些网络优化，你会从哪些方面入手？
我很喜欢的一种学习方式，就是问题式学习，这是符合客观规律。我们每天学的东西，做的事情，往大了看，不都是为了解决问题嘛。
通过对以上问题的思考和研究，我们一定会得出以下具象的结论：
1. HTTP协议，这个词，大部分人只是把焦点放在了“HTTP”上，而忘记了另外一个关键词“协议”。协议是什么？
Wikipedia的核心定义如下：
精简就是：协议就是规则，通信领域也是如此。
HTTP协议就是一套规则，大家都是按照这套规则来通信。
如果我和你对话，我用这套规则问你话，你没有遵循这套规则，你将听不懂，我也收不到回应，就这么简单。
客户端那些开源的HTTP网络框架和服务端所使用的HTTP服务器，就是用计算机编程语言按照这套规则来实现的软件，我们用这套软件间接用HTTP通信，我们也可以直接用HTTP协议来，但是太麻烦了。
2. HTTP协议是应用层协议，建立在传输层之上，依赖操作系统的套接字接口。研读一下HTTP网络框架的源码或者HTTP服务器源码便可得知（我研读的是OKHTTP）。如果你觉得没有亲眼看到TCP/IP的影子，你再看看linux关于socket的源码，底层用的就是TCP/IP。
通过以上深入的思考、理论学习、源码阅读，我想我们已经进入到了HTTP具象的世界：他是一套规范，最终他被表达的方式就是代码，然后提供给成千上万的开发者去使用。
再抽象过程学习
当进入具象的世界之后，我们再回过头来想想，为什么网络世界有那么多协议，为什么要有经典TCP/IP四层经典模型？ 一个协议不行吗？
行。可是很麻烦。为了简单，为了使用方便，大师们进行了层层抽象。而抽象是计算机领域一个非常重要的本质。
还记得曾经看到过一句话：计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。这句话反应的便是这个“抽象”二字的神奇功效！
我的HTTP学习方法参考
主要阅读的书籍是：《图解HTTP》（入门用） 《HTTP权威指南》（进阶，知识点细化）《TCP/IP详解》
实践：编写客户端程序和服务器程序，通过HTTP通信
源码阅读（任意选一个大众常用的软件即可）
‘贰’ 如何解决Nginx服务自动关闭问题
首先排除是否为网络问题：检查了iptable等。同时思考，如果真的是网络问题，不应该运行一段时间后，才出现无法接受新连接的现象。
为了验证，当出现问题时，我又重新启动Nginx，发现又可以接收新的请求了。也就是说出现问题时，只需要重启Nginx就可以解决，那么自然不是网络因素。
判定是否是Nginx本身的问题（不一定是指代码包括我写的配置文件）：因为这个代理服务器是为了测试fastsocket项目的稳定性，所以 Nginx是加载了fastsocket优化服务的。这时，就需要最纯粹的Nginx环境。我去掉了fastsocket服务，然后再用同样的配置启动 Nginx。这时，就排除了Nginx本身的问题。那么，究竟是否是fastsocket的bug呢？
这里先做一个小广告： fastsocket是新浪主导的一个开源项目，其通过封装socket套接字调用，无需改动服务程序，即可大幅提升服务程序性能。作者也是其中的维护者之一。这里小小推广一下：https://github.com/fastos/fastsocket。当使用fastsocket默认加载参数时，nginx运行一段时间就无法接受新连接请求了。
定位fastsocket问题：fastsocket的大部分优化功能都是有功能开关的，默认会使用一些功能，同时可以在加载动态模块时，使用参数指定是否打开开关。这时，先做实验，从所有功能关闭开始，逐渐打开功能开关，最后定位到enable_listen_spawn功能打开时，就会出现问题。并多次做实验，确定这是一个必现的问题。
当确定可以重现后，想这难道是一个fastsocket的bug吗？于是，先跟林晓峰同学说了一声，告诉他我的发现，毕竟fastsocket是他在sina时的工作，他最为熟悉代码。他说这可能是Nginx的配置使用了accept_mutex。我的配置文件虽然没有配置accept_mutex，但是没想到Nginx的accept_mutex是默认打开的。但是他忘了为什么会这样了？依稀记得是Nginx hang在了mutex中，具体原因记不清了。所以fastsocket的说明也是要求disable accept_mutex。
因为我一直以来有这还不错的求知欲，所以一定要搞清楚这个问题。同时我认为，如果真的是一启用accept_mutex，fastsocket和nginx就会有兼容问题，那也应该算是fastsocket的bug，应该将其解决掉。
定位Nginx hang在什么位置：这个很简单，使用strace -p跟踪Nginx的每个worer进程。发现大部分worker进程是在不断的epoll_wait，而其中一个worker进程，始终停留在epoll_wait中。重试多次，每次都是停留在epoll_wait中。
现在已经确定了本次问题，当使用fastsocket的enable_listen_spawn功能时，也就是fastsocket自动为当前CPU创建本地的listen socket套接字时，就会出现问题。
解决问题
当定位到问题时，就需要一步一步的找到原因，查看为什么一个worker进程始终停留在epoll_wait中。这时候，其实思考还是要优于动手。先思考，再动手，动手之后，看到结果，再做进一步思考。
查看该worker进程停留在epoll_wait的什么位置：只能通过日志形式来判断hang在epoll_wait的哪个位置？这时，不能用内核普通的printk来打印日志，不然就会淹没于大量正常工作worker进程打印的日志中。我们需要根据pid来打印日志。
再做一个小广告：我做了一个内核小工具[email protected]:gfreewind/unit_perf.git。是用来定位内核代码的性能瓶颈工具，和一些辅助工具。大家觉得还可以的话，就给赞个星星。
它提供一个宏UP_PID_INFO_LOG用于打印指定PID的日志，pid可以通过proc来指定。
这样我在epoll_wait中增加了大量的日志。在Nginx启动后，通过proc指定就打印某个worker进程的日志。
最后发现epoll_wait是因为指定了无限等待时间，所以该worker进程一直在hang住。
Nginx让一个worker进程无限等待，这稍微颠覆了我对Nginx的认识。我认为Nginx一直都是使用无阻塞的系统调用，至少核心模块是这样处理的。那么为什么会出现这个现象呢？这时候，就需要思考，而不是动手了。
毫无疑问，accept_mutex是一个关键。它本身是用于均衡不同worker进程的负载。稍微阅读一点Nginx相关的 代码，就可以明白。在Nginx无法接收新连接请求时，一定是该轮到hang住的进程接收新连接请求。所以尽管其它进程没有hang住，但是它们是无法接 受新请求，而能够接收新请求的进程却hang住，这样就导致了问题的产生。
为什么hang住的进程无法接收到新的请求呢？这时还是思考优先。首先要勾画标准的内核TCP连接的过程，然后对比启用fastsocket 后，TCP连接的过程。很可能是这两者之间的区别，造成了问题。尤其是启用了spawn socket时，与标准流程的不同。spawn socket时，实际上为每个cpu都创建了一个本地listen 套接字的hash表，与全局的listen表区分开。这样一方面访问全局hash表时需要的锁，另一方面也做到了将TCP会话做到本地，可以尽量命中 cache。 对于同一个CPU，由于有两个listen表的存在，所以在收到新的TCP连接请求时，必须先检查本地的listen表，然后再检查全局表。 根据这样的流程和现象，应该是所有的连接请求，都被发到其它的CPU，并且匹配中了其它CPU的本地listen表，所以全局表中的listen socket套接字一直没有被匹配到。
那么hang住的进程，既没有连接请求匹配本地listen表中的套接字，而全局表也一样，因为被请求都被其它CPU命中了本地的套接字。
所以问题更为明朗了，hang住的进程所在的CPU不能收到任何新连接请求。
这时其实已经到了冲刺的时候了。开始的时候，我还想着，是否是fastsocket影响了数据包的分发，还想检查一下代码。但一想，还是先看看 RPS的设置吧——虽然我没有设置网卡的任何RPS。结果出乎我意料，原来阿里云ECS服务器默认就把网卡的RPS设置了，唯一的外网网卡的RPS设置为 了0000，所以只有CPU 0能收到新连接请求，而另外的CPU1收不到任何的连接请求，这就造成了运行在CPU1上的worker进程hang住。
最后我修改了该网卡的RPS设置，使其可以将数据包分发到不同的CPU上。这样在加载了fastsocket后，即使打开了accept_mutex，Nginx也可以正常工作了。
本次过程，虽然最后发现只是服务器配置的问题，但整个儿过程还是收获不少。唯一的遗憾，是还没有定位Nginx对与epoll_wait的超时计算。开始的时候，都是500ms，后面因为什么因素变成了无限。这留到有时间的时候，再阅读Nginx源码吧。
‘叁’ 面试必问的epoll技术，从内核源码出发彻底搞懂epoll
epoll是linux中IO多路复用的一种机制，I/O多路复用就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。当然linux中IO多路复用不仅仅是epoll，其他多路复用机制还有select、poll，但是接下来介绍epoll的内核实现。
events可以是以下几个宏的集合：
epoll相比select/poll的优势 ：
epoll相关的内核代码在fs/eventpoll.c文件中，下面分别分析epoll_create、epoll_ctl和epoll_wait三个函数在内核中的实现，分析所用linux内核源码为4.1.2版本。
epoll_create用于创建一个epoll的句柄，其在内核的系统实现如下：
sys_epoll_create:
可见，我们在调用epoll_create时，传入的size参数，仅仅是用来判断是否小于等于0，之后再也没有其他用处。
整个函数就3行代码，真正的工作还是放在sys_epoll_create1函数中。
sys_epoll_create -> sys_epoll_create1:
sys_epoll_create1 函数流程如下：
sys_epoll_create -> sys_epoll_create1 -> ep_alloc:
sys_epoll_create -> sys_epoll_create1 -> ep_alloc -> get_unused_fd_flags:
linux内核中，current是个宏，返回的是一个task_struct结构（我们称之为进程描述符）的变量，表示的是当前进程，进程打开的文件资源保存在进程描述符的files成员里面，所以current->files返回的当前进程打开的文件资源。rlimit(RLIMIT_NOFILE) 函数获取的是当前进程可以打开的最大文件描述符数，这个值可以设置，默认是1024。
相关视频推荐：
支撑亿级io的底层基石 epoll实战揭秘
网络原理tcp/udp，网络编程epoll/reactor，面试中正经“八股文”
学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂
需要更多C/C++ Linux服务器架构师学习资料加群 812855908 获取（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，Mysql，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享
__alloc_fd的工作是为进程在[start,end)之间(备注：这里start为0， end为进程可以打开的最大文件描述符数)分配一个可用的文件描述符,这里就不继续深入下去了，代码如下：
sys_epoll_create -> sys_epoll_create1 -> ep_alloc -> get_unused_fd_flags -> __alloc_fd:
然后，epoll_create1会调用anon_inode_getfile，创建一个file结构，如下：
sys_epoll_create -> sys_epoll_create1 -> anon_inode_getfile:
anon_inode_getfile函数中首先会alloc一个file结构和一个dentry结构，然后将该file结构与一个匿名inode节点anon_inode_inode挂钩在一起，这里要注意的是，在调用anon_inode_getfile函数申请file结构时，传入了前面申请的eventpoll结构的ep变量，申请的file->private_data会指向这个ep变量，同时，在anon_inode_getfile函数返回来后，ep->file会指向该函数申请的file结构变量。
简要说一下file/dentry/inode，当进程打开一个文件时，内核就会为该进程分配一个file结构，表示打开的文件在进程的上下文，然后应用程序会通过一个int类型的文件描述符来访问这个结构，实际上内核的进程里面维护一个file结构的数组，而文件描述符就是相应的file结构在数组中的下标。
dentry结构（称之为“目录项”）记录着文件的各种属性，比如文件名、访问权限等，每个文件都只有一个dentry结构，然后一个进程可以多次打开一个文件，多个进程也可以打开同一个文件，这些情况，内核都会申请多个file结构，建立多个文件上下文。但是，对同一个文件来说，无论打开多少次，内核只会为该文件分配一个dentry。所以，file结构与dentry结构的关系是多对一的。
同时，每个文件除了有一个dentry目录项结构外，还有一个索引节点inode结构，里面记录文件在存储介质上的位置和分布等信息，每个文件在内核中只分配一个inode。 dentry与inode描述的目标是不同的，一个文件可能会有好几个文件名（比如链接文件），通过不同文件名访问同一个文件的权限也可能不同。dentry文件所代表的是逻辑意义上的文件，记录的是其逻辑上的属性，而inode结构所代表的是其物理意义上的文件，记录的是其物理上的属性。dentry与inode结构的关系是多对一的关系。
sys_epoll_create -> sys_epoll_create1 -> fd_install:
总结epoll_create函数所做的事：调用epoll_create后，在内核中分配一个eventpoll结构和代表epoll文件的file结构，并且将这两个结构关联在一块，同时，返回一个也与file结构相关联的epoll文件描述符fd。当应用程序操作epoll时，需要传入一个epoll文件描述符fd，内核根据这个fd，找到epoll的file结构，然后通过file，获取之前epoll_create申请eventpoll结构变量，epoll相关的重要信息都存储在这个结构里面。接下来，所有epoll接口函数的操作，都是在eventpoll结构变量上进行的。
所以，epoll_create的作用就是为进程在内核中建立一个从epoll文件描述符到eventpoll结构变量的通道。
epoll_ctl接口的作用是添加/修改/删除文件的监听事件，内核代码如下：
sys_epoll_ctl:
根据前面对epoll_ctl接口的介绍，op是对epoll操作的动作（添加/修改/删除事件），ep_op_has_event(op)判断是否不是删除操作，如果op != EPOLL_CTL_DEL为true，则需要调用_from_user函数将用户空间传过来的event事件拷贝到内核的epds变量中。因为，只有删除操作，内核不需要使用进程传入的event事件。
接着连续调用两次fdget分别获取epoll文件和被监听文件（以下称为目标文件）的file结构变量（备注：该函数返回fd结构变量，fd结构包含file结构）。
接下来就是对参数的一些检查，出现如下情况，就可以认为传入的参数有问题，直接返回出错：
当然下面还有一些关于操作动作如果是添加操作的判断，这里不做解释，比较简单，自行阅读。
在ep里面，维护着一个红黑树，每次添加注册事件时，都会申请一个epitem结构的变量表示事件的监听项，然后插入ep的红黑树里面。在epoll_ctl里面，会调用ep_find函数从ep的红黑树里面查找目标文件表示的监听项，返回的监听项可能为空。
接下来switch这块区域的代码就是整个epoll_ctl函数的核心，对op进行switch出来的有添加(EPOLL_CTL_ADD)、删除(EPOLL_CTL_DEL)和修改(EPOLL_CTL_MOD)三种情况，这里我以添加为例讲解，其他两种情况类似，知道了如何添加监听事件，其他删除和修改监听事件都可以举一反三。
为目标文件添加监控事件时，首先要保证当前ep里面还没有对该目标文件进行监听，如果存在(epi不为空)，就返回-EEXIST错误。否则说明参数正常，然后先默认设置对目标文件的POLLERR和POLLHUP监听事件，然后调用ep_insert函数，将对目标文件的监听事件插入到ep维护的红黑树里面：
sys_epoll_ctl -> ep_insert:
前面说过，对目标文件的监听是由一个epitem结构的监听项变量维护的，所以在ep_insert函数里面，首先调用kmem_cache_alloc函数，从slab分配器里面分配一个epitem结构监听项，然后对该结构进行初始化，这里也没有什么好说的。我们接下来看ep_item_poll这个函数调用：
sys_epoll_ctl -> ep_insert -> ep_item_poll:
ep_item_poll函数里面，调用目标文件的poll函数，这个函数针对不同的目标文件而指向不同的函数，如果目标文件为套接字的话，这个poll就指向sock_poll，而如果目标文件为tcp套接字来说，这个poll就是tcp_poll函数。虽然poll指向的函数可能会不同，但是其作用都是一样的，就是获取目标文件当前产生的事件位，并且将监听项绑定到目标文件的poll钩子里面（最重要的是注册ep_ptable_queue_proc这个poll callback回调函数），这步操作完成后，以后目标文件产生事件就会调用ep_ptable_queue_proc回调函数。
接下来，调用list_add_tail_rcu将当前监听项添加到目标文件的f_ep_links链表里面，该链表是目标文件的epoll钩子链表，所有对该目标文件进行监听的监听项都会加入到该链表里面。
然后就是调用ep_rbtree_insert，将epi监听项添加到ep维护的红黑树里面,这里不做解释，代码如下：
sys_epoll_ctl -> ep_insert -> ep_rbtree_insert:
前面提到，ep_insert有调用ep_item_poll去获取目标文件产生的事件位，在调用epoll_ctl前这段时间，可能会产生相关进程需要监听的事件，如果有监听的事件产生，(revents & event->events 为 true)，并且目标文件相关的监听项没有链接到ep的准备链表rdlist里面的话，就将该监听项添加到ep的rdlist准备链表里面，rdlist链接的是该epoll描述符监听的所有已经就绪的目标文件的监听项。并且，如果有任务在等待产生事件时，就调用wake_up_locked函数唤醒所有正在等待的任务，处理相应的事件。当进程调用epoll_wait时，该进程就出现在ep的wq等待队列里面。接下来讲解epoll_wait函数。
总结epoll_ctl函数：该函数根据监听的事件，为目标文件申请一个监听项，并将该监听项挂人到eventpoll结构的红黑树里面。
epoll_wait等待事件的产生，内核代码如下：
sys_epoll_wait:
首先是对进程传进来的一些参数的检查：
参数全部检查合格后，接下来就调用ep_poll函数进行真正的处理：
sys_epoll_wait -> ep_poll:
ep_poll中首先是对等待时间的处理，timeout超时时间以ms为单位，timeout大于0，说明等待timeout时间后超时，如果timeout等于0，函数不阻塞，直接返回，小于0的情况，是永久阻塞，直到有事件产生才返回。
当没有事件产生时（(!ep_events_available(ep))为true）,调用__add_wait_queue_exclusive函数将当前进程加入到ep->wq等待队列里面，然后在一个无限for循环里面，首先调用set_current_state(TASK_INTERRUPTIBLE)，将当前进程设置为可中断的睡眠状态，然后当前进程就让出cpu，进入睡眠，直到有其他进程调用wake_up或者有中断信号进来唤醒本进程，它才会去执行接下来的代码。
如果进程被唤醒后，首先检查是否有事件产生，或者是否出现超时还是被其他信号唤醒的。如果出现这些情况，就跳出循环，将当前进程从ep->wp的等待队列里面移除，并且将当前进程设置为TASK_RUNNING就绪状态。
如果真的有事件产生，就调用ep_send_events函数，将events事件转移到用户空间里面。
sys_epoll_wait -> ep_poll -> ep_send_events:
ep_send_events没有什么工作，真正的工作是在ep_scan_ready_list函数里面：
sys_epoll_wait -> ep_poll -> ep_send_events -> ep_scan_ready_list:
ep_scan_ready_list首先将ep就绪链表里面的数据链接到一个全局的txlist里面，然后清空ep的就绪链表，同时还将ep的ovflist链表设置为NULL，ovflist是用单链表，是一个接受就绪事件的备份链表，当内核进程将事件从内核拷贝到用户空间时，这段时间目标文件可能会产生新的事件，这个时候，就需要将新的时间链入到ovlist里面。
仅接着，调用sproc回调函数(这里将调用ep_send_events_proc函数)将事件数据从内核拷贝到用户空间。
sys_epoll_wait -> ep_poll -> ep_send_events -> ep_scan_ready_list -> ep_send_events_proc:
ep_send_events_proc回调函数循环获取监听项的事件数据，对每个监听项，调用ep_item_poll获取监听到的目标文件的事件，如果获取到事件，就调用__put_user函数将数据拷贝到用户空间。
回到ep_scan_ready_list函数，上面说到，在sproc回调函数执行期间，目标文件可能会产生新的事件链入ovlist链表里面，所以，在回调结束后，需要重新将ovlist链表里面的事件添加到rdllist就绪事件链表里面。
同时在最后，如果rdlist不为空（表示是否有就绪事件），并且由进程等待该事件，就调用wake_up_locked再一次唤醒内核进程处理事件的到达（流程跟前面一样，也就是将事件拷贝到用户空间）。
到这，epoll_wait的流程是结束了，但是有一个问题，就是前面提到的进程调用epoll_wait后会睡眠，但是这个进程什么时候被唤醒呢？在调用epoll_ctl为目标文件注册监听项时，对目标文件的监听项注册一个ep_ptable_queue_proc回调函数，ep_ptable_queue_proc回调函数将进程添加到目标文件的wakeup链表里面，并且注册ep_poll_callbak回调，当目标文件产生事件时，ep_poll_callbak回调就去唤醒等待队列里面的进程。
总结一下epoll该函数： epoll_wait函数会使调用它的进程进入睡眠（timeout为0时除外），如果有监听的事件产生，该进程就被唤醒，同时将事件从内核里面拷贝到用户空间返回给该进程。
‘肆’ 开源阅读好开发嘛
开源阅读不太好开发，有一定的难度性，你可以购买一些这样那样的开源软件的教程或者图书（包括电子书）去学习，但一定不要以这些学习材料为主要的学习这些开源软件的方法和途径，有机会的话，或者说你想要学习的开源软件所使用的开发语言正好是你熟悉或者使用的编程语言，那么你应该尽量多去以阅读这些开源项目的源码本身为主。举个例子，如果你是 C/C++ 后端开发者，那么像 Redis、Nginx（它们都是使用 C 编写的）这样的开源项目的源码你应该认真的去研读一下；如果你是做 Windows C/C++ 客户端或者一名 QT 客户端开发人员，那么像 MFC、DUILIB、金山卫士等源码，你可以拿来读一读；如果你是 Java 程序员，Netty、Spring 等源码是你进阶路上必须迈过去的一关。为什么建议以阅读相关源码为主，而不是其他相关教程呢？首先，任何其他相关教程介绍的内容都是基于这个软件的源码实现创作出来的，虽然能帮助你快速理解一些东西，但是不同的教程作者在阅读同样一份代码时的注意点和侧重点不一样，加上如果作者在某些地方有理解偏差的，这种偏差会被引入你所学习的教程或者图书里面，也就是说，你学习的这些东西其实不是第一手的，而是经过别人加工或者理解意译过的，在这个过程中如果别人理解有偏差，那么你或多或少的会受一点影响。所以，为了"不受制于人”，亲自去阅读一些源码是非常有必要的。以上是开源阅读开发的部分内容，具体还是得自己去验证和设计祝您生活愉快，谢谢提问😊
‘伍’ nginx源代码怎么建立 vs工程
”, 除了阅读代码以外, 没有更好的方法. 7.在寻找bug时, 请从问题的表现形式到问题的根源来分析代码. 不要沿着不相关的路径(误入歧途). 8.我们要充分利用调试器|编译器给出的警告或输出的符号代码|系统调用跟踪器|数据库结构化查询语言的日志机制...
‘陆’ php新手学习路线是怎样的
第一阶段：基础阶段（基础PHP程序员）
重点：把LNMP搞熟练（核心是安装配置基本操作） 目标：能够完成基本的LNMP系统安装，简单配置维护；能够做基本的简单系统的PHP开发；能够在PHP中型系统中支持某个PHP功能模块的开发。
时间：完成本阶段的时间因人而异，有的成长快半年一年就过了，成长慢的两三年也有。
Linux
基本命令、操作、启动、基本服务配置（包括rpm安装文件，各种服务配置等）；会写简单的shell脚本和awk/sed 脚本命令等。
Nginx
做到能够安装配置nginx+php，知道基本的nginx核心配置选项，知道 server/fastcgi_pass/access_log 等基础配置，目标是能够让nginx+php_fpm顺利工作。
MySQL
会自己搭建mysql，知道基本的mysql配置选项；知道innodb和myisam的区别，知道针对InnoDB和MyISAM两个引擎的不同配置选项；知道基本的两个引擎的差异和选择上面的区别；能够纯手工编译搭建一个MySQL数据库并且配置好编码等正常稳定运行；核心主旨是能够搭建一个可运行的MySQL数据库。
PHP
基本语法数组、字符串、数据库、XML、Socket、GD/ImageMgk图片处理等等；熟悉各种跟MySQL操作链接的api（mysql/mysqli/PDO)，知道各种编码问题的解决；知道常规熟练使用的PHP框架（ThinkPHP、Zendframework、Yii、Yaf等）；了解基本MVC的运行机制和为什么这么做，稍微知道不同的PHP框架之间的区别；能够快速学习一个MVC框架。能够知道开发工程中的文件目录组织，有基本的良好的代码结构和风格，能够完成小系统的开发和中型系统中某个模块的开发工作。
前端
如果条件时间允许，可以适当学习下 HTML/CSS/JS 等相关知识，知道什么web标准，div+css的web/wap页面模式，知道HTML5和HTML4的区别；了解一些基本的前端只是和JS框架（jQuery之类的）；了解一些基本的JavaScript编程知识；（本项不是必须项，如果有时间，稍微了解一下是可以的，不过不建议作为重点，除非个人有强烈兴趣）。
系统设计
能够完成小型系统的基本设计，包括简单的数据库设计，能够完成基本的：浏览器 -> Nginx+PHP -> 数据库 架构的设计开发工作；能够支撑每天几十万到数百万流量网站的开发维护工作；
第二阶段：提高阶段 （中级PHP程序员）
重点：提高针对LNMP的技能，能够更全面的对LNMP有熟练的应用。 目标：能够随时随地搭建好LNMP环境，快速完成常规配置；能够追查解决大部分遇到的开发和线上环境的问题；能够独立承担中型系统的构架和开发工作；能够在大型系统中承担某个中型模块的开发工作。
1. Linux
在第一阶段的基础上面，能够流畅的使用Shell脚本来完成很多自动化的工作；awk/sed/perl 也操作的不错，能够完成很多文本处理和数据统计等工作；基本能够安装大部分非特殊的Linux程序（包括各种库、包、第三方依赖等等，比如MongoDB/Redis/Sphinx/Luncene/SVN之类的）；了解基本的Linux服务，知道如何查看Linux的性能指标数据，知道基本的Linux下面的问题跟踪等。
2. Nginx
在第一阶段的基础上面，了解复杂一些的Nginx配置；包括 多核配置、events、proxy_pass，sendfile/tcp_*配置，知道超时等相关配置和性能影响；知道nginx除了web server，还能够承担代理服务器、反向静态服务器等配置；知道基本的nginx配置调优；知道如何配置权限、编译一个nginx扩展到nginx；知道基本的nginx运行原理（master/worker机制，epoll），知道为什么nginx性能比apache性能好等知识。
3. MySQL/MongoDB
在第一阶段的基础上面，在MySQL开发方面，掌握很多小技巧，包括常规SQL优化（group by/order by/rand优化等）；除了能够搭建MySQL，还能够冷热备份MySQL数据，还知道影响innodb/myisam性能的配置选项（比如key_buffer/query_cache/sort_buffer/innodb_buffer_pool_size/innodb_flush_log_at_trx_commit等），也知道这些选项配置成为多少值合适；另外也了解一些特殊的配置选项，比如 知道如何搭建mysql主从同步的环境，知道各个binlog_format的区别；知道MySQL的性能追查，包括slow_log/explain等，还能够知道基本的索引建立处理等知识；原理方面了解基本的MySQL的架构（Server+存储引擎），知道基本的InnoDB/MyISAM索引存储结构和不同（聚簇索引，B树）；知道基本的InnoDB事务处理机制；了解大部分MySQL异常情况的处理方案（或者知道哪儿找到处理方案）。条件允许的情况，建议了解一下NoSQL的代表MongoDB数据库，顺便对比跟MySQL的差别，同事能够在合适的应用场景安全谨慎的使用MongoDB，知道基本的PHP与MongoDB的结合开发。
4. Redis/Memcached
在大部分中型系统里面一定会涉及到缓存处理，所以一定要了解基本的缓存；知道Memcached和Redis的异同和应用场景，能够独立安装 Redis/Memcached，了解Memcahed的一些基本特性和限制，比如最大的value值，知道PHP跟他们的使用结合；Redis了解基本工作原理和使用，了解常规的数据类型，知道什么场景应用什么类型，了解Redis的事务等等。原理部分，能够大概了解Memcached的内存结构（slab机制），redis就了解常用数据类型底层实现存储结构（SDS/链表/SkipList/HashTable）等等，顺便了解一下Redis的事务、RDB、AOF等机制更好。
5. PHP
除了第一阶段的能力，安装配置方面能够随意安装PHP和各种第三方扩展的编译安装配置；了解php-fpm的大部分配置选项和含义（如max_requests/max_children/request_terminate_timeout之类的影响性能的配置），知道mod_php/fastcgi的区别；在PHP方面已经能够熟练各种基础技术，还包括各种深入些的PHP，包括对PHP面向对象的深入理解/SPL/语法层面的特殊特性比如反射之类的；在框架方面已经阅读过最少一个以上常规PHP MVC框架的代码了，知道基本PHP框架内部实现机制和设计思想；在PHP开发中已经能够熟练使用常规的设计模式来应用开发（抽象工厂/单例/观察者/命令链/策略/适配器 等模式）；建议开发自己的PHP MVC框架来充分让开发自由化，让自己深入理解MVC模式，也让自己能够在业务项目开发里快速升级；熟悉PHP的各种代码优化方法，熟悉大部分PHP安全方面问题的解决处理；熟悉基本的PHP执行的机制原理（Zend引擎/扩展基本工作机制）。
6. C/C++
开始涉猎一定的C/C++语言，能够写基本的C/C++代码，对基本的C/C++语法熟悉（指针、数组操作、字符串、常规标准API）和数据结构（链表、树、哈希、队列）有一定的熟悉下；对Linux下面的C语言开发有基本的了解概念，会简单的makefile文件编写，能够使用简单的GCC/GDB的程序编译简单调试工作；对基本的网络编程有大概了解。（本项是为了向更高层次打下基础）。
7. 前端
在第一阶段的基础上面，熟悉基本的HTTP协议（协议代码200/300/400/500，基本的HTTP交互头）；条件允许，可以在深入写出稍微优雅的HTML+CSS+JavaScript，或者能够大致简单使用某些前端框架（jQuery/YUI/ExtJS/RequireJS/BootStrap之类）；如果条件允许，可以深入学习JavaScript编程，比如闭包机制、DOM处理；再深入些可以读读jQuery源码做深入学习。（本项不做重点学习，除非对前端有兴趣）。
8. 系统设计
能够设计大部分中型系统的网站架构、数据库、基本PHP框架选型；性能测试排查处理等；能够完成类似：浏览器 -> CDN(Squid) -> Nginx+PHP -> 缓存 -> 数据库 结构网站的基本设计开发维护；能够支撑每天数百万到千万流量基本网站的开发维护工作；
第三阶段：高级阶段 （高级PHP程序员）
重点：除了基本的LNMP程序，还能够在某个方向或领域有深入学习。（纵深维度发展） 目标：除了能够完成基本的PHP业务开发，还能够解决大部分深入复杂的技术问题，并且可以独立设计完成中大型的系统设计和开发工作；自己能够独立hold深入某个技术方向，在这块比较专业。（比如在MySQL、Nginx、PHP、Redis等等任一方向深入研究）
1. Linux
除了第二阶段的能力，在Linux下面除了常规的操作和性能监控跟踪，还能够使用很多高级复杂的命令完成工作（watch/tcpmp/starce/ldd/ar等)；在shell脚本方面，已经能够编写比较复杂的shell脚本（超过500行）来协助完成很多包括备份、自动化处理、监控等工作的shell；对awk/sed/perl 等应用已经如火纯青，能够随意操作控制处理文本统计分析各种复杂格式的数据；对Linux内部机制有一些了解，对内核模块加载，启动错误处理等等有个基本的处理；同时对一些其他相关的东西也了解，比如NFS、磁盘管理等等；
2. Nginx
在第二阶段的基础上面，已经能够把Nginx操作的很熟练，能够对Nginx进行更深入的运维工作，比如监控、性能优化，复杂问题处理等等；看个人兴趣，更多方面可以考虑侧重在关于Nginx工作原理部分的深入学习，主要表现在阅读源码开始，比如具体的master/worker工作机制，Nginx内部的事件处理，内存管理等等；同时可以学习Nginx扩展的开发，可以定制一些自己私有的扩展；同时可以对Nginx+Lua有一定程度的了解，看看是否可以结合应用出更好模式；这个阶段的要求是对Nginx原理的深入理解，可以考虑成为Nginx方向的深入专业者。
3. MySQL/MongoDB
在第二阶段的基础上面，在MySQL应用方面，除了之前的基本SQL优化，还能够在完成一些复杂操作，比如大批量数据的导入导出，线上大批量数据的更改表结构或者增删索引字段等等高危操作；除了安装配置，已经能够处理更多复杂的MySQL的问题，比如各种问题的追查，主从同步延迟问题的解决、跨机房同步数据方案、MySQL高可用架构等都有涉及了解；对MySQL应用层面，对MySQL的核心关键技术比较熟悉，比如事务机制（隔离级别、锁等）、对触发器、分区等技术有一定了解和应用；对MySQL性能方面，有包括磁盘优化（SAS迁移到SSD）、服务器优化（内存、服务器本身配置）、除了二阶段的其他核心性能优化选项（innodb_log_buffer_size/back_log/table_open_cache/thread_cache_size/innodb_lock_wait_timeout等）、连接池软件选择应用，对show *（show status/show profile）类的操作语句有深入了解，能够完成大部分的性能问题追查；MySQL备份技术的深入熟悉，包括灾备还原、对Binlog的深入理解，冷热备份，多IDC备份等；在MySQL原理方面，有更多了解，比如对MySQL的工作机制开始阅读部分源码，比如对主从同步（复制）技术的源码学习，或者对某个存储引擎（MyISAM/Innodb/TokuDB）等等的源码学习理解，如果条件允许，可以参考CSV引擎开发自己简单的存储引擎来保存一些数据，增强对MySQL的理解；在这个过程，如果自己有兴趣，也可以考虑往DBA方向发展。MongoDB层面，可以考虑比如说在写少读多的情况开始在线上应用MongoDB，或者是做一些线上的数据分析处理的操作，具体场景可以按照工作来，不过核心是要更好的深入理解RMDBS和NoSQL的不同场景下面的应用，如果条件或者兴趣允许，可以开始深入学习一下MongoDB的工作机制。
4. Redis/Memcached
在第二阶段的基础上面，能够更深入的应用和学习。因为Memcached不是特别复杂，建议可以把源码进行阅读，特别是内存管理部分，方便深入理解；Redis部分，可以多做一些复杂的数据结构的应用（zset来做排行榜排序操作/事务处理用来保证原子性在秒杀类场景应用之类的使用操作）；多涉及aof等同步机制的学习应用，设计一个高可用的Redis应用架构和集群；建议可以深入的学习一下Redis的源码，把在第二阶段积累的知识都可以应用上，特别可以阅读一下包括核心事件管理、内存管理、内部核心数据结构等充分学习了解一下。如果兴趣允许，可以成为一个Redis方面非常专业的使用者。
5. PHP
作为基础核心技能，我们在第二阶段的基础上面，需要有更深入的学习和应用。从基本代码应用上面来说，能够解决在PHP开发中遇到95%的问题，了解大部分PHP的技巧；对大部分的PHP框架能够迅速在一天内上手使用，并且了解各个主流PHP框架的优缺点，能够迅速方便项目开发中做技术选型；在配置方面，除了常规第二阶段会的知识，会了解一些比较偏门的配置选项（php auto_prepend_file/auto_append_file），包括扩展中的一些复杂高级配置和原理（比如memcached扩展配置中的memcache.hash_strategy、apc扩展配置中的apc.mmap_file_mask/apc.slam_defense/apc.file_update_protection之类的）；对php的工作机制比较了解，包括php-fpm工作机制（比如php-fpm在不同配置机器下面开启进程数量计算以及原理），对zend引擎有基本熟悉（vm/gc/stream处理），阅读过基本的PHP内核源码（或者阅读过相关文章），对PHP内部机制的大部分核心数据结构（基础类型/Array/Object）实现有了解，对于核心基础结构（zval/hashtable/gc）有深入学习了解；能够进行基本的PHP扩展开发，了解一些扩展开发的中高级知识（minit/rinit等），熟悉php跟apache/nginx不同的通信交互方式细节（mod_php/fastcgi）；除了开发PHP扩展，可以考虑学习开发Zend扩展，从更底层去了解PHP。
6. C/C++
在第二阶段基础上面，能够在C/C++语言方面有更深入的学习了解，能够完成中小型C/C++系统的开发工作；除了基本第二阶段的基础C/C++语法和数据结构，也能够学习一些特殊数据结构（b-tree/rb-tree/skiplist/lsm-tree/trie-tree等）方便在特殊工作中需求；在系统编程方面，熟悉多进程、多线程编程；多进程情况下面了解大部分多进程之间的通信方式，能够灵活选择通信方式（共享内存/信号量/管道等）；多线程编程能够良好的解决锁冲突问题，并且能够进行多线程程序的开发调试工作；同时对网络编程比较熟悉，了解多进程模型/多线程模型/异步网络IO模型的差别和选型，熟悉不同异步网络IO模型的原理和差异（select/poll/epoll/iocp等），并且熟悉常见的异步框架（ACE/ICE/libev/libevent/libuv/Boost.ASIO等）和使用，如果闲暇也可以看看一些国产自己开发的库（比如muo）；同时能够设计好的高并发程序架构（leader-follow/master-worker等）；了解大部分C/C++后端Server开发中的问题（内存管理、日志打印、高并发、前后端通信协议、服务监控），知道各个后端服务RPC通信问题（struct/http/thirft/protobuf等）；能够更熟络的使用GCC和GDB来开发编译调试程序，在线上程序core掉后能够迅速追查跟踪解决问题；通用模块开发方面，可以积累或者开发一些通用的工具或库（比如异步网络框架、日志库、内存池、线程池等），不过开发后是否应用要谨慎，省的埋坑去追bug。
7. 前端
深入了解HTTP协议（包括各个细致协议特殊协议代码和背后原因，比如302静态文件缓存了，502是nginx后面php挂了之类的）；除了之前的前端方面的各种框架应用整合能力，前端方面的学习如果有兴趣可以更深入，表现形式是，可以自己开发一些类似jQuery的前端框架，或者开发一个富文本编辑器之类的比较琐碎考验JavaScript功力。
8. 其他领域语言学习
在基础的PHP/C/C++语言方面有基本积累，建议在当前阶段可以尝试学习不同的编程语言，看个人兴趣爱好，脚本类语言可以学学 python/Ruby 之类的，函数式编程语言可以试试 Lisp/Haskell/Scala/Erlang 之类的，静态语言可以试试 Java/Golang，数据统计分析可以了解了解R语言，如果想换个视角做后端业务，可以试试 Node.js还有前面提到的跟Nginx结合的Nginx_Lua等。学习不同的语言主要是提升自己的视野和解决问题手段的差异，比如会了解除了进程/线程，还有轻量级协程；比如在跨机器通信场景下面，Erlang的解决方案简单的惊人；比如在不想选择C/C++的情况下，还有类似高效的Erlang/Golang可用等等；主要是提升视野。
9. 其他专业方向学习
在本阶段里面，会除了基本的LNMP技能之外，会考虑一些其他领域知识的学习，这些都是可以的，看个人兴趣和长期的目标方向。目前情况能够选择的领域比较多，比如、云计算（分布式存储、分布式计算、虚拟机等），机器学习（数据挖掘、模式识别等，应用到统计、个性化推荐），自然语言处理（中文分词等），搜索引擎技术、图形图像、语音识别等等。除了这些高大上的，也有很多偏工程方面可以学习的地方，比如高性能系统、移动开发（Android/IOS）、计算机安全、嵌入式系统、硬件等方向。
10. 系统设计
系统设计在第二阶段的基础之上，能够应用掌握的经验技能，设计出比较复杂的中大型系统，能够解决大部分线上的各种复杂系统的问题，完成类似 浏览器 -> CDN -> 负载均衡 ->接入层 -> Nginx+PHP -> 业务缓存 -> 数据库 -> 各路复杂后端RPC交互（存储后端、逻辑后端、反作弊后端、外部服务） -> 更多后端 酱紫的复杂业务；能够支撑每天数千万到数亿流量网站的正常开发维护工作。
‘柒’ fastdfs 与 为什么要搭建nginx
上次搭建FastDFS使用的版本是v4.05
http://blog.itpub.net/29254281/viewspace-1283539/
这个版本已经比较旧了
最新的版本是v5.04,由于作者重构了代码,所以安装过程还是有一些不一致.
最新版本下载地址:
http://sourceforge.net/projects/fastdfs/files/
安装可以参考压缩包内的INSTALL文件。
实验还是搭建一个FastDFS环境,并增加Nginx模块
所用软件:
FastDFS_v5.04.tar.gz
libfastcommon-master.zip
fastdfs-nginx-mole_v1.16.tar.gz
nginx-1.6.2.tar.gz
与之前版本不同的是,v5.04首先需要安装libfastcommon
下载地址:
https://github.com/happyfish100/libfastcommon.git
1.安装libfastcommon
在每一台服务器上,解压libfastcommon,进入libfastcommon-master目录执行
./make.sh
./make.sh install
可以看到libfastcommon.so安装到了/usr/lib64/libfastcommon.so
但是FastDFS主程序设置的lib目录是/usr/local/lib
所以需要创建软链接.
ln -s /usr/lib64/libfastcommon.so /usr/local/lib/libfastcommon.so
ln -s /usr/lib64/libfastcommon.so /usr/lib/libfastcommon.so
ln -s /usr/lib64/libfdfsclient.so /usr/local/lib/libfdfsclient.so
ln -s /usr/lib64/libfdfsclient.so /usr/lib/libfdfsclient.so
2.安装FastDFS主程序
这个版本似乎已经不需要libevent依赖
在每台服务器,解压缩FastDFS_v5.04.tar.gz,进入FastDFS目录
执行
./make.sh
./make.sh install
如果上步的软链接创建成功,就应该会非常顺利。
配置Tracker服务器(192.168.1.70)
vim /etc/fdfs/tracker.conf文件,修改如下内容
base_path=/tracker
然后执行命令
fdfs_trackerd tracker.conf
配置Storage服务器(192.168.1.80,192.168.1.30)
vim /etc/fdfs/storage.conf
group_name=group1
base_path=/storage
store_path0=/storage
tracker_server=192.168.1.70:22122
然后执行命令
fdfs_storaged storage.conf
执行测试,修改Tracker服务器192.168.1.70的配置文件/etc/fdfs/client.conf
tracker_server=192.168.1.170:22122
执行命令
[root@mysql1 fdfs]# fdfs_upload_file client.conf /home/nginx/FastDFS_v5.04.tar.gz
group1/M00/00/00/wKgBHlQvrQGARrS6AAU9tcFAzok.tar.gz
3.解压fastdfs-nginx-mole
FastDFS通过Tracker服务器,将文件放在Storage服务器存储,
但是同组之间的服务器需要复制文件,有延迟的问题.
假设Tracker服务器将文件上传到了192.168.1.80,文件ID已经返回客户端,
这时,后台会将这个文件复制到192.168.1.30,如果复制没有完成,客户端就用这个ID在192.168.1.30取文件,肯定会出现错误
这个fastdfs-nginx-mole可以重定向连接到源服务器取文件,避免客户端由于复制延迟的问题,出现错误。
修改fastdfs-nginx-mole的config文件
原来的内容是
CORE_INCS="$CORE_INCS /usr/local/include/fastdfs /usr/local/include/fastcommon/"
vim /home/nginx/fastdfs-nginx-mole/src/config,修改为
CORE_INCS="$CORE_INCS /usr/include/fastdfs /usr/include/fastcommon"
各个版本的位置并不统一.所以需要根据自己的版本修改位置。
4.安装nginx
在每个Storage服务器上安装Nginx
http://blog.itpub.net/29254281/viewspace-1283760/
yum -y install gcc automake autoconf libtool make gcc-c++ pcre* zlib openssl openssl-devel
增加fastdfs-nginx-mole模块
./configure \
--prefix=/home/nginx/nginx-1.6.2 \
--sbin-path=/home/nginx/nginx-1.6.2/nginx \
--conf-path=/home/nginx/nginx-1.6.2/nginx.conf \
--pid-path=/home/nginx/nginx-1.6.2/nginx.pid \
--with-http_ssl_mole \
--add-mole=/home/nginx/fastdfs-nginx-mole/src
make -j `cat /proc/cpuinfo | grep processor| wc -l` && make install
复制fastdfs-nginx-mole源码中的配置文件到/etc/fdfs
cp /home/nginx/fastdfs-nginx-mole/src/mod_fastdfs.conf /etc/fdfs
修改该配置文件
group_name=group1
tracker_server=192.168.1.70:22122
store_path0=/storage
base_path=/storage
复制FastDFS的配置到/etc/fdfs
修改Nginx配置文件
location /M00 {
root /storage;
ngx_fastdfs_mole;
}
在/storage目录下创建软连接,将其链接到实际存放数据的目录,
[root@mysql2 storage]# pwd
/storage
[root@mysql2 storage]# ln -s data/ M00
创建软链接的好处是方便多目录的管理
启动Nginx,就可以使用HTTP下载了.
注意事项:
1.FastDFS各个版本安装方式有差别,需要阅读INSTALL文件
2.FastDFS各个组件的默认位置可能不同,需要按照版本创建相应的软链接
‘捌’ C++ int i[233];我直接这样写代表了什么意思
C++ int i[233];直接这样写代表了，定义了一个整形的数组，共有233个整形元素，数组的名字叫做i。
‘玖’ FastAPI 源码阅读 (一) ASGI应用
本章开启 FastAPI 的源码阅读，FastAPI是当下python web中一颗新星，是一个划时代的框架。从诞生便是以快速和简洁为核心理念。
它继承于 Starlette ，是在其基础上的完善与扩展。详细内容可以翻看我之前的源码阅读。
openapi() 与 setup() 是在初始化阶段，对 OpenAPI 文档进行初始化的函数。
而 add_api_route() 一直到 trace() ，是关于路由的函数，它们都是直接对 router 的方法传参引用。所以这些放在解读 routing.py 时一并进行。
除了 Starlette 原生的参数，大量参数都是和API文档相关。
而路由从 Starlette 的 Router 换成了新式的 APIRouter
这两个概念查询了大量文档才搞明白。他们主要是关于文档与反向代理的参数。当使用了Nginx时等反向代理时，从Uvicorn直接访问，和从Nginx代理访问，路径可能出现不一致。比如Nginx中的Fastapi根目录是 127.0.0.1/api/ ，而Uvicorn角度看是 127.0.0.1:8000/ 。对于API接口来说，其实这个是没有影响的，因为服务器会自动帮我们解决这个问题。但对于API文档来说，就会出现问题。
因为当我们打开/docs时，网页会寻找 openapi.json 。他的是写在html内部的，而不是变化的。这会导致什么问题？
例如当我们从Uvicorn访问 127.0.0.1:8000/docs 时，他会寻找 /openapi.json 即去访问 127.0.0.1:8000/openapi.json (了解前端的应该知道)
但是假如我们这时，从Nginx外来访问文档，假设我们这样设置Nginx:
我们需要访问 127.0.0.1/api/docs ，才能从代理外部访问。而打开docs时，我们会寻找 openapi.json 。
所以这时，它应该在 127.0.0.1/api/openapi 这个位置存在。
但我们的浏览器不知道这些，他会按照 /openapi.json ，会去寻 127.0.0.1/openapi.json 这个位置。所以他不可能找到 openapi.json ，自然会启动失败。
这其实是openapi文档前端的问题。
root_path ，是用来解决这个问题的。既然 /openapi.json 找不到，那我自己改成 /api/openapi.json 不就成了么。
root_path 即是这个 /api ，这个是在定义时手动设置的参数。为了告诉FastAPI，它处在整个主机中的哪个位置。即告知 所在根目录 。这样，FastAPI就有了"自知之明"，乖乖把这个 前缀 加上。来找到正确的 openapi.json
加上了 root_path ， openapi.json 的位置变成了 /api/openapi.json 。当你想重新用Uvicorn提供的地址从代理内访问时，他会去寻找哪？没错 127.0.0.1:8000/api/openapi.json ，但我们从代理内部访问，并不需要这个 前缀 ，但它还是 “善意” 的帮我们加上了，所以这时候内部的访问失灵了。
虽然我们不大可能需要从两个位置访问这个完全一样的api文档。但这点一定要注意。
我在翻官方文档时，看到他们把 root_path 吹得天花乱坠，甚至弃用了 openapi_prefix 参数。但最后是把我弄得晕头转向。
这样要提到 servers 这个参数，官方首先给了这么段示例，稍作修改。
当我们打开API文档时
我们可以切换这个 Servers 时，底下测试接口的发送链接也会变成相应的。
但是记住，切换这个server，下面的接口不会发送变化，只是发送的host会改变。
这代表，虽然可以通过文档，测试多个其他主机的接口。但是这些主机和自己之间，需要拥有一致的接口。这种情况通常像在 线上/开发服务器 或者 服务器集群 中可能出现。虽然不要求完全一致，但为了这样做有实际意义，最好大体上是一致的。
但是我们看到，这是在代理外打开的，如果我们想从代理内打开，需要去掉 root_path 。会发生什么？
我们将 root_path 注释掉：
如果想解决这个问题，只需要将自身手动加入到 Servers 中。
关于 root_path_in_servers ，当 root_path 和 servers 都存在时， root_path 会自动将自己加入到 servers 中。但如果这个置为False，就不会自动加入。(默认为True)
API文档实际上以字符串方式，在FastAPI内部拼接的。实际上就是传统的 模板(Templates) ，这个相信大家都很熟悉了。优点是生成时灵活，但缺点是不容易二次开发。fastapi提供了好几种文档插件，也可以自己添加需要的。
这么长一大串，实际上就一句话 self.router.add_api_route() ，其他剩下的那些我暂且省略的，其实基本都是这样的。就是调用router的一个功能。下面我用省略方式将它们列出。
可以看到有些在这里就做了闭包，实际上除了这里的'add_api_route()'他们最终都是要做闭包的。只是过程放在里router里。它们最终的指向都是 router.add_api_route() ，这是一个添加真正将 endpoint 加入到路由中的方法。
FastAPI 添加路由的方式，在starlette的传统路由列表方式上做了改进，变成了装饰器式。
其实就是通过这些方法作为装饰器，将自身作为 endpoint 传入生成 route 节点，加入到 routes 中。
FastAPI的入口没有太大的变化，借用starlette的 await self.middleware_stack(scope, receive, send) 直接进入中间件堆栈。
‘拾’ 《Nginx模块开发指南使用 C++11和 Boost程序库》txt下载在线阅读全文,求百度云资源
《Nginx模块开发指南》（罗剑锋）电子书网盘下载免费在线阅读
链接: https://pan..com/s/19HN5knWwFEO8-M78kQc-6w
书名：Nginx模块开发指南
作者：罗剑锋
出版社：电子工业出版社
出版年份：2015-10
页数：372
内容简介：
Nginx 是由俄罗斯工程师Igor Sysoev 开发的一个高性能Web 服务器，运行效率远超传统的Apache、Tomcat，是世界第二大Web 服务器，被国内外诸多顶级互联网公司采用。
Nginx 的一个突出特点是其灵活优秀的模块化架构，可以在不修改核心的前提下增加任意功能，自2004 年发布至今，已经拥有百余个官方及非官方的功能模块（如fastcgi、memcached、mysql 等），使得Nginx 成长为了一个近乎“全能”的服务器软件。
Nginx 以纯C 语言实现，开发扩展功能模块也大多使用C 语言，但由于C 语言固有的过程式特性，编写、调试代码都较麻烦——特别是对于Nginx 的初学者。《Nginx 模块开发指南：使用C++11 和Boost 程序库》深入源码，详细解析了模块体系、配置指令、HTTP 框架等Nginx 核心运行机制，并在此基础上讲解如何使用C++和Boost 程序库来开发Nginx 模块，充分利用现代C++里的大量新特性和库组件，让Nginx 的模块开发变得更加便捷、轻松和愉快。
《Nginx 模块开发指南：使用C++11 和Boost 程序库》结构严谨、脉络清晰、论述精确、详略得当，值得广大软件开发工程师、系统运维工程师和编程爱好者拥有。
