物联网时代的大数据策略

物联网时代的大数据策略

互联网时代，PC、Pad、智能手机等设备无处不在，数以亿计的用户通过微博、微信、SNS、博客等途径产生大量的自媒体数据，电商、新闻类网站、搜索引擎每时每刻都在记录着丰富的用户行为信息，海量的数据促进了云计算，分布式技术的发展，而这些技术反过来不仅推动了Web和移动互联网的革新，也推动了物联网的飞速前进。现在，我们正逐渐迈入物联网时代，实现万物互联的愿景，如果说之前人是信息生产的主体，那么或许不久的将来设备将成为主角，它们将源源不断地产生与人相关的衣食住行信息，这些信息会通过云计算、数据挖掘等技术实现价值的升华从而为用户提供更优质、贴心的服务。那么物联网时代会产生什么样的数据，应该采用什么样的大数据策略呢？
THINKstrategies 的总经理 Jeff Kaplan 在自己的博文《 当物联网遇见大数据 》中写道：
“你不能使用现在的策略，因为可以被捕获、管理并利用的数据将更加多样化，同时用例也会更加丰富。附加到各种设备和对象上的传感器会产生各种类型的数据。这些数据将会用于各种响应式的、主动的或者 创造性的目的 。IT部门的任务就是与业务部门一起工作，完全理解物联网方面的用例，然后寻找满足业务需求的技术。特别是，IT部门必须识别出最优的分析平台和工具，让业务用户能够获取到需要的数据，分析数据的含义并快速地做出响应。”
Gartner公司的副总裁、著名分析师 Joe Skorupa 认为：
“分布在世界各地的物联网设备将产生大量的输入数据，将所有的数据传送到一个位置进行处理无论从技术上还是从经济上都是无法实现的。最近的趋势——将应用程序集中起来以便于降低成本并增强安全性——并不适合物联网。组织必须将数据集中到多个分布式的小型数据中心中，在此对数据进行初步的处理并发送到一个中心站点进行额外的处理。数据中心管理员需要在这些区域部署更加具有前瞻性的容量以满足业务发展的需要。”
Patrick McFadin则在自己的博文《 物联网：数据都去了哪里？ 》中阐述了一个具体的数据策略解决方案。他认为整个过程可以分为三个阶段：产生数据并通过Internet传递、中央系统收集并组织数据、持续的数据分析与使用。
第一阶段需要决定数据创建的标准以及如何通过网络进行传递。Patrick McFadin认为可以通过>

以上是小编为大家分享的关于物联网时代的大数据策略的相关内容，更多信息可以关注环球青藤分享更多干货

  MQTT 协议 是基于发布/订阅模式的物联网通信协议，凭借简单易实现、支持 QoS、报文小等特点，占据了物联网协议的半壁江山。
  常用于 IOT 物联网和一些需要服务端主动通知客户端的场景。

1 导入依赖

2 创建 MqttHelper 辅助类，设置回调监听

3 连接 MQTT

  连接成功或失败，以及中途的连接掉线，会触发 OnMqttStatusChangeListener 回调

4 MQTT 连接状态监听

5 MQTT 收发消息监听

  onSubMessage 订阅的消息回调，因为存在订阅多个 topic 的情况，所以回调能知道是来自哪个 Topic 的消息；
  onPubMessage 发布的消息回调，用于确认发布的消息是否发送成功。

6 MQTT 订阅 Topic

  需要在 MQTT 连接成功后才能订阅 topic，否则订阅 Topic 不成功，收不到对应消息

7 MQTT 取消订阅 Topic

8 MQTT 发布消息

9 MQTT 断开连接

10 通知设置
  由于 MQTT 启动了一个 Service，而 Android 80 以上对于后台 Service 限制时长 5 秒；所以将 MqttService 绑定到 Notification 上成为了一个前台通知；通知的标题和内容显示可以在 stringsxml 中设置，对应属性如下：

  Android 80 及以上开启前台服务绑定到通知，80 以下默认不启用，可将 mqtt_foreground_notification_low_26 设为 true，将 80 以下设备也开启前台通知服务

  创建 MQTT 实例时需要传送参数 MqttOptions,下面将介绍下部分参数;

1 Topic
  MQTT 是一种发布/订阅的消息协议, 通过设定的主题 Topic,
