1 系統概述
人物關系為代理模式，一級代理包含二級代理，二級代理包含三級代理。
需求為實時計算每個用戶的訂單金額，並取出金額的TOP100。
並實時計算當天下級人數。
1.1 指標使用方式
- 單用戶訂單列表查詢：查詢訂單表，不限定日期。
- 當天訂單額top100：查詢指標表對金額排序取前100，限定日期當天。
- 當天下級人數：根據用戶id查詢級別表統計行數，限定日期為當天。
1.2 系統概述
系統離線和實時合二為一，實時只需限定日期為當天，即為實時數據；離線數據只需指定日期即可。
1.3 性能概述
- 計算引擎，Flink是純流式架構，可保證數據的低延遲處理。
- 存儲：此套系統采用HBase+Phoenix作為存儲，適當設計好索引可將查詢延遲控制在2秒以內，tps數量和RegionServer數量呈正相關，此套系統可滿足當前需求。
2 系統目標
1.1 容錯性
對於當天的實時報表，容錯能力詳見處理邏輯。
1.2 可擴展性
此系統增加hbase RegionServer服務器數量對代碼無影響。
1.3 健壯性
此套系統配置，隨着訂單量增加，HBase可支持的數據量可達億級別。若業務暴增，系統磁盤受限，tps到達瓶頸，可適當增加機器節點，同樣對業務代碼無影響。
1.4 吞吐量
月增訂單量大概在500W,單日增量20萬左右，此系統設計至少滿足於1年需求，實際的吞吐量根據集群而定，按照我的設計，集群平均tps在2500左右，目前能滿足該需求。
1.5 數據傾斜
為防止數據傾斜，建表是可對Phoenix進行加鹽或者指定split key。
1.6 一致性
HBase為強一致性，所以不存在並發修改問題。
1.6 高可用性
HBase為集群，基於Hadoop的HDFS，可設置副本集為3，此系統為3台節點，允許宕機一台，若要求高可用級別很高，則需相應增加機器。
3 業務流程
4 系統總體設計
4.1 架構
4.2 表設計
用戶表
- 主鍵：USERID,AGENTID
訂單表
- 主鍵：ORDERID,ordertime
- 二級索引：USERID、shopid、status、totalFee
級別表
- 主鍵：USERID,PT
- 二級索引：childId
指標表
- 主鍵：userid，pt
- 二級索引：totalfee
5 系統功能設計
5.1 數據源
Kafka采用2.X版本，通過參數設置保證消息發送零丟失，但是本系統未涉及kafka相關。
5.2 計算引擎
5.2.1 消息零丟失
Flink checkpoint采用exactly once語義，保證消息只被消費一次，即使Flink意外宕機，也可從檢查點恢復工作。
5.2.2 高可用性
Flink采用Standalone HA安裝模式，可配置多個JobManager，保證Flink集群高可用性。
5.2.3 計算邏輯
- 用戶數據計算邏輯，涉及指標：下級用戶數
- 訂單數據計算邏輯，設計指標：訂單總金額
5.3 存儲
HBase2.0.5采用HA安裝，保證高可用，Phoenix5.0采用全局索引，保證讀寫的速率。
5.4 RESTful
接口使用Spring Boot 2.x編程。
6 硬件配置
HBase
- RegionServer：3台32核128G，
- Master：2台8核32G
Flink
- JobManager：與HBase Master共用機器
- executor：與HBase RegionServer共用機器
磁盤
- 每台機器掛載4*1T硬盤
帶寬
- 至少1G帶寬