SSIO項目中實踐應(yīng)用分析

本文小編為大家詳細介紹“SSIO項目中實踐應(yīng)用分析”，內(nèi)容詳細，步驟清晰，細節(jié)處理妥當，希望這篇“SSIO項目中實踐應(yīng)用分析”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學(xué)習(xí)新知識吧。

一、項目背景

     我們是傳統(tǒng)行業(yè)，但是我們有一顆不傳統(tǒng)的心。企業(yè)用戶遍布國內(nèi)和國外，面對行業(yè)，要建設(shè)行業(yè)級的（大）數(shù)據(jù)平臺。一提到大數(shù)據(jù)平臺，大家往往想到Hadoop、Spark、Nosql、分布式等等，我只能說我們還比較低級，但是后期肯定會涉及到這些技術(shù)。做大數(shù)據(jù)平臺是有風險的，拋開絕技術(shù)方面，應(yīng)該從四個方面來考慮這個問題：企業(yè)思維的轉(zhuǎn)變、是否解決實際問題、是否落地可實施、是否有增值效應(yīng)。

    不轉(zhuǎn)變思維，企業(yè)不死，個人死。為什么呢？戰(zhàn)略定力差，推進動力不足，隨時面臨PASS的風險。

    不能解決實際問題，那只是空中樓閣，創(chuàng)造不了實際的價值，變現(xiàn)也很困難，忽悠人是不能長久的。

    不能落地可實施，要么是團體不行，要么是技術(shù)不行，總之還是團隊不行，帶頭人不一定什么都懂，但是要有絕對的推進能力。

    不能有增值效應(yīng)，最終最不到錢，這是任何人都不愿意看到的情況。再美的女人，不能生孩子，你也要多顧慮一些。所以我大學(xué)同學(xué)找對象的第一原則，就是能生孩子。

二、數(shù)據(jù)情況

     全國大概有238個站點，不包括國外。每個站點大概有2000個傳感器，5分鐘上傳一次數(shù)據(jù)，相當于1秒鐘要傳7個點的傳感器。在大數(shù)據(jù)平臺再進行數(shù)據(jù)的深度分析，幫助生產(chǎn)企業(yè)改進生產(chǎn)工藝，以及安全防范。

三、通訊協(xié)議

    通訊協(xié)議主要從指令要求、傳輸流程、通訊層級、應(yīng)答模式、重發(fā)機制、超時界定、數(shù)據(jù)完整性、通訊效率、代碼和字典定義等，進行綜合考慮，有些是用技術(shù)實現(xiàn)的，有些是用協(xié)議保障的……。

    通訊協(xié)議命令包如下：

四、緩存機制

     避免頻繁的操作數(shù)據(jù)庫，在上傳數(shù)據(jù)端和接收數(shù)據(jù)端進行了緩沖設(shè)計，作為臨時數(shù)據(jù)的存儲，當然這些臨時數(shù)據(jù)也可以保存在Hadoop上，前期沒有打算這樣做。

     客戶端緩存結(jié)構(gòu)圖：

服務(wù)端緩存結(jié)構(gòu)圖：

五、通訊層面的框架

      服務(wù)端使用的是SeverSuperIO（SSIO），并沒有使用其他的框架。一是考慮到不同協(xié)議的接入，二是方便對站點的通訊狀態(tài)、IO狀態(tài)，以及站點進行管理。客戶端就是自己寫的控制臺程序。

六、問題及解決

（1）    第一天客戶端與服務(wù)端進行測試的時候，第二天發(fā)現(xiàn)客戶端直接崩了，提示：OutOfMemoryException。經(jīng)排查，再測試至今還沒有出現(xiàn)問題。可能是因為線程并且對數(shù)據(jù)操作引起的。

（2）    測試過程中，發(fā)現(xiàn)接收到的數(shù)據(jù)開頭和結(jié)尾都對，但是就是解析數(shù)據(jù)包為空。這個問題是因為CRC16校驗與結(jié)尾字節(jié)數(shù)據(jù)組重復(fù)了，SeverSuperIO（SSIO）在過濾數(shù)據(jù)的時候，少了兩個字節(jié)。后來把CRC16校驗改成了校驗和。

七、測試效果

     測試12小時，如下圖：

讀到這里，這篇“SSIO項目中實踐應(yīng)用分析”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領(lǐng)會，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注億速云行業(yè)資訊頻道。