每天10億次請求的的絕佳乾貨分享
原文：http://h5ip.cn/ev8N
翻譯自jdon社區
印度最大電商公司Snapdeal介紹了其Snapdeal Ads系統支持每天5B請求的經驗分享。
Snapdeal是一家類似於京東和阿里巴巴結合體的電商平臺。獨立商戶可以藉助這個平臺銷售高質量的商品，在Snapdeal出售的商品均爲全新，並且支持七天免費退換。商家進駐Snapdeal後，隨後的事宜（交易、包裝和物流）都將由Snapdeal完成，也就是商家都將成爲Snapdeal的“供貨商”，無需與用戶直接進行交易。
對於只有不到10個工程師的團隊構建一個可伸縮的大型Web系統(web-scale)是困難的，使用正確的技術也許比你的團隊成員數量多少更加重要。
關鍵戰略：
1. 從水平和垂直兩個方面擴展
2.CAP定理中選擇可用性和分區容錯性(AP)，而不是一致性和可用性組合(CA)。因爲初始目標是需要一個低延遲 高性能的拍賣服務平臺。
3.沒有廠商鎖定保護或因爲專利限制使用的情況，開源軟件以前達到毫無疑問的穩定和易用程度，且低費用。因此決定不再使用軟件供應廠商的專有軟件。
4.基於機器同情Mechanical Sympathy法則建立系統，軟件建立在深刻理解硬件工作機理上，通過軟件最大發揮硬件潛能。
5.雲技術的限制使用，因爲亞馬遜EC2比較昂貴，其次是網絡不確定和磁盤虛擬化會提高延遲時間。
6.如果延遲存在就必須處理它，再試圖消除它，所有的查詢應該限制在1ms以下，使用RocksDB和各種其他解決方案作爲初始緩存/嵌入式數據庫。
7.儘可能使用SSD，也是爲了降低延遲。
8.不虛擬化硬件，利用大規模硬件優點（256GB RAM, 24 core）並行化很多計算。
9.磁盤寫操作，如果可能進行計時然後每隔幾秒將一串數據flush寫到到磁盤。
10.Nginx微調到支持keep-alive連接，Netty優化到支持大量併發負載支持模型。
11.關鍵數據對於廣告服務器總是立即可用（微妙級），所有數據都是存儲在內存in-memory的庫或數據結構中。
12.架構應該總是share nothing，至少廣告服務器和外部拍賣系統應該是share nothing，當我們拔掉廣告服務器時，整個系統都不會眨眼受到影響。
13.所有關鍵數據結果必須是可複製的。
14.保持幾天的原始記錄備份。
15.如果數據有點過時和系統不一致，沒有關係。
16.消息系統應該是失敗容錯，可以崩潰但是不能丟失數據。
當前基礎設施：
1.跨3個數據中心的40–50節點。
2.其中是30臺用於高計算(128–256G RAM, 24 cores, 當前頂級CPU，儘可能SSD)
3.其餘小於32G RAM, Quadcore機器.
4.10G私有網絡 + 10G 公共網絡
5.小型 Cassandra, Hbase 和 Spark 集羣.
關鍵性需求：
1.系統支持多個拍賣者發送基於HTTP(REST端口)的RTB 2.0請求。
2.系統應當能在拍賣中推出Yes/No 價格與廣告的響應。
3.系統應當能處理每天數億的事件，響應幾百上千的QPS。
4.數據應該儘可能被處理，至少關鍵點是這樣。
使用的關鍵技術：
1.HBase和Cassandra用於計數據和和管理用戶或賬戶的傳統數據集，選擇HBase是因爲高寫入性能，能夠幾乎實時處理計數。
2.後端主要語言是Java，儘管過去有C++和Erlang經驗，Java有成熟的應用技能，JVM也相當成熟。
3.Google Protobuf 用於數據傳輸
4.Netty作爲後端主要服務器，簡單高性能。
5.RocksDB作爲用戶資料讀寫服務，它是嵌入式數據庫，使用Apache Kafka能夠跨RocksDB同步數據。
6.Kafka是用於消息隊列，流化數據處理
7.CQEngine用於主要的內存in-memory快速查詢。
8.Nginx是主要的反向代理
9.Apache Spark是用戶ML處理
10 Jenkins用於CI
11.Nagio和Newrelic 監視服務器
12.Zookeeper用於分佈式同步
13.Dozens of third parties for audience segments, etc.
14.Bittorrent Sync用於同步跨節點和數據中心的關鍵數據
15.ustom built quota manger based on Yahoo white paper for budget control.
系統設計與結果：
ad服務器是使用簡單非堵塞的netty構建，處理每個進來的HTTP請求，在內存的很多存儲中尋找一個活動進行展示，這是使用CQ Engine查詢，這種查詢並不引發任何網絡延遲，計算時間或堵塞過程比如磁盤寫，將會整個在內存中運行，所有計算會發生在節點內存中，幾乎是in process。
ad服務器和其他系統沒有分享，共同組件是通過異步通訊。
ad服務器以5-15ms延遲的高性能傳遞結果，原始數據異步寫入到Kafka處理。
原始數據被Hbase中多個Java過程消費，預算和活動狀態在Cassandra集羣中更新。
一些原始數據發往spark集羣用於adhoc處理。
