乙個系統的吞度量（承壓能力：系統在單位時間內處理請求的數量，體現系統整體處理能力）與request對cpu的消耗、外部介面、io等等緊密關聯。單個request對cpu消耗越高，外部系統介面、io影響速度越慢，系統吞吐能力越低，反之越高。吞度量常用量化指標有每秒事務數tps、每秒查詢率qps、每秒http請求數hps。
系統吞吐量幾個重要引數：每秒查詢率qps、併發數、響應時間rt。
每秒查詢率 qps：對乙個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準，在網際網路上，作為網域名稱系統伺服器的機器的效能經常用每秒查詢率來衡量。對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。
pv(page view)即頁面瀏覽量：使用者每1次訪問網頁均被記錄1次。
1）平均併發使用者數c=nl / t
n是平均每天訪問使用者數（login session），l是一天內使用者從登入到退出的平均時間（login session的平均時間），t是考察時間長度（一天內多長時間有使用者使用系統）
2）併發使用者數峰值≈c + 3 *（根號c）
舉例假設系統a，該系統有3000個使用者，平均每天大概有400個使用者要訪問該系統（可以從系統日誌從獲得），對於乙個典型使用者來說，一天之內使用者從登陸到退出的平均時間為4小時，而在一天之內，使用者只有在8小時之內會使用該系統。
平均併發使用者數為：c = 400*4/8 = 200
併發使用者數峰值為：≈200 + 3*根號200 ≈ 200 + 3*14.1≈ 242
3）吞吐量，指單位時間內系統處理使用者的請求數
從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量。從網路角度看，吞吐量
可以用：位元組/秒來衡量。對於互動式應用來說，吞吐量指標反映的是伺服器承受的壓力，他能夠說明系統的負載能力。
當沒有遇到效能瓶頸的時候，吞吐量與虛擬使用者數之間存在一定的聯絡，可以採用以下公式計算：
tps=(虛擬使用者個數vu * 每個虛擬使用者發出的請求數r )/效能測試所用的時間t
tps=每個虛擬使用者發出的請求數r × 系統的併發使用者數c
4）思考時間的計算公式
think time，從業務角度是指使用者進行操作時每個請求之間的時間間隔，在做效能測試時，模擬這樣的時間間隔，更加真實的
模擬使用者的操作。
每個虛擬使用者發出的請求數r = 效能測試所用的時間t / 思考時間tt
1）使用者關注的是使用者操作的相應時間。
2）管理員的角度考慮需要關注的效能點。
相應時間、伺服器資源使用情況是否合理、
應用伺服器和資料庫資源使用是否合理、系統能否實現擴充套件、
系統最多支援多少使用者訪問、系統最大業務處理量是多少、
系統效能可能存在的瓶頸在**、 更換那些裝置可以提高效能、
系統能否支援7×24小時的業務訪問
3）開發（設計）人員角度去考慮。
架構設計是否合理、 資料庫設計是否合理、
**是否存在效能方面的問題、 系統中是否有不合理的記憶體使用方式、
系統中是否存在不合理的執行緒同步方式、系統中是否存在不合理的資源競爭
1）流控：後台服務可以支撐的最大併發量，雖然理論上可以通過新增節點（機器）的方法橫向擴充套件，即擴容，但考慮到成本通常後台服務都會存在乙個預估的能力上限。後台服務的最大支撐能力低於了實際使用者的請求量，那麼對後台系統造成的影響可能就如同ddos攻擊，嚴重的話整個後台服務都會出現不可用，根據業務場景定製合理的流控策略。
2）負載均衡：閘道器層除了流控功能外，還有乙個重要的balance load的作用。將大量使用者的請求通過負載均衡策略合理地分發給後端節點。每個節點分配不同的權重。
3）接入層：通過閘道器層執行一些基礎的流控策略，然後再由閘道器層將請求**給後端的接入層。接入層主要實現一些業務層面的基本校驗功能，比如登入態校驗。可過濾大部分非法請求，為合法的使用者請求留出有限的後台資源。通常接入層都是無狀態的，可橫向擴充套件。
4）邏輯層:根據「前輕後重」的原則，接入層一般只執行一些輕量的業務邏輯，真正核心的業務邏輯放在邏輯層來實現。邏輯層是真正核心處理的模組，它的處理能力決定了整個服務的質量，因此邏輯層的設計非常重要。設計原則：縮短關鍵業務流程、降低單個介面處理時耗、同步變異步、隔離。
5）儲存層儲存層主要解決的是資料快速訪問，大資料量如何儲存，以及資料一致性安全問題。對應的解決方案分別是快取，分庫分表，資料如何同步備份。
Twitter 高併發高可用架構
解決 twitter的 問題 就像玩玩具一樣，這是乙個很有趣的擴充套件性比喻。每個人都覺得 twitter很簡單，乙個菜鳥架構師隨便擺弄一下個可伸縮的 twitter就有了，就這麼簡單。然而事實不是這樣，twitter的工程副總裁 raffi krikorian細緻深入的描述了在 twitter在可...
Twitter 高併發高可用架構
解決 twitter的 問題 就像玩玩具一樣，這是乙個很有趣的擴充套件性比喻。每個人都覺得 twitter很簡單，乙個菜鳥架構師隨便擺弄一下個可伸縮的 twitter就有了，就這麼簡單。然而事實不是這樣，twitter的工程副總裁 raffi krikorian細緻深入的描述了在 twitter在可...
Redis高併發和高可用
如何保證 redis 的高併發和高可用？redis 的主從複製原理能介紹一下麼？redis 的哨兵原理能介紹一下麼？其實問這個問題，主要是考考你，redis 單機能承載多高併發？如果單機扛不住如何擴容扛更多的併發？redis 會不會掛？既然 redis 會掛那怎麼保證 redis 是高可用的？其實針...