八年前，谷歌發現每 500ms 的延遲會讓網路堵塞程度增加 20%，而亞馬遜也察覺 100ms 的延遲會使銷量降低 1%。從那以後，開發者就在減少延遲方面絞盡腦汁，以至於前端開發者試圖從他們用的 JS、CSS 甚至 HTML 中擠出每一毫秒。這篇文章接下來要介紹的就是在設計低延遲系統是要時刻注意的一些最佳實踐。大部分的建議看似荒謬卻被證實為是有用的，當然有時也需要一些權衡。（感謝在Quora 提出這個問題的匿名使用者，促使我將我的想法寫下來）。

選擇合適的語言

指令碼語言就不需要考慮這一點。雖然程式語言一直以來都在變得越來越快，只要你試圖將處理時間削減最後那麼幾毫秒，你就不能忽視解釋型語言。此外，你可能會需要一個強大的記憶體模式來進行無鎖程式設計，那麼你就要考慮使用 Java,、Scala、C++11或者Go。

儘量使用記憶體

I/O會增加延遲，所以要確保所有的資料都在記憶體中。這通常意味著要管理你的記憶體資料結構，維護持久日誌，這樣當機器或者程序重啟的時候能夠恢復之前的狀態。建立持久日誌的工具有Bitcask、 Krati、LevelDB 和 BDB-JE。除此之外，你可能可以投巧地執行一個本地的，持久的記憶體資料庫，比如說 Redis 或者MongoDB (當記憶體>>資料）。需要注意的是，當系統崩潰的時候你可能會丟失一些資料，因為它們的後臺和硬碟是同步的。

保持資料和處理在同一位置

網路躍遷（hop）比硬碟搜尋要快，但是它們仍然會間接增加延遲。理想說來，你的資料應該完全能夠放的進一臺主機裡的儲存器。AWS能夠提供將近 1/4TB 的雲記憶體，而物理伺服器通常有很多 TB 的空間。如果你需要使用多臺主機，那麼你要確保你正確地劃分好了資料和請求，這樣服務所需要的所有資料就都是本地可取的。

保持系統未充分利用

低延遲要求一直有資源來處理請求。不要試圖將你的硬體/軟體用到極限。要永遠給突發情況預留好空間。

最小化環境切換

環境轉換意味著你在處理多於現有資源可以處理的計算任務。你應該將執行緒數量減少到系統核心數量，然後各個執行緒運行於各自的核心中。

有序讀取

任何形式的儲存，無論是旋轉儲存、快閃記憶體，還是記憶體，當有序使用的時候都會大大提高效能。當你有序讀取記憶體時，你觸發了 RAM 和 CPU 快取級別的預取功能。如果處理正確，你需要的下一塊資料會在你需要它之前就到達L1快取。幫助這種處理的最簡單的方法就是儘量使用原始資料型別或者結構的陣列。按照這個原則，連結串列和物件陣列的使用是無論如何都要避免的。

批量處理寫任務

這聽上去違反直覺，但是批量寫可以大大提高效能。但是，這有一個誤區，就是這意味著系統必須在執行寫任務之前要等待一段時間。其實不然，一個執行緒應該是在一個緊湊的迴圈中不停地執行輸入輸出。每一個寫操作都會批量處理自從上一次執行寫任務之後接收到的所有資料。這樣一個既快速又有適應性的系統就生成了。

重視快取

經過所有這些優化處理後，快速訪問記憶體就變成了一個瓶頸。將執行緒固定於他們自己的核心中可以減少 CPU 快取汙染，序列化輸入輸出也可以預取快取。此外，使用原始資料型別可以減小記憶體大小，這樣快取就可以放下更多的資料。你也可以看看這個快取導向演算法：遞迴分解資料直到能夠放進快取中，然後再做其它必要的處理。

儘可能無鎖

和無鎖並無等待的資料結構和演算法交個朋友。每次你使用鎖，你都必須回溯到 OS 去幹涉鎖，這個鎖就是個很大的系統開銷。通常說來，如果你知道你在做什麼，你就可以通過了解JVM、C++ 或者 Go 的記憶體模式來避開鎖。

儘可能非同步

任何程式，尤其任何 I/O，只要不是建立響應所必須的，就應該在關鍵路徑之外進行。

儘可能並行化

任何程式，尤其任何I/O，只要能並行就應該並行處理。比如說如果你的高可用策略包括把交易日誌寫進硬碟併發送給第二個伺服器，那麼這些行為都是可以並行的。