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