最近乙個專案為了實現低時延、高吞吐的目標，自己寫了個簡單的通訊模組。結合實現中的經驗和看的一些文章，嘗試總結下這個中間一些共通的點，也是做個小結。
備註：我總結時候總是會有一些不同於他人的角度，雖然別人看著可能會比較莫名，但是個人就是寫給未來的自己罷了 o(∩_∩)o哈哈~備註2：不要來扯什麼中斷、執行緒排程更靈活之類的廢話。請麻煩認清楚本文討論的問題。
不論是利用使用者態、核心態執行緒、程序還是自己實現的執行緒模式，都盡量的避免這中間的排程/切換。主要是為了避免：1.排程消耗 2. 快取汙染，同時有助於實現1.2的原則。
這個當然不完全決定，但是在關鍵路徑上必須的原則。
結合繫結cpu核，可以避免競爭，也就不需要各種鎖、訊號量等機制。
直接涉及硬體裝置驅動時可用，更適合定製化的系統。要知道乙個中斷喚醒要3-5us，還不算其它消耗。在高吞吐、高併發下是非常值得採用輪詢模式，更可以結合[1.1]將驅動開始就繫結cpu核處理。
反正就是，一門心思、死心眼的就忙那點事情。多像生產線~~ ：)
說到生產線，就引入另乙個點，為了能處理各種不同狀況的報文，就需要乙個合適的機制給死心眼用
就像生產線上，乙個產品(報文)流過不同工序(狀態)，每個工序處理乙個任務
如果寫個使用者態通訊實現，那麼系統呼叫(tcp協議棧->硬體驅動)是個非常漫長的過程；如果寫個核心態驅動，那麼操作硬體，同樣也是個無法忍受的等待。如果是單併發的系統，還是那話，不在討論範圍。
批量化的處理，其實就是摺疊了這部分系統呼叫/硬體等較慢處理的消耗，平攤。1個人要捐1萬可能壓力山大，10個人就好多，1000個人就是毛毛雨了。
具體批量處理多少個應根據情況來定，最好有個基準測試和具體的目標，或者可以配置。
要知道記憶體分配、拷貝甚至查詢都是非常耗費時間的。
但是完全的記憶體零拷貝並不見得能實現，需要根據具體的系統、目標，甚至硬體來分析具體實現方案。
但是至少，記憶體池、大頁內存在大部分實現中比較容易達到了。
嗯，很熱門的cas實現，只是這個硬體鎖(原子操作)還是免不掉。同時，如果衝突/競爭機率很高情況下，其實和spinlock也相差無幾。
所以，也許per cpu core的更合適。嗯，至少我還沒想好更好的實現，要努力學習呀！
不多說目前主流的cpu的cache line都是64b長度的，嗯，一次就是刷這麼多。
讀寫的cache適當的分離，避免經常改動的部分影響很少變化的部分。
強烈推薦！
小心使用，不完全明確的還是交給cpu自己優化吧
在大迴圈和批量處理，非常有威力。但使用需要些技巧。
什麼__always_inline__,hot之類
和查詢只會用鍊錶逐個比較的，交流如何高效能本身就是挺扯的事情。這說明俺也是個挺扯的人~~
嗯，就這樣~！
實現高效能穩定的socket tcp通訊經驗分享
其實在.net socket編寫高效能穩定方面的資料真的比較少,乙個實質性的測試資料結果對比就更少了.我們可以從看到ms說net 2.0 sp1後的socket通訊能力非常強勁,可以同時掛起6w個io 可以簡單地認為可以在一秒內send receive可以達到6w或更高 但要找這個資料的測試似乎很難...
關於《高效能MySQL》的一些簡單分享by笑臉岑
在這裡主要想簡單分享一些關於併發相關的內容，主要內容如下 併發控制目的是當多個連線對資料庫進行修改時保證資料的一致性。mysql提供兩個級別的併發控制 伺服器級和儲存引擎級。從功能上可以分為共享鎖和排他鎖，也就是我們常講的讀鎖和寫鎖。簡單描述就是 讀鎖是共享的，或者說是互相不阻塞的。多個使用者在同一...
Python高效能瓶頸及一些常用高效庫
1.全域性直譯器 對於python來說，充分利用多核效能的阻礙主要在於python的全域性直譯器鎖 gil gil確保python程序一次只能執行一條指令，無論當前有多少個核心。這意味著即使某些python 可以使用多個核心，在任意時間點僅有乙個核心在執行python的指令。以前面調查的例子來說，即...