1.OpenResty究竟解決了什麼痛點
2.Location路由
3.OpenResty請求處理機制
4.緩存
2011年的時候章亦春老師把 LuaJIT VM 嵌入到 Nginx 中，實現了 OpenResty 這個高性能服務端解決方案。
性能接近c model，甚至超過
Node.js—開創性 異步非阻塞（用回調—回調次數多會出問題）
Python—python從3.4加入異步的東西，3.5引入協程，
Golang—異步協程出去，需要在線熱調試，
SystemTap
Bass—後端即服務。
ps. 協程和多線程下的線程類似：有自己的堆棧，自己的局部變量，有自己的指令指針，但是和其他協程程序共享全局變量等信息。線程和協程的主要不同在於：多處理器的情況下，概念上來說多線程是同時運行多個線程，而協程是通過代碼來完成協程的切換，任何時刻只有一個協程程序在運行。並且這個在運行的協程只有明確被要求掛起時纔會被掛起。
用 Lua 來控制 Nginx 的行爲，用C++去做控制，要自己實現協程，但是在 OpenResty 裏面，它像 Golang 一樣天生就有協程。OpenResty 所有的參數和行爲都可以在程序裏面動態的去做，完全不用重啓和reload，因爲它是基於 Nginx 之上的，性能非常高。
一個worker 在可能出現阻塞的地方會註冊一個事件就放過去了（epoll模型），而不是乾巴巴的等待阻塞被處理完
location :
語法規則
location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
修飾符
= 表示精確匹配。只有請求的url路徑與後面的字符串完全相等時，纔會命中
~ 表示該規則是使用正則定義的，區分大小寫。
~* 表示該規則是使用正則定義的，不區分大小寫。
^~ 表示如果該符號後面的字符是最佳匹配，採用該規則，不再進行後續的查找
匹配優先級
(1). 優先嚐試 全匹配( 也就是前綴 =)
(2). 嘗試 路徑匹配 （ 也就是前綴 ^~）
(3). 嘗試 正則匹配 （ 也就是前綴 ~* 或者 ~）
(4). 字符串匹配 （也就是前綴爲空）
所以，前綴的優先級概括爲： = > ^~ > ~, ~* > 空 全匹配 > 路徑匹配 > 正則匹配 > 字符串匹配
使用正則定義的location在配置文件中出現的順序很重要。
使用精確匹配可以提高查找的速度。
ngx處理一個請求的流程
1、post-read 7、access
2、server-rewrite 8、 post-access
3、find-config 9、try-files
4、rewrite 10、content
5、post-rewrite 11、log
6、preaccess
http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html#02-NginxDirectiveExecOrder01
緩存
shared_dict 字典緩存
lua-resty-lrucache（常用）
lua-resty-lrucache是每個worker佔用一個。有get\set\delete操作。
API不完整
壓測：ab -n 100000 -c 100 -k http://127.0.0.1:81/get_value
省去較昂貴的序列化操作
FFI允許lua調用C。可以參考安裝目錄下的resty目錄（openresty/lualib/resty）實現的Rand函數實現，其實是用c的。
2.增加第三方模塊
2.1.查找：例如：搜索resty http
2.2.添加模塊：將下載的第三方庫文件放在resty目錄（openresty/lualib/resty）中
2.3.調用模塊：如前面調用json庫一樣使用即可
Openresty引入lua實現的一個比較強的一個功能就是和後端mysql、redis 等數據庫的連接更直接。減少了中間其他動態語言再去處理的過程，可以通過nginx直接返回或修改數據，也便於實現API。
OpenResty雖然爲了提高性能更多的是使用的內存數據庫(redis),但是特殊的時候也會存在需要操作數據庫的時候.