Linux高性能服務器處理框架12步走

·減少頻繁的分配和釋放，提高性能的同時，還能避免內存碎片的問題;

·能夠存儲變長的數據，不要很傻瓜地只能預分配一個最大長度;

·基于SLAB算法實現內存池是一個好的思路：分配不同大小的多個塊，請求時返回大于請求長度的最小塊即可，對于容器而言，處理固定塊的分配和回收，相當容易實現。當然，還要記得需要設計成線程安全的，自旋鎖比較好，使用讀寫自旋鎖就更好了。

·分配內容的增長管理是一個問題，比如第一次需要1KB空間，隨著數據源源不斷的寫入，第二次就需要4KB空間了。擴充空間容易實現，可是擴充的時候必然 涉及數據拷貝。甚至，擴充的需求很大，上百兆的數據，這樣就不好辦了。暫時沒更好的想法，可以像STL一樣，指數級增長的分配策略，拷貝數據雖不可避免， 但是起碼重分配的幾率越來越小了。

·上面提到的，如果是上百兆的數據擴展需要，采用內存映射文件來管理是一個好的辦法：映射文件后，雖然占了很大的虛擬內存，但是物理內存僅在寫入的時候才會被分配，加上madvice()來加上順序寫的優化建議后，物理內存的消耗也會變小。

·用string或者vector去管理內存并不明智，雖然很簡單，但服務器軟件開發中不適合使用STL，特別是對穩定性和性能要求很高的情況下。

·減少對象的分配和釋放。其實C++對象也就是struct，把構造和析構脫離出來手動初始化和清理，保持對同一個緩沖區的循環利用，也就不難了。

·可以設計為一個對象池只能存放一種對象，則對象池的實現實際就是固定內存塊的池化管理，非常簡單。畢竟，對象的數量非常有限。

·如果可以預料到極限的處理能力，采用固定大小的環形隊列來作為緩沖區是比較不錯的。一個生產者一個消費者是常見的應用場景，環形隊列有其經典的“鎖無關”算法，在一個線程讀一個線程寫的場景下，實現簡單，性能還高，還不涉及資源的分配和釋放。好啊，實在是好!

·涉及多個生產者消費者的時候，tbb::concurent_queue是不錯的選擇，線程安全，并發性也好，就是不知道資源的分配釋放是否也管理得足夠好。

·因為epoll是事件觸發的，而一系列的流程可能是分散在多個事件中的，因此，必須保留下中間狀態，使得下一個事件觸發的時候，能夠接著上次處理的位置繼續處理。要簡單的話，STL的hash_map還行，不過得自己處理鎖的問題，多線程環境下使用起來很麻煩。

·多線程環境下的hash表，最好的還是tbb::concurent_hash_map。

·事件線程是調用epoll_wait()等待事件的線程。例子代碼里面，一個線程干了所有的事情，而需要開發一個高性能的服務器的時候，事件線程應該專注于事件本身的處理，將觸發事件的socket句柄放到對應的處理隊列中去，由具體的處理線程負責具體的工作。

·服務端的socket句柄(就是調用bind()和listen()的這個)最好在單獨的一個線程里面做accept()，阻塞還是非阻塞都無所謂，相比整個服務器的通訊，用戶接入的動作只是很小一部分。而且，accept()不放在事件線程的循環里面，減少了判斷。

·接收線程從發生EPOLLIN事件的隊列中取出socket句柄，然后在這個句柄上調用recv接收數據，直到緩沖區沒有數據為止。接收到的數據寫入以socket為鍵的hash表中，hash表中有一個自增長的緩沖區，保存了客戶端發過來的數據。

·這樣的處理方式適合于客戶端發來的數據很小的應用，比如HTTP服務器之類;假設是文件上傳的服務器，則接受線程會一直處理某個連接的海量數據，其他客戶端的數據處理產生了饑餓。所以，如果是文件上傳服務器一類的場景，就不能這樣設計。

·發送線程從發送隊列獲取需要發送數據的SOCKET句柄，在這些句柄上調用send()將數據發到客戶端。隊列中指保存了SOCKET句柄，具體的信息 還需要通過socket句柄在hash表中查找，定位到具體的對象。如同上面所講，客戶端信息的對象不但有一個變長的接收數據緩沖區，還有一個變長的發送 數據緩沖區。具體的工作線程發送數據的時候并不直接調用send()函數，而是將數據寫到發送數據緩沖區，然后把SOCKET句柄放到發送線程隊列。

·SOCKET句柄放到發送線程隊列的另一種情況是：事件線程中發生了EPOLLOUT事件，說明TCP的發送緩沖區又有了可用的空間，這個時候可以把SOCKET句柄放到發送線程隊列，一邊觸發send()的調用;

·需要注意的是：發送線程發送大量數據的時候，當頻繁調用send()直到TCP的發送緩沖區滿后，便無法再發送了。這個時候如果循環等待，則其他用戶的 發送工作受到影響;如果不繼續發送，則EPOLL的ET模式可能不會再產生事件。解決這個問題的辦法是在發送線程內再建立隊列，或者在用戶信息對象上設置 標志，等到線程空閑的時候，再去繼續發送這些未發送完成的數據。

·一位將epoll使用的高手說道：“單純靠epoll來管理描述符不泄露幾乎是不可能的。完全解決方案很簡單，就是對每個fd設置超時時間，如果超過timeout的時間，這個fd沒有活躍過，就close掉”。

·所以，定時器線程定期輪訓整個hash表，檢查socket是否在規定的時間內未活動。未活動的SOCKET認為是超時，然后服務器主動關閉句柄，回收資源。

·工作線程由接收線程去觸發：每次接收線程收到數據后，將有數據的SOCKET句柄放入一個工作隊列中;工作線程再從工作隊列獲取SOCKET句柄，查詢hash表，定位到用戶信息對象，處理業務邏輯。

·工作線程如果需要發送數據，先把數據寫入用戶信息對象的發送緩沖區，然后把SOCKET句柄放到發送線程隊列中去。

·對于任務隊列，接收線程是生產者，多個工作線程是消費者;對于發送線程隊列，多個工作線程是生產者，發送線程是消費者。在這里需要注意鎖的問題，如果采用tbb::concurrent_queue，會輕松很多。

·假設這樣一種情況：事件線程剛把某SOCKET因發生EPOLLIN事件放入了接收隊列，可是隨即客戶端異常斷開了，事件線程又因為EPOLLERR事 件刪除了hash表中的這一項。假設接收隊列很長，發生異常的SOCKET還在隊列中，等到接收線程處理到這個SOCKET的時候，并不能通過 SOCKET句柄索引到hash表中的對象。

·索引不到的情況也好處理，難點就在于，這個SOCKET句柄立即被另一個客戶端使用了，接入線程為這個SCOKET建立了hash表中的某個對象。此時，句柄相同的兩個SOCKET，其實已經是不同的兩個客戶端了。極端情況下，這種情況是可能發生的。

·解決的辦法是，使用socket fd + sequence為hash表的鍵，sequence由接入線程在每次accept()后將一個整型值累加而得到。這樣，就算SOCKET句柄被重用，也不會發生問題了。

·框架中最容易出問題的是工作線程：工作線程的處理速度太慢，就會使得各個隊列暴漲，最終導致服務器崩潰。因此必須要限制每個隊列允許的最大大小，且需要監視每個工作線程的處理時間，超過這個時間就應該采用某個辦法結束掉工作線程。