大屏技術演進-拉模式

1、背景

產品經理：咱們要實現以下的一個形以下圖的一個大屏需求，目前咱們全部的日誌數據都在庫裏面，應該不是很難吧

圖片來源與網絡，若是侵權請及時聯繫刪除

技術小哥哥：嗯，難道是不難，我要回去看看日誌的數據量，而後再製定對應技術方案，而後在一塊兒評審，接下來就是作需求分析和技術方案了。

這種技術需求應該在一些to b的公司業務是比較常見的，很榮幸本身參與系統的大屏從1.0到2.0的升級操做

2、需求分析

與前端定義格式

一期由於時間關係，就採用的是http+json定時拉取的方式獲取，這個方式在不少場景下面是很是好的，由於http協議成熟與穩定，json格式比較大衆，如今基本的語言都支持對應的編碼操做。

後端技術方案

1. 每次請求直接從日誌表來進行數據獲取。
2. 使用腳本將日誌數據生成一份基礎數據，而後給前端直接調用。
3. 用消息隊列進行訂閱/推送模式，增長一個新的topic供大屏業務使用，後續與第二個方案差很少，也是生成一個基礎數據存儲在庫裏面。
4. 根據頁面的條件，生成每一個組合條件的數據供前端調用，這裏會藉助redis來進行存儲，至於爲何使用redis，這裏不進行介紹了，社區有不少關於redis介紹文章。

1-3其實均可以理解爲一種拉模式，由於都是在請求時候進行前端數據的組合，至於2-3僅僅是將數據進行壓縮減少，好比減少到分鐘級別，畢竟通常日誌數據都是秒級別的。

4實際上是一種推模式，若是直接使用http，在後臺邏輯是拉，對於前端也是拉，這種方案通常會使用websocket進行推模式的獲取，這個會在 下一篇 文章進行描述

3、技術方案制定

本篇文章不會有代碼實現來作，由於講原理方案，任何後端語言都是能夠拿來實現的。

一、前端請求，後端直接拉日誌數據統計

    優勢：

• 簡單方便，能夠直接發起ajax請求就能夠獲取數據
• 後端也方便，而且不須要改動太多原來的表存儲方法，不須要擴展表數據

    缺點：

• 數據量大，就會知道你是在考驗數據庫的承受能力了
• 條件太多狀況下，及時你設置了每一個條件模塊的緩存，可是大屏數據及時性比較高，緩存命中率低，因此這個方案下面緩存設置沒有太多意義

    流程圖：

    流程說明：

1. 終端進行日誌請求上報，請求的日誌通過贊成網關的認證以及基礎的字段校驗，校驗經過後將數據寫入到消息隊列裏面。
2. 開啓一個消費者，持續消費消息隊列裏面數據，將消息隊列的數據異步寫入到數據庫裏面，這裏使用異步消費其實就是將大量併發的終端請求作一個控制處理，防止大量請求直接穿透到數據庫，數據庫資源在整個系統架構中是比較寶貴的，最好不要由於請求的激增出現宕機狀況。
3. 前端大屏發起數據請求，直接到咱們的web服務器，web服務器經過反向代理方式給到咱們服務端業務邏輯服務器，服務端業務邏輯服務器直接從數據庫拉取數據分析聚合再返回

二、後端使用腳本生成每分鐘數據，供前端接口調用

    優勢：

• 簡單方便，能夠直接發起ajax請求就能夠獲取數據

• 會比上面的方案少不少數據，特別是在每分鐘密集型日誌上，由於原來一分鐘估計會有1w條記錄，而用異步腳本生成後就是一條了，在後續的前端請求邏輯上，作出的響應會更及時。

    缺點：

• 須要額定擴展一張統計表，有維護額外統計表的成本
• 這裏只是減小了數據的一個條數，當業務需求須要到秒級別的時候，這個方案又是一個積累的存在了

   流程圖：

流程說明（與第一個在收集過程一致，再也不贅述）：

• 當日志收集入庫後，咱們會有定時腳本任務將日誌的數據讀取出來進行分析聚合存儲到咱們的統計表裏面。
• 前端的邏輯在請求過來後，就不會在日誌庫進行讀取了，而是直接去了已經統計好的數據表，這個統計好區別後面文章說的按條件區分好的統計數據。

三、消息隊列方式進行異步統計數據，供前端接口調用

    優勢：

• 前端層面來說，調用仍是比較方便的
• 由於是異步進行數據統計，因此不會影響總體的前端請求的響應時間，對應cpu和內存佔用暫時不在這考慮，這裏主要是由於進程間已經隔離

    缺點：

• 與第二個同樣，須要增長一個統計表，對於統計表的維護問題
• 這裏也是減小了數據的個數條數的問題，對於產品來說，時間粒度更改成每秒，整個表的統計粒度就gg了
• 增長了消息隊列組件，整個系統架構上會複雜一點，固然如今通常系統消息隊列是標配了，因此這個缺點也是最不起眼的缺點了

    流程圖

    流程說明：

1. 收集與第一個方案不同在於，咱們同時會入兩個隊列，固然在一些支持多播的消息隊列徹底能夠共用哈，固然若是是服務化架構的話，統計與收集應該不會同一個服務了
2. 統計隊列的消費者獲取到數據後，進行統計邏輯直接入了統計表，供前端接口來調用。

4、總結

• 咱們這裏都沒有使用緩存來作一些防止數據穿透問題，固然在現實方案部署確定有緩存來作，這裏沒作是由於對於總體方案架構來說沒必要過於複雜了，固然在大屏的需求上，其實前端請求的緩存麼有太大做用，咱們要的基本是實時數據，而緩存基本都是歷史的數據
• 總體的三個方案，咱們第一期選擇的是第二個方案，第一個太過於簡單粗暴了，數據庫扛不住；固然第三個其實與第二個也差很少，若是需求要求比較準確點的話，好比要精確到秒，第三個也是能夠的，而咱們需求恰好是精確到分，這就不必每一個日誌來都要進行數據統計操做
• 世界上沒有最優的方案，只有最適合需求的技術方案，固然需求不合理，仍是能夠好好反駁的。

5、思考

• 咱們這篇文章基本用的是拉數據方式，能夠理解爲，咱們的前端須要的數據邏輯都是在請求同步來獲取的，若是這個大屏條件比較單一，其實這個方案是沒有太大問題的，畢竟簡單一點，因此咱們定義爲1.0版本方案。
• 那麼若是咱們有條件選擇呢？若是咱們要看： 24小時數據 、1小時數據 、30分鐘數據，這是咱們下一期須要講的一個技術方案，期待咱們的新技術方案