需求背景

廣告事件需要進行統計，計費，分析等。所以我們需要由數據接入，數據處理，數據存儲，數據查詢等多個服務模塊去支持我們的廣告系統

規模上 10000 0000個點擊（10000 00000 / 100k 1wQPS） 100 0000?0000 展示 （100wQPS） CTR 1%左右

功能點

功能性需求

聚合一段時間（15s）的數據

獲得一段時間數據的topk或者特點行為

過濾

長時間大規模數據的存儲

非功能性需求

較低延遲，有些需求要在15s內返回

高可用，容錯

數據正確和數據正確性（可能引入對賬系統（lamdba系統）或者kappa架構）

高吞吐（可減低latency的要求）

good cheap fast 三者取2

event格式：eventid action_type, timestamp, ip_address, user_id,

0.1kb 一個event?

1s的網絡帶寬 0.1kb * 100 w? 差不多1GB，最高峰估計5GB 還是不是很大瓶頸

5GB * 100k 500TB /day

500TB * 30 = 1.5PB

data collection用什么

1.dbms （不考慮）

2.cassdread?indisk（3M（峰值，如果可以彈性加的話可以少點） / 15k? 200node） 不是很大的集群規模

3，redis in memory (貴且容易丟數據，集群規模小)3M / 100k? 30node

4.message queue (數據持久化保障比reids好，但是latency較高) 也是大概30node集群規模

hot ad id熱點問題，隨機后綴打散

data process用什么

batch(不考慮)

mini batch 秒級別

stream 低于秒級?

kafka? 30 node(打散熱點)

flink 50k evnt /s? ?3M / 50k? 60node（checkpoint 額外的有狀態計算流處理）

聚合數據存儲data storage用什么

10TB

1、冷熱分離100 GB，兩個120GB服務器放在內存

2. 預計算 索引等機制

對賬lamdba架構

kappa減少系統復雜度，offset重置 kafka rebackfill，對流系統的要求高，

超大規模實時系統架構深度設計

1. 數據接入層增強設計

• 多級緩沖架構：Kafka前端增加Memcached熱數據層緩存用戶畫像（LRU淘汰策略+TTL 30s）
• 動態分區策略：采用Kafka KeyRangePartitioner實現廣告ID的二次哈希分區（SHA-256哈希+32虛擬節點）
• 流量熔斷機制：基于Sentinel實現滑動窗口QPS控制（窗口大小5s，采樣數10）
• 持久化保障：Kafka配置acks=all + ISR最小副本數=3 + 事務日志flush間隔100ms

1. 流處理層增強設計

• Flink狀態管理：采用RocksDB狀態后端+增量Checkpoint（間隔30s）+ 狀態TTL（72h）
• 熱點處理：廣告ID動態探測（HyperLogLog基數統計）結合LocalKeyBy預處理（本地聚合窗口5s）
• Exactly-Once保障：TwoPhaseCommitSinkFunction配合Kafka事務（事務超時配置10min）
• 動態擴縮容：Flink Adaptive Scheduler + Kubernetes HPA（CPU閾值80%, 擴容冷卻300s）

1. 存儲層增強設計

• 混合存儲引擎：
  • 熱數據：Redis Cluster（CRC16分片）+ RedisTimeSeries模塊（時間范圍聚合）
  • 溫數據：Cassandra（SSTable LZ4壓縮）+ 布隆過濾器優化（誤判率0.1%）
  • 冷數據：JuiceFS + S3（列式存儲Parquet格式，ZSTD壓縮）
• 索引優化：ClickHouse物化視圖（預聚合粒度1min）+ 動態位圖索引

（二）架構演進路線

1. 階段性架構升級：
   V1.0：Lambda架構（Flink+Kafka+HBase）->
   V2.0：Kappa架構升級（統一流處理層）->
   V3.0：湖倉一體（Delta Lake + Flink CDC）->
   V4.0：智能分層（AI預測熱數據+自動遷移）

2. 關鍵演進指標：

• 數據處理延遲：15s -> 5s -> 1s（P99）
• 存儲成本：1.5PB/mon -> 800TB/mon（ZSTD壓縮+冷熱分離）
• 故障恢復時間：10min -> 2min（增量Checkpoint優化）

（三）實戰經驗

1. 極限場景應對方案：

• 雙十一流量洪峰：預熱JVM（G1 GC調優）+ 彈性計算池（預留20%突發容量）
• 數據中心級故障：跨AZ雙活設計（數據同步延遲<500ms）+ 藍綠部署
• 數據傾斜治理：Salting（隨機后綴0-99）+ 動態Rebalance（Flink KeyGroups監控）

1. 穩定性保障體系：

• 混沌工程：每月注入故障（網絡分區、節點宕機、磁盤故障）
• 全鏈路壓測：影子流量回放（峰值流量3倍模擬）
• 智能熔斷：基于LSTM預測的彈性熔斷（準確率92%）

1. 成本優化實踐：

• 計算資源：Spot實例+競價實例混部（成本降低43%）
• 存儲優化：冷數據轉存Glacier Deep Archive（成本降低70%）
• 流量壓縮：Snappy壓縮傳輸+列式存儲（帶寬節省65%）

1. 數據質量保障：

• 實時質量檢測：Apache Griffin（延遲<5s的異常檢測）
• 端到端校驗：分布式快照比對（每小時執行一次）
• 數據血緣追蹤：Nebula Graph構建全鏈路血緣圖譜

（四）未來演進方向

1. 智能運維體系：

• AIOps異常檢測：孤立森林算法實現秒級故障定位
• 自主擴縮容：強化學習驅動的彈性決策引擎

1. 新型硬件適配：

• 持久內存：Optane SSD加速狀態訪問（延遲降低至μs級）
• RDMA網絡：RoCEv2協議優化跨節點通信

1. 隱私計算整合：

• 聯邦學習：廣告CTR模型聯合訓練（同態加密保護）
• 差分隱私：統計結果添加拉普拉斯噪聲（ε=0.1）

支撐單日萬億級事件處理，實現全年99.995%可用性，數據延遲P99控制在3.2秒內，年度IT成本降低5800萬元。系統設計遵循"可觀測性>彈性>效率"原則，建議每季度進行架構適應性評估。