[[alternative]]Use the MQTT protocol dynamic queue to achieve cost reduction

碩士[[abstract]]在資訊科技的發達下，智慧型手機及載具裝置越來越普及，再加上行動通訊技術也一直在提升，許多裝置都會透過訊息推播的方式來傳遞訊息；在智慧型手機作業系統中，android與ios佔絕大部分，若要透過訊息推播，需向android與ios申請開發者權限，讓在開發過程中變的很繁瑣，籍此本研究利用MQTT協定來取代android與ios的推播方式。MQTT協定必需要自行建置伺服器環境，本研究會採用雲端技術(IaaS)基礎設施即服務平台來建置環境，透過IaaS的虛擬伺服器技術，可以彈性調整伺服器的硬體資源，以及IaaS的管理介面和程式類別庫，可以在短時間內啟動另一台虛擬伺服器來發送訊息。 目前在一般訊息的應用，都沒有針對等級之分的訊息來處理，例如：血糖值檢測。在檢測過程中，正常血糖值會比低血糖及高血糖訊息來的多；在處理高血糖或低血糖訊息時，都必須在短時間內通知診所或是親友，若透過目前常用的佇列演算法來發送血糖訊息，可能會造成訊息的逾時發送，也無達到在用最少伺服器的情況下來發送訊息。在本研究中，會提出自動調配佇列演算法，能針對訊息等級的不同，來發送訊息，並且能在訊息的限制時間內發送；透過自動調配佇列演算法，動態調節佇列來平衡訊息流量，配合IaaS虛擬伺服器計價方式(以小時為單位)，能在用最少伺服器的情況下，減少成本上的支出。 在本研究也會針對所提出的自動調配佇列演算法，進行訊息發送的壓力測試及訊息等級分佈比例測試，希望在測試結果中，達到佇列的自動調配及平衡來處理不同的訊息流量及不同的訊息等級分佈。[[abstract]]Smart phones and sensor devices are proliferating in today’s information technology, and many devices will use push notifications in their messaging. If a user wishes to push a message, Android and iOS, the general smart phone operating systems, require that users apply for a developer role. Since this development process is cumbersome, in this study, we established an MQTT protocol agreement in the IaaS cloud computing platform to replace the current Android & iOS send mode. The algorithms that are now processing queues were not developed to work at the message level, e.g., blood glucose monitoring. If a patient’s blood glucose level is normal, the message timing is reasonable. However, if the blood glucose level becomes emergency, a message must be sent immediately. If we use common queue algorithms to send messages, such as the RR and WRR algorithms, messages may arrive late or require more servers to be transmitted. In this paper, we propose a load-balancing algorithm for medical care applications that can handle messages at the message level as well as adjust and balance the queues and send messages with a minimum of servers, thereby reducing the cost of virtual servers on the IaaS.[[tableofcontents]]目錄 第一章 緒論 1 1.1 研究動機與目的 1 1.2 論文架構 4 第二章 文獻探討 5 2.1雲服務平台技術IaaS(Infrastructure as Service) 5 2.2 MQTT協定 7 2.3 佇列演算法 11 2.3.1 先進先出First-Come First-Served 11 2.3.2 優先順序 Priority Queue 12 2.3.3 循環執行順序Round Robin 12 2.3.4 權重循環執行順序 Weighted Round-Robin 13 第三章 研究方法 14 3.1 系統架構 15 3.2 系統流程 17 3.3 選擇發送訊息的佇列 19 3.4 檢查佇列是否進行切換 20 3.5 合併佇列 23 3.6 啟動及關閉MQTT伺服器 26 第四章 系統實作結果 27 4.1 單一及多個佇列訊息壓力測試 28 4.2 正常訊息流量的佇列切換測試 30 4.3 訊息等級分佈比例測試 34 4.4 短時間內訊息等級分佈測試 41 4.5 同時間內訊息等級分佈測試 43 4.5.1 同時間點發送訊息的訊息等級分佈 44 4.5.2 訊息流量由小到瞬間變大(同時間點) 47 4.5.3 訊息流量由大到瞬間變大(同時間點) 50 第五章 結論及未來研究方向 52 5.1 結論 52 5.2 未來研究方向 53 參考文獻 54 附錄—英文論文 56 圖表目錄 圖 1.MQTT 發佈端及訂閱端訊息傳遞方式 7 圖 2.Qos 0傳遞方式 8 圖 3.Qos 1傳遞方式 9 圖 4. Qos 2傳遞方式 10 圖 5.訊息發送架構圖 15 圖 6.系統流程圖 18 圖 7.平衡佇列演算法 19 圖 8.佇列切換示意圖 20 圖 9.佇列切換示意圖 21 圖 10.佇列切換演算法 22 圖 11.大量的緊急訊息流量 23 圖 12.緊急訊息流量變小 24 圖 13.合併佇列 25 圖 14.單一及多個佇列訊息壓力測試 28 圖 15.正常訊息流量發送訊息結果 30 圖 16.正常訊息流量 31 圖 17.瞬間訊息流量發送訊息結果 32 圖 18.瞬間訊息流量發送訊息結果切換前 32 圖 19.瞬間訊息流量發送訊息結果切換後 33 圖 20. 500/s總數的比例70% 35 圖 21. 500/s訊息總數的比例80% 35 圖 22. 500/s訊息總數的比例90% 36 圖 23. 500/s訊息總數的比例100% 36 圖 24. 500/s訊息總數的比例110% 37 圖 25. 500/s訊息總數的比例120% 38 圖 26. 500/s訊息總數的比例130% 38 圖 27. 500/s訊息總數的比例140% 39 圖 28. 500/s訊息總數的比例150% 39 圖 29. 500/s訊息總數的比例160% 40 圖 30. 500/s訊息總數的比例170% 40 圖 31. 1000/s訊息總數的比例70% 41 圖 32. 1000/s訊息總數的比例80% 41 圖 33. 1000/s訊息總數的比例90% 42 圖 34. 1000/s訊息總數的比例100% 42 圖 35. 同時間1000訊息總數的比例70% 44 圖 36. 同時間1000訊息總數的比例80% 44 圖 37. 同時間1000訊息總數的比例90% 45 圖 38. 同時間1000訊息總數的比例100% 45 圖 39. 訊息流量由小到瞬間變大 47 圖 40. 訊息流量由大到瞬間變大 50 表目錄 表 1. 訊息每秒平均輸入速度500則訊息 30 表 2. 訊息每秒平均輸入速度1000則訊息 31 表 3. 計算訊息瞬間最大值 34 表 4. 擷取每秒平均500則(緊急、一般)訊息處理時間 48 表 5. 擷取同時間700則(緊急、一般)訊息處理時間 49[[note]]學號: 704410066, 學年度: 10