发布者向 Topic 发送的 payload 负载消息会经过服务器, 转发到所有订阅
该 Topic 的订阅者
   通配符 : 假想移动端消息推送场景,有的系统消息是全体用户接收,有的消息是 Android 或 iOS 设备接收, 又或者是某些消息具体推送到用户,当然, 对应的多种类型消息可以通过多订阅几个对应的 Topic 解决,也可以使用通配符;
  通配符有两个, " + " 和 " # ", 与正斜杠 " / " 组合使用;加号只能表示一级Topic, 井号可以表示任意层级 Topic; 例如: 订阅 Topic为 " System/+ ", 发布者发布的 Topic 可以是 System、System/Android、System/iOS; 但是不能是 System/iOS/123, 而订阅的 Topic 如果是" System/# " 则可以收到;
   注意,只有订阅的 Topic 才可以使用 通配符, 发布和遗嘱的 Topic 不能包含通配符

2 ClientID
  发布者和订阅者都是属于客户端, 客户端与服务端建立连接之后,发送的第一个报文消息必须是 Connect 消息,而 Connect 的消息载荷中必须包含 clientID 客户端唯一标识;
  如果两个客户端的 clientID 一样, 则服务端记录第一个客户端连接之后再收到第二个客户端连接请求,则会向一个客户端发送 Disconnect 报文断开连接, 并连接第二个客户端, 而如果此时设置了自动重连, 第一个客户端再次连接,服务端又断开与第二个的连接, 连上第一个客户端, 如此将导致两个客户端不断的被挤掉重连
  注意: clientID 使用的字符最好是 大小写字母和数字, 长度最好限制在[1, 23] 之间;

3 遗嘱消息
  可选参数, 客户端没有主动向服务端发起 disconnect 断开连接消息,然而服务端检测到和客户端之间的连接已断开, 此时服务端将该客户端设置的遗嘱消息发送出去
  应用场景: 客户端因网络等情况掉线之后, 可以及时通知到所有订阅该遗嘱 Topic 的客户端;
  遗嘱 Topic 中不能存在通配符

4 Session
  客户端和服务端之间建立的会话状态, 一般用于消息保存, 如果设置清除 Session,则每次客户端和服务端建立连接会创建一个新的会话,之前连接中的消息不能恢复,
  而设置不清除会话, 对应发布者发送的 qos 为 1和2 的消息,还未被订阅者接收确认,则需要保存在会话中, 以便订阅者下次连接可以恢复这些消息;
  注意: Session 存储的消息是保存在内容中的, 所以如果不是重要的消息,最好是设置清除 Session, 或者设置 qos = 0;

5 心跳包
  标识客户端传输一次控制报文到下一次传输之间允许的空闲时间；在这段时间内，如果客户端没有其他任何报文发送，必须发送一个 PINGREQ 报文到服务器，而如果服务端在 15 倍心跳时间内没有收到客户端消息，则会主动断开客户端的连接，发送其遗嘱消息给所有订阅者。而服务端收到 PINGREQ 报文之后，立即返回 PINGRESP 报文给客户端
  心跳时间单位为秒，占用2个字节，最大 2^16 - 1 = 65535秒（18小时12分钟15秒）,设置为 0 表示不使用心跳机制； 心跳时间一般设置为几分钟或几十秒即可，时间短点可以更快的发出遗嘱消息通知掉线，但是时间短会增加消息频率，影响服务端并发； 微信长连接为 300 秒，而三大运营商貌似也有个连接时间最小的为 5 分钟。

6 qos
  服务质量等级 qos 对应两部分,一是客户端到服务端发送的消息, 一是服务端到客户端订阅的消息; 从发布者到订阅者实际 qos 为两段路中 qos 最小的。
  qos 可选值 0(最多交付一次)、1(最少交付一次)、2(正好交付一次);
   qos = 0 ：接收方不发送响应，发送方不进行重试；发送方只管发一次，不管是否发成功，也不管接收方是否成功接收，适用于不重要的数据传输；
   qos = 1 ：确保消息至少有一次到达接收方，发送方向接收方发送消息，需要等待接收方返回应答消息，如果发送方在一定时间之内没有收到应答，发送方继续下一次消息发送，直到收到应答消息，删除本地消息缓存，不再发送；所以接收方可能收到1-n次消息；适用于需要收到所有消息，客户端可以处理重复消息。
   qos = 2 ：确保消息只一次到达接收方，发送方和接收方之间消息处理流程最复杂；
   Mqtt Qos 深度解读 和 MQTT协议QoS2 准确一次送达的实现

7 payload 负载消息
  字节流类型, 是 MQTT 通信传输的真实数据

