背景
接着上篇文章 百億級流量實時分析統計 - 數據結構設計 我們已經設計好了日誌的結構，接下來我們就準備要開始擼代碼了，我最喜歡這部分的環節了，可是一個上來連就擼代碼的程序肯定不是好程序員，要不先設計設計流程圖？那來吧！！！
流程圖
設計一
- 用戶發起文章操作，發起請求日誌
- 日誌將由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進行實現，你想問我什麼嗎？四個字：
[ 百億級流量實時分析統計 - 數據結構設計 ] 上篇 下篇 [編寫當中…]