如何擴充套件大規模Web網站的效能？

banq發表於2015-06-27
套件Web網站
Reduce Data廣告服務網站如何擴充套件到每天300K QPS請求？分享經驗如下：

1. 為大規模設計，廣告服務平臺從一開始增長就很驚人，因此，系統開始就為大規模設計，系統為水平和垂直伸縮擴充套件。

2.選擇CAP定理中的AP（可用性和分割槽容錯性）二不是CA（一致性和可用性），因為廣告拍賣與服務平臺是追求低延遲和高效能，資料的高一致性不是非常關鍵。

3.沒有鎖定專門廠商軟體或專利技術的限制使用，積極使用開源軟體，開源軟體已經達到非常成熟的程度。

4.基於Mechanical Sympathy（順硬體之勢而為）構建系統，一個軟體的建立應該是基於理解硬體如何工作以及如何更好利用硬體。

5.雲技術的限制使用，他們很早就決定對雲技術的有限使用，因為a)EC2和計數部分往往非常昂貴；b)在對EC2早期的測試中發現網路抖動jitter、磁碟虛擬化等會增加延遲。

6. 延遲總是存在，對付它而不是設法消除它。所有查詢都應該發生在1ms以下。 利用RocksDB和各種其他解決方案作為主要的快取/嵌入式資料庫。

7.使用SSD固態硬碟降低延遲

8.沒有虛擬化硬體，充分利用高配置硬體(256G記憶體和24核機器)並行化許多計算。

9.磁碟寫操作，每N秒定時flush寫入大塊資料

10.Nginx用於支援keep-alive連線，而Netty最佳化支援大型併發負載。

11.為了保證廣告伺服器中關鍵資料始終是立即可用(訪問延遲以微秒計)，所有這些資料都是儲存記憶體中庫/資料結構中。

12.架構應該使用share nothing，當我們增減伺服器時，系統應該是絲毫不受影響，眼睛都不會眨一下。

13.所有關鍵資料 結果都需要複製。

14.保持每天的原始記錄日誌複製

15.如果資料有點髒，系統發生資料不一致性，這一切也是正常

16.訊息系統應該是容錯的，它們可以崩潰但是不會丟失資料。


下面是具體設施情況：
跨3個資料中心的40–50節點(primarily US and two nodes in Germany)

其中30臺執行高計算 (128–256G RAM, 24 cores, top of the line CPUS and where possible SSDs)

其餘機器配置低一些， 32G RAM, Quadcore 機器.

10G 私有網 + 10G 公網

小型 Cassandra, Hbase 和 Spark 叢集.


使用關鍵技術是：

1.HBase 和 Cassandra 用於計數聚合，以及管理使用者和賬號資料集， Hbase 因為其高效能寫操作，能夠很好處理計數器，並提供近實時的分析。

2.後端主要語言是 Java. 儘管有C++ 和 Erlang經驗，但是Java有更可用的成熟技巧以及過去幾年JVM相當成熟。

3.使用Google Protobuf進行資料傳輸

4. Netty作為主要後端伺服器，感謝其簡單和高效能特點。

5.RocksDB作為使用者配置讀寫， 它是一個嵌入在每個廣告出價人中的嵌入式資料庫，使用者配置透過Apache Kafka跨RocksDB同步資料。

6. Kafka作為主要的訊息佇列，流化資料處理。

7.CQEngine作為主要的基於記憶體 快速查詢系統，使用原子物件儲存資料。

8. Nginx作為主要的反向代理.

9. Apache Spark用於為ML機器學習處理而需要的快速資料處理。

10.Jenkins 使用者CI持續整合

11. Nagios 和 Newrelic用於監視伺服器。

12. Zookeeper用於分散式同步。

13. Dozens of third parties for audience segments, etc.

14. Bittorrent Sync用於跨節點和資料中心同步關鍵資料。

15. 基於雅虎白皮書的預算控制定製的配額管理。


最後，他們在提高改進部分提到了引入LMax的Disruptor框架進行預先聚合，提高跨RocksDB資料的內部複製方式。


How we scaled: 300K QPS & 3-5B requests a day — Me

相關文章