8 保留消息
  发布消息时设置, 对应参数 retain, 服务端将保留对应 Topic 最新的一条消息记录; 保留消息的作用是每次客户端连接上线都会收到其 Topic 的最后一条保留消息, 所以可能存在网络不稳定,频繁掉线重连,每次重连重复收到保留消息;
   可以向对应的 Topic 发送一条 空消息,用于清除保留消息。

MQTT 服务搭建 Apache Apollo 服务器 搭建 MQTT 服务
Github 仓库
mqtt 协议

之前一直想要使用mqtt协议模拟tcp协议的实时返回监控参数的功能，经过几个月的摸索和试验，终于将同步服务的开发摸透，仅仅看飞燕平台的技术文档是看不懂的，核心文档链接如下：

1、什么是rrpc，同步服务如何使用rrpc实现实时返回的效果

>

物联网 (internet of thing) ，表示的是可以把一些带某些传感器的设备(终端)，接入到互联网的行为。
通过互联网连接这些设备，这些设备就能够互相协作。
而 MQTT 就是这些设备之间数据通信的一个基于 TCP/IP 的协议。

每个终端都和实现了 MQTT 协议的代理/服务器相连。
通过 published MQTT 代理服务器的某个 主题 发送数据。
通过 subscription 从 MQTT 代理服务器获取自己订阅的 主题 数据。

MQTT 协议是一种轻量级的、灵活的网络协议。并且非常适合 IOT 的场景。

大多数开发人员已经熟悉了 >1、 什么是MQTT

MQTT（MessageQueueing Telemetry Transport Protocol）的全称是消息队列遥感传输协议的缩写，是由IBM公司推出的一种基于轻量级代理的发布/订阅模式的消息传输协议，运行在TCP协议栈之上，为其提供有序、可靠、双向连接的网络连接保证。由于其开放、简单和易于实现所以能够应用在资源受限的环境中，对于M2M和物联网应用程序来说是一个相当不错的选择。

2、 为什么要用MQTT？

MQTT协议是针对如下情况设计的：

M2M（Machine to Machine） communication，机器端到端通信，比如传感器之间的数据通讯 因为是Machine to Machine，需要考虑： Machine，或者叫设备，比如温度传感器，硬件能力很弱，协议要考虑尽量小的资源消耗，比如计算能力和存储等 M2M可能是无线连接，网络不稳定，带宽也比较小

MQTT的特点:

发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。这一点很类似于1 这里是列表文本XMPP，但是MQTT的信息冗余远小于XMPP

对负载内容屏蔽的消息传输。

使用TCP/IP提供网络连接。主流的MQTT是基于TCP连接进行数据推送的，但是同样有基于UDP的版本，叫做MQTT-SN。这两种版本由于基于不同的连接方式，优缺点自然也就各有不同了。

三种消息传输方式QoS：

0代表“至多一次”，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。

1代表“至少一次”，确保消息到达，但消息重复可能会发生。

2代表“只有一次”，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。 备注：由于服务端采用Mosca实现，Mosca目前只支持到QoS 1

如果发送的是临时的消息，例如给某topic所有在线的设备发送一条消息，丢失的话也无所谓，0就可以了（客户端登录的时候要指明支持的QoS级别，同时发送消息的时候也要指明这条消息支持的QoS级别），如果需要客户端保证能接收消息，需要指定QoS为1，如果同时需要加入客户端不在线也要能接收到消息，那么客户端登录的时候要指定session的有效性，接收离线消息需要指定服务端要保留客户端的session状态。

mqtt基于订阅者模型架构，客户端如果互相通信，必须在同一订阅主题下，即都订阅了同一个topic，客户端之间是没办法直接通讯的。订阅模型显而易见的好处是群发消息的话只需要发布到topic，所有订阅了这个topic的客户端就可以接收到消息了。

发送消息必须发送到某个topic，重点说明的是不管客户端是否订阅了该topic都可以向topic发送了消息，还有如果客户端订阅了该主题，那么自己发送的消息也会接收到。

小型传输，开销很小（固定长度的头部是2字节），协议交换最小化，以降低网络流量。这就是为什么在介绍里说它非常适合“在物联网领域，传感器与服务器的通信，信息的收集”，要知道嵌入式设备的运算能力和带宽都相对薄弱，使用这种协议来传递消息再适合不过了。

使用Last Will和Testament特性通知有关各方客户端异常中断的机制。Last Will：即遗言机制，用于通知同一主题下的其他设备发送遗言的设备已经断开了连接。Testament：遗嘱机制，功能类似于Last Will 。

---