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頻寬