一、項目背景
我們是傳統行業，但是我們有一顆不傳統的心。企業用戶遍布國內和國外，面對行業，要建設行業級的（大）數據平台。一提到大數據平台，大家往往想到Hadoop、Spark、Nosql、分布式等等，我只能說我們還比較低級，但是後期肯定會涉及到這些技術。做大數據平台是有風險的，拋開絕技術方面，應該從四個方面來考慮這個問題：企業思維的轉變、是否解決實際問題、是否落地可實施、是否有增值效應。
不轉變思維，企業不死，個人死。為什麼呢？戰略定力差，推進動力不足，隨時面臨PASS的風險。
不能解決實際問題，那只是空中樓閣，創造不了實際的價值，變現也很困難，忽悠人是不能長久的。
不能落地可實施，要麼是團體不行，要麼是技術不行，總之還是團隊不行，帶頭人不一定什麼都懂，但是要有絕對的推進能力。
不能有增值效應，最終最不到錢，這是任何人都不願意看到的情況。再美的女人，不能生孩子，你也要多顧慮一些。所以我大學同學找對象的第一原則，就是能生孩子。
二、數據情況
全國大概有238個站點，不包括國外。每個站點大概有2000個傳感器，5分鐘上傳一次數據，相當於1秒鐘要傳7個點的傳感器。在大數據平台再進行數據的深度分析，幫助生產企業改進生產工藝，以及安全防范。
三、通訊協議
通訊協議主要從指令要求、傳輸流程、通訊層級、應答模式、重發機制、超時界定、數據完整性、通訊效率、代碼和字典定義等，進行綜合考慮，有些是用技術實現的，有些是用協議保障的……。
通訊協議命令包如下：
四、緩存機制
避免頻繁的操作數據庫，在上傳數據端和接收數據端進行了緩沖設計，作為臨時數據的存儲，當然這些臨時數據也可以保存在Hadoop上，前期沒有打算這樣做。
客戶端緩存結構圖：
服務端緩存結構圖：
五、通訊層面的框架
服務端使用的是SeverSuperIO（SSIO），並沒有使用其他的框架。一是考慮到不同協議的接入，二是方便對站點的通訊狀態、IO狀態，以及站點進行管理。客戶端就是自己寫的控制台程序。
六、問題及解決
（1） 第一天客戶端與服務端進行測試的時候，第二天發現客戶端直接崩了，提示：OutOfMemoryException。經排查，再測試至今還沒有出現問題。可能是因為線程並且對數據操作引起的。
（2） 測試過程中，發現接收到的數據開頭和結尾都對，但是就是解析數據包為空。這個問題是因為CRC16校驗與結尾字節數據組重復了，SeverSuperIO（SSIO）在過濾數據的時候，少了兩個字節。後來把CRC16校驗改成了校驗和。
七、測試效果
測試12小時，如下圖：
