程序員們的三高：高併發、高性能、高可用

1、高併發

簡介

高併發（High Concurrency）是互聯網分佈式系統架構設計中必須考慮的因素之一，它一般是指，經過設計保證系統可以同時並行處理不少請求。 高併發相關經常使用的一些指標有響應時間（Response Time），吞吐量（Throughput），每秒查詢率QPS（Query Per Second），併發用戶數等。

• 響應時間：系統對請求作出響應的時間。例如系統處理一個HTTP請求須要200ms，這個200ms就是系統的響應時間。
• 吞吐量：單位時間內處理的請求數量。
• QPS：每秒響應請求數。在互聯網領域，這個指標和吞吐量區分的沒有這麼明顯。
• 併發用戶數：同時承載正常使用系統功能的用戶數量。例如一個即時通信系統，同時在線量必定程度上表明瞭系統的併發用戶數。

如何提升併發能力

• 垂直擴展（Scale Up）
  1. 加強單機硬件性能（優先）：例如：增長CPU核數如32核，升級更好的網卡如萬兆，升級更好的硬盤如SSD，擴充硬盤容量如2T，擴充系統內存如128G。
  2. 提高單機架構性能：例如：使用Cache來減小IO次數，使用異步來增長單服務吞吐量，使用無鎖數據結構來減小響應時間。
  3. 總結：管是提高單機硬件性能，仍是提高單機架構性能，都有一個致命的不足：單機性能老是有極限的。因此互聯網分佈式架構設計高併發終極解決方案仍是水平擴展。
• 水平擴展（Scale Out）
  1. 只要增長服務器數量，就能線性擴充系統性能。水平擴展對系統架構設計是有要求的，難點在於：如何在架構各層進行可水平擴展的設計。

2、高性能

簡介

1. 簡單的說，高性能（High Performance）就是指程序處理速度快，所佔內存少，cpu佔用率低。
2. 高併發和高性能是緊密相關的，提升應用的性能，是確定能夠提升系統的併發能力的。
3. 應用性能優化的時候，對於計算密集型和IO密集型仍是有很大差異，須要分開來考慮。
4. 增長服務器資源（CPU、內存、服務器數量），絕大部分時候是能夠提升應用的併發能力和性能 （前提是應用可以支持多任務並行計算，多服務器分佈式計算才行），但也是要避免其中的一些問題，才能夠更好的更有效率的利用服務器資源。

提升性能的注意事項

1. 避免由於IO阻塞讓CPU閒置，致使CPU的浪費。
2. 避免多線程間增長鎖來保證同步，致使並行系統串行化。
3. 免建立、銷燬、維護太多進程、線程，致使操做系統浪費資源在調度上。
4. 避免分佈式系統中多服務器的關聯，好比：依賴同一個mysql，程序邏輯中使用分佈式鎖，致使瓶頸在mysql，分佈式又變成串行化運算。

3、高可用

簡介

高可用性（High Availability）一般來描述一個系統通過專門的設計，從而減小停工時間，而保持其服務的高度可用性(一直都能用)。

• 整年停機不能超過31.5秒，
• 6個9的性能：一直能用的機率爲99.9999%

高可用注意事項

1. 避免單點：使用單個服務器，一旦該服務器意外宕機，將致使服務不可用
2. 使用「集羣」：一臺服務器掛了，還有其餘後備服務器可以頂上
3. 心跳機制：用於監控服務器狀態，掛了就進行故障修復

4、 舉例

Redis的主從複製

1. 應用場景

電子商務網站上的商品，通常都是一次上傳，無數次瀏覽的，說專業點也就是」多讀少寫」。

2. 實現原理

一個Redis服務能夠有多個該服務的複製品，這個Redis服務稱爲Master，其它複製稱爲Slaves。

如圖中所示，咱們將一臺Redis服務器做主庫(Matser)，其餘三臺做爲從庫(Slave)，主庫只負責寫數據，每次有數據更新都將更新的數據同步到它全部的從庫，而從庫只負責讀數據。這樣一來，就有了兩個好處：

1. 讀寫分離：不只能夠提升服務器的負載能力，而且能夠根據讀請求的規模自由增長或者減小從庫的數量。
2. 數據被複製成了了好幾份，就算有一臺機器出現故障，也可使用其餘機器的數據快速恢復。

注意事項：在Redis主從模式中，一臺主庫能夠擁有多個從庫，可是一個從庫只能隸屬於一個主庫。

---

PS：

1. 文章來自各類資源的整理，若有侵權請告知刪除。
2. 轉載本文請註明出處