背景
接著上篇文章 百億級流量實時分析統計 - 資料結構設計 我們已經設計好了日誌的結構,接下來我們就準備要開始擼程式碼了,我最喜歡這部分的環節了,可是一個上來連就擼程式碼的程式肯定不是好程式設計師,要不先設計設計流程圖?那來吧!!!

流程圖

設計一
- 使用者發起文章操作,發起請求日誌
- 日誌將由SLB伺服器進行負載到日誌打點伺服器。
- NSA將作為日誌收集中心進行儲存,也可以使用
rsync
把節點上的日誌同步到日誌中心。 - 作為核心的
ETL
程式,將要對日誌中心上所有節點的資料進行抽取轉換載入。 - 上圖中出現的Hbase比較好理解,但是為什麼要出現
Mysql
?因為我們要更細粒度地控制日誌的寫入時間點,主要用來記錄日誌時間的offset,後續會有詳細的介紹。
設計二
- 使用者發起文章操作,發起請求日誌
- 日誌將由SLB伺服器進行負載到日誌打點伺服器。
- Filebeat 收集節點日誌 到Kafka,主要是用來日誌削峰使用。
**或者:**使用
nginx
直接將日誌寫入kafka,因為nginx
也是生產級別的。 - ETL 將消費Kafka 資料並寫到Hbase。
- 與設計一相同
日誌中心
日誌中心的儲存會是下面這樣
├── log
│ ├── 2019-03-21
│ │ ├── 111.12.32.11
│ │ │ ├── 10_01.log
│ │ │ └── 10_02.log
│ │ ├── 222.22.123.123
│ │ │ ├── 0_01.log
│ │ │ ├── 0_02.log
│ │ │ └── 0_03.log
│ │ └── 33.44.55.11
│ ├── 2019-03-22
│ └── 2019-03-23
複製程式碼
- 每分鐘每節點會生成一個檔案。
- 一天一個資料夾。
- 這樣子的設計可以方便查錯。
日誌內容如下
{"time":1553269361115,"data":{"type": "read","aid":"10000","uid":"4229d691b07b13341da53f17ab9f2416","tid": "49f68a5c8493ec2c0bf489821c21fc3b","ip": "22.22.22.22"}}
{"time":1553269371115,"data":{"type": "comment","content":"666,支援一下","aid":"10000","uid":"4229d691b07b13341da53f17ab9f2416","tid": "49f68a5c8493ec2c0bf489821c21fc3b","ip": "22.22.22.22"}}
複製程式碼
敲定方案
選擇設計一 因為我們就看上了第5點,線上上業務穩定了一年的使用情況來看,這種方案是可行的。
在下篇文章中,我們將真實開始擼我們的黃金程式碼了,所有程式將使用scala
進行實現,你想問我什麼嗎?四個字:

