近來做了乙個大屏的大專案（效果類似於下圖的那種），說是要做到資料實時，甚至把物聯網的那一套東西都接進來實時監控！！！
（大屏指揮中心效果圖，來自dreamstime.com）
最後在徵求多方專家的建議，綜合評估各大方面的情況後後得出一方案是：
其實，這樣從資料產生，直到前端顯示，差了好幾分鐘。
資料**。資料**可以很多，可以來自kafka、db、日誌檔案等。
通過spark streaming或storm等實現比較實時流獲取分析資料。非實時要求的資料，可以由etl工具處理落地。
對要求實時更新顯示的資料，spark每處理處理完一批以後，使用mq+websocket通知到前端進行更新。
前端因為不是面向社會大眾，所以可以指定使用支援websocket的瀏覽器。通過websocket與伺服器通訊，能夠及時得知資料動態。而重新整理資料，仍然使用rest的方式，h5頁面只關心和處理自己關注的事件，並進行重新整理就可。同時，通過定時重新整理功能，也可以支援非websocket的瀏覽器正常的使用。
有時間上**。。。
當然，並不是所有的最新最好的技術就是最好的解決方案。還要綜合人力物力需求等各方面的情況，評估出最合適的方案
關於學習的一點想法
上了十幾年學，才發現自己很多本質的問題從來沒有想過。人類在發展過程中會遇到各種各樣的問題，面對各種各樣的問題，人們提出了各種解決方法。但是如果不用文字記錄下來，讓更多的人看到，實現知識的傳播，那麼未來的人類面對相同的問題就會一臉懵逼，然後花很多重複時間解決乙個解決過的問題。所以人類把各種問題的解決方...
關於CTFT DTFT DFT的一點想法
關於ctft dtft dft dfs等概念的理解一直是模模糊糊 似是而非的，近日忽然就咂摸到了一點滋味，簡單記錄一下，正確性不敢保證。考慮到計算機只能處理時域離散 頻域離散的訊號，因此時域連續或頻域連續的訊號，計算機無法直接處理 這是大前提 因此需要對連續的訊號進行離散處理，這就需要用到衝激串了 ...
關於工作的一點想法
最近基於spring cloud在做乙個支付閘道器的功能。基於 兩 個服務 格式化服務與子支付服務。格式化服務 接受所以平台的請求，提供公共介面，實現在內部呼叫不同平台的子服務介面。子支付服務 針對不同的支付平台提供相關的支付功能。因為剛剛起步，所以就以剛接觸的第乙個子服務為基礎建立了格式化服務。然...