同步非阻塞IO （NIO）html
NIO是基於事件驅動思想的，實現上一般採用Reactor（http://en.wikipedia.org/wiki/Reactor_pattern）模式，從程序角度而言，當發起IO的讀或寫操做時，是非阻塞的；當socket有流可讀或可寫入socket時，操做系統會相應的通知引用程序進行處理，應用再將流讀取到緩衝區或寫入操做系統。對於網絡IO而言，主要有鏈接創建、流讀取及流寫入三種事件、linux2.6之後的版本使用epoll（http://lse.sourceforge.net/epoll/index.html）方式實現NIO。linux
select/epoll的好處就在於單個process就能夠同時處理多個網絡鏈接的IO。它的基本原理就是select/epoll這個function會不斷的輪詢所負責的全部socket，當某個socket有數據到達了，就通知用戶進程。它的流程如圖：web
當用戶進程調用了select，那麼整個進程會被block，而同時，kernel會「監視」全部select負責的socket，當任何一個 socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操做，將數據從kernel拷貝到用戶進程。
這個圖和blocking IO的圖其實並無太大的不一樣，事實上，還更差一些。由於這裏須要使用兩個system call (select 和 recvfrom)，而blocking IO只調用了一個system call (recvfrom)。可是，用select的優點在於它能夠同時處理多個connection。（多說一句。因此，若是處理的鏈接數不是很高的話，使用 select/epoll的web server不必定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優點並非對於單個鏈接能處理得更快，而是在於能處理更多的鏈接。）
在IOmultiplexing Model中，實際中，對於每個socket，通常都設置成爲non-blocking，可是，如上圖所示，整個用戶的process實際上是一直被 block的。只不過process是被select這個函數block，而不是被socket IO給block。數據庫
AIO，異步IO方式編程
AIO爲異步IO方式，一樣基於事件驅動思想，實現上一般採用Proactor模式（http://en.wikipedia.org/wiki/Proactor_pattern）後端
從程序的角度而言，與NIO不一樣，當進行讀寫操做時，只須直接調用API的read或write方法便可。這兩種方法均爲異步的，對於讀操做而言，當有流可讀取時，操做系統會將可讀的流傳入read方法的緩衝區，並通知應用程序；對於寫操做而言，當操做系統將write方法傳遞的流寫入完畢時，操做系統主動通知應用程序。較之NIO而言，AIO一方面簡化了程序出的編寫，流的讀取和寫入都由操做系統來代替完成；另外一方面省去了NIO中程序要遍歷事件通知隊列（selector）的代價。Windows基於IOCP（http://en.wikipedia.org/wiki/Input/output_completion_port）實現了AIO，Linux目前只有基於epoll實現的AIO。網絡
IO的方式一般分爲幾種，同步阻塞的BIO、同步非阻塞的NIO、異步非阻塞的AIO
在JDK1.4出來以前，咱們創建網絡鏈接的時候採用BIO模式，須要先在服務端啓動一個ServerSocket，而後在客戶端啓動Socket來對服務端進行通訊，默認狀況下服務端須要對每一個請求創建一堆線程等待請求，而客戶端發送請求後，先諮詢服務端是否有線程相應，若是沒有則會一直等待或者遭到拒絕請求，若是有的話，客戶端會線程會等待請求結束後才繼續執行。
BIO與NIO一個比較重要的不一樣，是咱們使用BIO的時候每每會引入多線程，每一個鏈接一個單獨的線程；而NIO則是使用單線程或者只使用少許的多線程，每一個鏈接共用一個線程。
NIO的最重要的地方是當一個鏈接建立後，不須要對應一個線程，這個鏈接會被註冊到多路複用器上面，因此全部的鏈接只須要一個線程就能夠搞定，當這個線程中的多路複用器進行輪詢的時候，發現鏈接上有請求的話，纔開啓一個線程進行處理，也就是一個請求一個線程模式。
在NIO的處理方式中，當一個請求來的話，開啓線程進行處理，可能會等待後端應用的資源(JDBC鏈接等)，其實這個線程就被阻塞了，當併發上來的話，仍是會有BIO同樣的問題。
HTTP/1.1出現後，有了Http長鏈接，這樣除了超時和指明特定關閉的http header外，這個連接是一直打開的狀態的，這樣在NIO處理中能夠進一步的進化，在後端資源中能夠實現資源池或者隊列，當請求來的話，開啓的線程把請求和請求數據傳送給後端資源池或者隊列裏面就返回，而且在全局的地方保持住這個現場(哪一個鏈接的哪一個請求等)，這樣前面的線程仍是能夠去接受其餘的請求，然後端的應用的處理只須要執行隊列裏面的就能夠了，這樣請求處理和後端應用是異步的.當後端處理完，到全局地方獲得現場，產生響應，這個就實現了異步處理。多線程
BIO是一個鏈接一個線程。
NIO是一個請求一個線程。
AIO是一個有效請求一個線程。併發
按照《Unix網絡編程》的劃分，IO模型能夠分爲：阻塞IO、非阻塞IO、IO複用、信號驅動IO和異步IO，按照POSIX標準來劃分只分爲兩類：同步IO和異步IO。如何區分呢？首先一個IO操做其實分紅了兩個步驟：發起IO請求和實際的IO操做，同步IO和異步IO的區別就在於第二個步驟是否阻塞，若是實際的IO讀寫阻塞請求進程，那麼就是同步IO，所以阻塞IO、非阻塞IO、IO複用、信號驅動IO都是同步IO，若是不阻塞，而是操做系統幫你作完IO操做再將結果返回給你，那麼就是異步IO。阻塞IO和非阻塞IO的區別在於第一步，發起IO請求是否會被阻塞，若是阻塞直到完成那麼就是傳統的阻塞IO，若是不阻塞，那麼就是非阻塞IO。運維
Reactor: send(msg) -> 消息隊列是否爲空，若是爲空-> 向Reactor註冊OP_WRITE，而後返回 -> Reactor select -> 觸發Writable，通知用戶線程去處理->先註銷Writable(不少人遇到的cpu 100%的問題就在於沒有註銷）,處理Writeable，若是沒有徹底寫入，繼續註冊OP_WRITE。注意到，寫入的工做仍是用戶線程在處理。
Proactor: send(msg) ->消息隊列是否爲空，若是爲空,發起read異步調用，並註冊CompletionHandler，而後返回。-> 操做系統負責將你的消息寫入，並返回結果（寫入的字節數）給Proactor->Proactor派發CompletionHandler。可見，寫入的工做是操做系統在處理，無需用戶線程參與。事實上在aio的API中,AsynchronousChannelGroup就扮演了Proactor的角色。
http://www.ibm.com/developerworks/cn/linux/l-async/
除了須要阻塞以外，select 函數所提供的功能（異步阻塞 I/O）與 AIO 相似。不過，它是對通知事件進行阻塞，而不是對 I/O 調用進行阻塞。
AIO 簡介
Linux 異步 I/O 是 Linux 內核中提供的一個至關新的加強。它是 2.6 版本內核的一個標準特性，可是咱們在 2.4 版本內核的補丁中也能夠找到它。AIO 背後的基本思想是容許進程發起不少 I/O 操做，而不用阻塞或等待任何操做完成。稍後或在接收到 I/O 操做完成的通知時，進程就能夠檢索 I/O 操做的結果。
I/O 模型
在深刻介紹 AIO API 以前，讓咱們先來探索一下 Linux 上可使用的不一樣 I/O 模型。這並非一個詳盡的介紹，可是咱們將試圖介紹最經常使用的一些模型來解釋它們與異步 I/O 之間的區別。圖 1 給出了同步和異步模型，以及阻塞和非阻塞的模型。
圖 1. 基本 Linux I/O 模型的簡單矩陣
每一個 I/O 模型都有本身的使用模式，它們對於特定的應用程序都有本身的優勢。本節將簡要對其一一進行介紹。
同步阻塞 I/O
I/O 密集型進程所執行的 I/O 操做比執行的處理操做更多。CPU 密集型的進程所執行的處理操做比 I/O 操做更多。Linux 2.6 的調度器實際上更加偏心 I/O 密集型的進程，由於它們一般會發起一個 I/O 操做，而後進行阻塞，這就意味着其餘工做均可以在二者之間有效地交錯進行。
最經常使用的一個模型是同步阻塞 I/O 模型。在這個模型中，用戶空間的應用程序執行一個系統調用，這會致使應用程序阻塞。這意味着應用程序會一直阻塞，直到系統調用完成爲止（數據傳輸完成或發生錯誤）。調用應用程序處於一種再也不消費 CPU 而只是簡單等待響應的狀態，所以從處理的角度來看，這是很是有效的。
圖 2 給出了傳統的阻塞 I/O 模型，這也是目前應用程序中最爲經常使用的一種模型。其行爲很是容易理解，其用法對於典型的應用程序來講都很是有效。在調用read 系統調用時，應用程序會阻塞並對內核進行上下文切換。而後會觸發讀操做，當響應返回時（從咱們正在從中讀取的設備中返回），數據就被移動到用戶空間的緩衝區中。而後應用程序就會解除阻塞（read 調用返回）。
圖 2. 同步阻塞 I/O 模型的典型流程
從應用程序的角度來講，read 調用會延續很長時間。實際上，在內核執行讀操做和其餘工做時，應用程序的確會被阻塞。
同步非阻塞 I/O
同步阻塞 I/O 的一種效率稍低的變種是同步非阻塞 I/O。在這種模型中，設備是以非阻塞的形式打開的。這意味着 I/O 操做不會當即完成，read 操做可能會返回一個錯誤代碼，說明這個命令不能當即知足（EAGAIN 或EWOULDBLOCK），如圖 3 所示。
圖 3. 同步非阻塞 I/O 模型的典型流程
非阻塞的實現是 I/O 命令可能並不會當即知足，須要應用程序調用許屢次來等待操做完成。這可能效率不高，由於在不少狀況下，當內核執行這個命令時，應用程序必需要進行忙碌等待，直到數據可用爲止，或者試圖執行其餘工做。正如圖 3 所示的同樣，這個方法能夠引入 I/O 操做的延時，由於數據在內核中變爲可用到用戶調用 read 返回數據之間存在必定的間隔，這會致使總體數據吞吐量的下降。
異步阻塞 I/O
另一個阻塞解決方案是帶有阻塞通知的非阻塞 I/O。在這種模型中，配置的是非阻塞 I/O，而後使用阻塞select 系統調用來肯定一個 I/O 描述符什麼時候有操做。使 select 調用很是有趣的是它能夠用來爲多個描述符提供通知，而不只僅爲一個描述符提供通知。對於每一個提示符來講，咱們能夠請求這個描述符能夠寫數據、有讀數據可用以及是否發生錯誤的通知。
圖 4. 異步阻塞 I/O 模型的典型流程 (select)
select 調用的主要問題是它的效率不是很是高。儘管這是異步通知使用的一種方便模型，可是對於高性能的 I/O 操做來講不建議使用。
異步非阻塞 I/O（AIO）
最後，異步非阻塞 I/O 模型是一種處理與 I/O 重疊進行的模型。讀請求會當即返回，說明 read 請求已經成功發起了。在後臺完成讀操做時，應用程序而後會執行其餘處理操做。當 read 的響應到達時，就會產生一個信號或執行一個基於線程的回調函數來完成此次 I/O 處理過程。
圖 5. 異步非阻塞 I/O 模型的典型流程
在一個進程中爲了執行多個 I/O 請求而對計算操做和 I/O 處理進行重疊處理的能力利用了處理速度與 I/O 速度之間的差別。當一個或多個 I/O 請求掛起時，CPU 能夠執行其餘任務；或者更爲常見的是，在發起其餘 I/O 的同時對已經完成的 I/O 進行操做。
下一節將深刻介紹這種模型，探索這種模型使用的 API，而後展現幾個命令。
異步 I/O 的動機
從前面 I/O 模型的分類中，咱們能夠看出 AIO 的動機。這種阻塞模型須要在 I/O 操做開始時阻塞應用程序。這意味着不可能同時重疊進行處理和 I/O 操做。同步非阻塞模型容許處理和 I/O 操做重疊進行，可是這須要應用程序根據重現的規則來檢查 I/O 操做的狀態。這樣就剩下異步非阻塞 I/O 了，它容許處理和 I/O 操做重疊進行，包括 I/O 操做完成的通知。
除了須要阻塞以外，select 函數所提供的功能（異步阻塞 I/O）與 AIO 相似。不過，它是對通知事件進行阻塞，而不是對 I/O 調用進行阻塞。
Linux 上的 AIO 簡介
本節將探索 Linux 的異步 I/O 模型，從而幫助咱們理解如何在應用程序中使用這種技術。
在傳統的 I/O 模型中，有一個使用唯一句柄標識的 I/O 通道。在 UNIX® 中，這些句柄是文件描述符（這對等同於文件、管道、套接字等等）。在阻塞 I/O 中，咱們發起了一次傳輸操做，當傳輸操做完成或發生錯誤時，系統調用就會返回。
AIO 在 2.5 版本的內核中首次出現，如今已是 2.6 版本的產品內核的一個標準特性了。
在異步非阻塞 I/O 中，咱們能夠同時發起多個傳輸操做。這須要每一個傳輸操做都有唯一的上下文，這樣咱們才能在它們完成時區分究竟是哪一個傳輸操做完成了。在 AIO 中，這是一個 aiocb（AIO I/O Control Block）結構。這個結構包含了有關傳輸的全部信息，包括爲數據準備的用戶緩衝區。在產生 I/O （稱爲完成）通知時，aiocb 結構就被用來唯一標識所完成的 I/O 操做。這個 API 的展現顯示瞭如何使用它。
1.內存優化
2.運維接口優化
3.日誌管理優化
4.解析接口優化。
5.單表、單表+and、單表加多個and，多表
6.一致性Hash
7.跨庫讀
8.跨庫寫
9.後端拆鏈
10.生成SQL
11.數據字典
12.數據庫檢測
13.QOS