接下來咱們會從最基本的開始 :
儘可能的優化單機性能
基本上不少高性能的書籍都是直接跳至分散式架構，但是如果一個開發者連單機都處理不好，我不太相信他開發出來的分散式架構是高性能的。
單機處理的好，才是高性能的前提。
本篇會分為以下幾個章節，來探討單機領域的優化方向，這個方向也就是之後文章的目錄。
單機系統的最基本最基本架構應該長的如下圖 1，就是最簡單的應用服務與資料庫服務，咱們這裡先以最大眾的 web 服務為主 :
圖 1 : 最簡單的應用架構。
基本上單機應用層的優化目標如下 :
以最快與最少的資源來處理請求，並且可以最快的速度將結果回應給客戶，讓客戶於愉悅。
而要完成這件事情，基本上有幾個方向可以研究。
不過簡單來說就分兩種『運算』與『I/O』。
圖 2 : 應用服務性能重點。
資料庫層是的優化目標基本上如上應用層一樣:
以最快與最少的資源來處理請求，並且可以最快的速度將結果回應給客戶，讓客戶於愉悅。
基本上在性能方向會有幾個方向可以研究 :
它就是影響性能的最大變數，用的好上天堂，用不好下地獄，所以在們之後會花不少篇的文章來說明索引這個主題。
但是在資料庫世界中，事實上有幾個是會拖性能後腿，但是它又是不可少的東西，那就是 :
而這兩個就是要處理所謂的『一致性難題』，這問題非常的複雜，而且這也於分散式相關，這個地方如果沒搞懂，直接上分散式系統只是死路一條。
在資料庫世界中，如果沒有鎖與事務，那你的系統就不能讓用戶感到『愉悅』，因為它會錯誤百出，所以我們必須熟悉的理解它為什麼是拖後後腿，並且它為什麼又是必要的，這種才能儘可能的讓它們不要拖太多。
之後的文章我們將以『MySQL』這個資料庫服務來進行說明與研究，雖然不同的資料庫服務有些實作細節或啥的會不相同，它是他們的基本原理都差不多。
圖 3 : 資料庫服務性能重點。
然後通常上述兩個最基本的性能優化結束以下，會有另外兩個部份的優化服務會加入變成如下圖 4 :
圖 4 : 加上緩存服務的架構
這張圖基本上就是咱們這世界 80 % 以上的最基本的系統架構，之後文章咱們將會一個部份一個部份的來慢慢深入研究。
Cache 服務，最主要用來將資料庫的一些常用查詢結果，先放在 Cache 服務中，為了能提升讀取性能。但它是個雙刃劍，用的好，性能升級強無敵，但是用的爛，用戶會不愉悅的。
這個地方基本上我們會以 redis 這種最多人在使用的 Cache 服務應用來進行深入研究。
這個東西基本上是會放在用戶與應用層之間，它和上面的 Cache 服務相同，都是預先將某些東西放在 CDN 上，然後用戶在直接去 CDN 拿就好。
CDN 服務的提供者非常的多，這裡我們會簡單使用 AWS Cloudfront 來進行說明，因為我只用過它。
這個就是我們的目標
基本上可以分成兩個角度來看『用戶』與『開發者』。
根據上述的兩個角度來看，基本上有兩種指標可以來滿足兩方想看的重點。
有時後也稱為延遲(Latency)，概念如下。
Latency 就是你發送一個請求以後，你收到這個結果的時間 ( 越低越好 )。
實際上我們這三十天的其中一個目標就是『最少的延遲時間』。
延遲時間公式，就是下面這張圖，基本上可以包含幾個部份 (這裡先以最基本的 web db 系統來看)。
圖 5 : 簡單版回應時間圖
它的定義如下 :
在一段時間單位內，所能處理的資料量(單位請求或事務) (越高越好)。
基本這個指標，就代表你的系統可以 hold 多少使用量。
它有很多種單位 QPS、TPS，而你的系統用那種單位取決於是那一種服務，假設如果你是資料庫的服務，那基本上就是以 TPS(Transaction Per Second) 來當你的指標，而如果是一般的 Web 服務，那就是用 QPS (Query Per Second) 或是 HPS(Http Per Second)。
基本上這幾個的基本單位會解釋為 :
每秒鐘可以處理 n 個 Http request 或 Query 或 Transaction
基本計算公式如下 :
QPS = 併發數/平均回應時間
所以假設你的系統同一個時間內可以處理 1000 併發數，而平均回應時間為 1 秒，這就代表你系統在 1 秒內可以處理 1000 個請求。
本篇文章簡單的說明以單機為範圍，咱們最基本的系統藍圖如下圖 6 所示 :
圖 6 : 單機基本架構圖
並且也介紹了兩種性能指標 :
而只要這兩個指標越好，基本上也就達成咱們所希望的 :
以最少的資源做最多的事情，這樣才叫高性系統。
而接下來的文章，咱們將要針對每一個地方，一個一個的深入進行深入的探討吧。
那們就正式的開始吧。
iThome鐵人賽
看影片追技術