先吐槽一下，一開始看了ppt，覺得很高大上，但后面聽了演講后，基本就是讀ppt，真是一口老血=。=
IoT的挑戰(zhàn)
規(guī)模上物聯(lián)網(wǎng)設(shè)備將會達(dá)到數(shù)百億級別，包括可穿戴設(shè)備，家庭智能設(shè)備，工業(yè)網(wǎng)關(guān)等。存儲上面對海量的存儲，需要使用分布式的時序數(shù)據(jù)庫。協(xié)議上看，需要有注重安全，個人隱私，防止攻擊，數(shù)據(jù)安全的協(xié)議。
百度的物聯(lián)網(wǎng)平臺解決方案
用戶通過終端SDK接入，使用MQTT協(xié)議。數(shù)據(jù)儲存使用對象存儲，NoSQL，關(guān)系型DB和時序數(shù)據(jù)庫。對行業(yè)服務(wù)，提供物解析，預(yù)測性維保和嵌入式可視化報表等。所謂物解析（IoT Parser），就是簡單快速完成各種設(shè)備數(shù)據(jù)協(xié)議解析。
用戶通過工業(yè)網(wǎng)關(guān)或者設(shè)備終端，接入MQTT服務(wù)。MQTT服務(wù)依賴其服務(wù)，HBase做數(shù)據(jù)的存儲，Redis做數(shù)據(jù)的緩存，ZooKeeper做broker之間數(shù)據(jù)的協(xié)調(diào)。用戶可以用Rule Engine來自定義一些數(shù)據(jù)服務(wù)，只需使用sql語句就可操作。之后，數(shù)據(jù)通過Kafka，對數(shù)據(jù)做流處理和批處理，最后對過濾后的數(shù)據(jù)進(jìn)行存儲（使用NoSQL，MySql，DFS，TSDB）。
協(xié)議的選擇
百度選擇使用MQTT協(xié)議。CoAP，使用基于UDP，因而反控性能較差。XMPP和HTTP都是比較重的協(xié)議，數(shù)據(jù)量較大。
MQTT有如下特點(diǎn)：
- 使用心跳維持連接
可以用來檢測client和server之間的連接狀態(tài)，同時還可以維護(hù)NAT地址映射表 - 遺愿信息功能
指定當(dāng)client和server之間失去連接之后，server需要往指定的topic發(fā)送特定QoS的級別的消息 - 能保留消息
一個特定主題的消息會保留到服務(wù)器，當(dāng)任何一個client訂閱了這個主題，都會首先收到這個消息。 -
持久化訂閱
當(dāng)client和server之間斷開連接之后，所有發(fā)往這個主題的消息都會保留下來，等client重新連接之后，會重新發(fā)給該client
屏幕快照 2017-09-23 下午3.41.02.png
目開源的MQTT服務(wù)，主要是單機(jī)版的MQTT服務(wù)，Mosquitto，Moquette，Apollo，RabbitMQ。
物聯(lián)網(wǎng)場景下的數(shù)據(jù)一致性
如果所有client發(fā)送的數(shù)據(jù)需要全局一致性，那么必然會需要一個broker來擔(dān)當(dāng)master，為每一個消息分配一個id，那么這個Broker會成為一個hotspot，而且系統(tǒng)不具有擴(kuò)展性。在百度的應(yīng)用場景中，并沒有保證多個client的全局消息一致性。只支持同一個client消息的有序性，通過消息的到達(dá)時間來決定其順序。
MQTT協(xié)議的局限性及解決方法
在消息數(shù)量級很大時，消息訂閱者在一條連接上，會消費(fèi)所有數(shù)據(jù)，這是不合理的。
百度使用Kafka，先對消息做分區(qū)處理，根據(jù)用戶提供不同的key，將不同的key的消息存放到不同的分區(qū)。在后面的Consumer Group對消息進(jìn)行消費(fèi)。
