裝置每10分鐘上報一次a指標資料，需要對裝置的a指標資料進行日增量/存量打標。即對於a指標，標記裝置是存量裝置還是增量裝置。在裝置每次上報時進行打標。日存量/增量判斷標準：將當日裝置上報a指標資料的總次數，與該裝置前30天內上報的a指標資料的總次數進行對比。假如前30天內總次數超過n次且當日上報a指標資料的總次數超過n次則為該裝置打存量標記。假如前30天內總次數小於n次且當日上報a指標資料的總次數超過n次則為該裝置打增量標記。
裝置數量上百萬，且都按每10分鐘一次進行指標資料上報。如何在大資料量且高併發的場景下快速的對裝置進行存量/增量標記。
使用redis快取，乙個key對應乙個裝置近30天每天的a指標資料出現次數，可以是乙個json陣列：
[
,...,,
]
在多執行緒和高併發場景下，如果因為前置元件發生訊息堆積，導致一批資料中存在多個同一裝置多條a指標資料報文。而有多個執行緒同時對某個裝置多條a指標資料報文進行處理，使用方式一會存在a指標資料計數總量不準確的情況。考慮在a的整個邏輯之外增加乙個基於redis的有過期時間的分布式鎖。當某個執行緒對指定裝置的a指標進行計數和判斷時，加分布式鎖，其他執行緒遇鎖等待，直到鎖釋放或者過期，再執行增量/存量判斷。
使用定時任務離線非同步的進行處理。持久化每日所有裝置的a指標資料發生次數，某個時間點對當日所有裝置進行判斷，分別比對其前30天的指標總次數，進行打標。
該方法有如下不足：
1.需要開闢更多磁碟空間。
2.定時任務執行時間有限制，需慎重選擇。
3.假如有後置任務需要依賴存量/增量標識，會存在定時任務執行超時或者執行異常導致後置任務受影響的可能。
大資料高併發學習筆記（2）
對於大資料問題，最終都會反饋到資料瓶頸上。那麼今天就是搞得資料庫啦！木桶理論 桶裝水能力是由最短的那塊板決定的。在乙個系統中，或者說是乙個企業裡，資料時最重要的。所以我們是一定要保證資料的正確性，唯一性。資料 二八原則 80 的請求聚焦在 20 的資料上。80 的請求都是查詢 20 是增刪改。讀寫分...
大資料 高併發LVS1
yum search ipvsadm yum install ipvsadm ipvsadm幫助命令 ipvsadm h 管理集群服務 常用的管理命令 管理集群服務的rs e 修改 d t u f service address r server address 刪除 檢視刪除所有集群事務服務 儲存...
針對大資料高併發站點的優化
現今不論是電商 還是熱門論壇或者其他的應用程式都涉及到大資料和高併發問題，例如電商 的秒殺 搶購等等，在此針對自己了解過的資料做個淺顯的總結 主要是關於php開發方向的 大資料處理 層面 1 前端 1 減少大的應用和複雜js的載入，提公升頁面的訪問速度 2 通過js外掛程式等工具實現頁面的延遲載入或...