mqtt（message queuing telemetry transport，訊息佇列遙測傳輸）
一種針對移動終端裝置的基於tcp/ip的發布/訂閱協議
可以連線大量的遠端感測器和控制裝置
mqtt的特點是可以保持長連線，具有一定的實時性
要保持長連線，那麼就要不時地傳送心跳包，這就不會省電
特點：
使用發布/訂閱訊息模式，提供一對多的訊息發布，解除應用程式耦合
有三種訊息發布服務質量(qos)：
「至多一次」，訊息發布完全依賴底層 tcp/ip 網路，會發生訊息丟失或重複，這一級別可用於對採集資料要求不嚴格的情況
「至少一次」，確保訊息到達，但訊息可能會重**生
「只有一次」，確保訊息只到達一次，這一級別可用於要求嚴格如涉及計費系統的情況，訊息重複或丟失都是不允許的
mqtt中有3個角色：
發布者publisher
訂閱者subscriber
**broker
mqtt這種結構替代了傳統的客戶端/伺服器模型，可以實現以下解耦：
空間解耦，發布者和訂閱者不需要知道對方
時間解耦，發布者和訂閱者不需要同時執行（離線訊息）
同步解耦，發布和接收都是非同步通訊，無需停止任何處理
mqtt協議的中心是mqtt伺服器或** (broker)：
mqtt與其他協議
mqtt與tcp socket
雖然mqtt執行於tcp層之上，看起來這兩者之間根本沒有比較性，但筆者覺得還是有必要敘述一番，因為大多數從事硬體或嵌入式開發的工程師，都是直接在tcp層上通訊的。從事嵌入式開發工作的人都應該知道lwip，lwip是一套用於嵌入式系統的開放源**tcp/ip協議棧，lwip在保證嵌入式產品擁有完整的tcp/ip功能的同時，又能保證協議棧對處理器資源的有限消耗，其執行一般僅需要幾十kb的ram和40kb左右的rom。
也就是說，只要是嵌入式產品使用了lwip，就支援tcp/ip協議棧，進而可以使用mqtt協議。
由於tcp協議有粘包和分包問題，所以傳輸資料時需要自定義協議，如果傳輸的資料報超過mss（最大報文段長度），一定要給協議定義乙個訊息長度字段，確保接收端能通過緩衝完整收取訊息。乙個簡單的協議定義：訊息頭部+訊息長度+訊息正文。
當然，使用mqtt協議則不需要考慮這個問題，這些mqtt都已經處理好了，mqtt最長可以一次性傳送256mb資料，不用考慮粘包分包的問題。
總之，tcp和mqtt本身並不矛盾，只不過基於socket開發需要處理更多的事情，而且大多數嵌入式開發模組本身也只會提供socket介面供廠家自定義協議。
mqtt與http
http最初的目的是提供一種發布和接收html頁面的方法，主要用於web。http是典型的c/s通訊模式：請求從客戶端發出，服務端只能被動接收，一條連線只能傳送一次請求，獲取響應後就斷開連線。該協議最早是為了適用web瀏覽器的上網瀏覽場景而設計的，目前在pc、手機、pad等終端上都應用廣泛。由於這樣的通訊特點，http技術在物聯網裝置中很難實現裝置的反向控制，不過非要實現也不是不行，下面看一下web端的例子。
目前，在微博等sns**上有海量使用者公開發布的內容，當發布者發布訊息，資料傳到伺服器更新時，就需要給關注者盡可能的實時更新內容。web**基於http協議，使用http協議探測伺服器上是否有內容更新，就必須頻繁地讓客戶端請求伺服器進行確認。在瀏覽器中要實現這種效果，可以使用comet技術，comet是基於http長連線的「伺服器推」技術，主要有兩種實現模型：基於ajax的長輪詢（long-polling）方式和基於iframe及htmlfile的流（streaming）方式。這兩種技術模型在這裡不詳細展開，有興趣的讀者可以查閱相關資料。
如果要實現裝置的反向控制，可能就要用到前面提到的comet技術。由於需要不斷的請求伺服器，會導致通訊開銷非常大，加上http冗長的報文頭，在節省流量上實在沒有優勢。
當然，如果只是單純地讓裝置定時上報資料而不做控制，也是可以使用http協議的。
mqtt與xmpp
最有可能與mqtt競爭的是xmpp協議。xmpp（可擴充套件通訊與表示協議）是一項用於實時通訊的開放技術，它使用可擴充套件標記語言（xml）作為交換資訊的基本格式。其優點是協議成熟、強大、可擴充套件性強。目前主要應用於許多聊天系統中，在訊息推送領域，mqtt和xmpp互相競爭。下面列舉mqtt與xmpp各自的特性：
xmpp協議基於繁重的xml，報文體積大且互動繁瑣；而mqtt協議固定報頭只有兩個位元組，報文體積小、編譯碼容易；
xmpp基於jid的點對點訊息傳輸；mqtt協議基於主題(topic)發布\訂閱模式，訊息路由更為靈活；
xmpp協議採用xml承載報文，二進位制必須進行base64編碼或其他方式處理；mqtt協議未定義報文內容格式，可以承載json、二進位制等不同型別報文，開發者可以針對性的定義報文格式；
mqtt協議支援訊息收發確認和qos保證，有更好的訊息可靠性保證；而xmpp主協議並未定義類似機制；
在嵌入式裝置開發中大多使用的是c語言開發，c語言解析xml是非常困難的。mqtt基於二進位制實現且未定義報文內容格式，可以很好的兼顧嵌入式c語言開發者；而xmpp基於xml，開發者需要配合協議格式，不能靈活開發。
綜上所述，在嵌入式裝置中，由於需要乙個靈巧簡潔，對裝置開發者和服務端開發者都友好的協議，mqtt比xmpp更具有優勢。
mqtt與coap
coap也是乙個能與mqtt競爭的協議。其模仿http的rest模型，服務端以uri方式建立資源，客戶端可以通過get、put、post、delete方式訪問這些資源，並且協議風格也和http極為相似，例如乙個裝置有溫度資料，那麼這個溫度可以被描述為：
coap://:/sensors/temperature
其中為裝置的ip，為埠。
NOSQL的介紹與其他NOSQL的比較
nosql nosql not only sql 意即 不僅僅是sql 是一項全新的資料庫理念，泛指非關係型的資料庫。nosql又叫非關係型資料庫，沒有資料庫那麼強規範，資料結構簡單 優點 成本 nosql資料庫簡單易部署，基本都是開源軟體，不需要像使用oracle那樣花費大量成本購買使用，相比關係...
python開發 與其他語言的比較
1 關於函式 1 不需要指定返回型別，不需要指定是否有返回值，每個函式都有返回值，沒有的話，就返回none 2 引數也可以不指定型別，可以有預設引數，但是必須放到最後，呼叫的時候指定引數的值，和順序無關 3 支援lamda方式 2 關於資料型別 python 是一種動態資料型別的語言，在執行期間才去...
Flink 的程式設計模型與其他框架比較
flink 的核心語義和架構模型 我們在講解 flink 程式的程式設計模型之前，先來了解一下 flink 中的 streams state time 等核心概念和基礎語義，以及 flink 提供的不同層級的 api。flink 核心概念 streams 流 流分為有界流和無界流。有界流指的是有固定...