1、各大运营商、互联网公司、设备制造商等等企业都在做综合性的平台。
国内有阿里、华为、三大运营商、百度、腾讯、小米、海尔、京东、中电科等。
国外有亚马逊、IBM、SAP、
谷歌、GE、西门子、博世等。
通过以上名单可以发现，这些公司的特点。
这说明物联网是未来的发展方向，是值得花钱而且花大钱去布局的事。
2、做综合性的物联网平台，要求的资金、资源和技术要求会很高。因为是综合性平台，那么你得搞清楚各行各业的所使用物联网平台的诉求，行业标准等等，不然你的用户群体就会很窄。
3、面对的竞争对手的实力都不可小觑，你要考虑的是现阶段进入这个领域做平台在技术上能否与以上那些公司一较高下呢？你想投入多少时间和精力去做平台呢？人家都可是布局好几年了，踩了很多坑积累了很多经验，且现在平台已具有一定规模，形成了一定的行业壁垒，特别是华为，据我所知，国内运营商的平台都离不开华为的支持。
物联网平台的玩家之多，让人惊叹啊，那么咱们还有没有机会呢？答案是肯定的，有！但我的建议走垂直领域。
物联网的领域很广泛，所以专业的物联网平台未来会有很多，而这种综合性的物联网平台经过几年的厮杀后，最终也就剩下几家巨头。何谓垂直领域的物联网平台呢？
最基本的就是行业垂直，比如工业、农业、教育、医疗、安防、建筑、家居、交通运输等领域。
以上玩家也有做垂直领域的，比如ABB/西门子/GE/普奥云/博世等，他们专注工业领域，爱立信、诺基亚专注通信领域，而互联网巨头则是走综合性的较多，因为他们有一定客户基础、服务器资源和用户群体，可以面对企业和开发者提供平台服务，海尔/小米等企业就是在智能家居领域发力的。
不出意外，安防领域的海康、大华都在对自己的领域来架设相应的物联网平台。
从专业的角度来看物联网平台类型有功能呢？
物联网平台有五种类型
1网络连接，网络连接平台以物联网系统的网络组件为中心。它们为用户提供保持设备在线所必需的软件、连接硬件和数据指导。它们的网络通常依赖现有的运营商服务和WI-FI，并以一种便于物联网设置的方式配置网络连接。
有机会的，物联网的网少不了平台，没有平台就没有物联网。平台提供基于数据的存储、管理等。数据挖掘、数据分析等都基于云平台来计算。
物联网平台从另一个角度来看，是数据的“聚合”平台，通过大数据分析，给决策提供状态、趋势和决策等。
随着5G时代的到来，“边缘计算”一词越来越多的出现在大众视野。今天我们就来讲讲Arex算力资源平台如何利用“边缘计算”制霸未来物联网20。
什么是边缘计算？
首先我们介绍一下什么是边缘计算：边缘计算是分布式计算技术的一种，分布式系统的崛起催生边缘计算平台和新的网络构架分布式AI会在最后一英里网络中增加更多的计算、智能和处理/存储能力，将引发移动端硬件和算力变革。
在这种配置中，人工智能引擎将依赖于大量物联网传感器和执行器，收集和处理大量的 *** 作现场数据。海量数据将为“本地化”的边缘计算AI引擎提供燃料，这些引擎将运行本地进程并在现场做出决策。
因此网络需要另一种水平的实时边缘计算、数据收集和存储，将推动人工智能处理到网络边缘。这将完成云边缘智能和网络化计算机的循环, 并通过基于区块链的智能合约来完成数据授权和业务运转。
物联网中边缘计算与区块链的结合是大势所趋，会将当前的传统物联网完全颠覆掉。
为什么这么说呢？
传统物联网将被淘汰
伴随着近年来通用计算机设备的飞速发展，各类自动化的智能设备开始进入人们视野，背后是廉价传感器和控制设备的爆炸性增长。传统物联网系统基于服务器/客户端的中心化架构。即所有物联设备都通过云实现验证、连接和智能控制。
中心化的物联网架构存在三个问题。
一是云计算成本，例如在家庭应用场景下，两台家电相距不到一米，也需要通过云端进行沟通。数据汇总到单一的控制中心，企业所销售的物联设备越多，其中心云计算服务支出的成本会越大。由于终端物联设备竞争愈加激烈，利润走低，中心计算成本矛盾会越来越突出。
其次，中心化的数据收集和服务方式，无法从根本上向用户保证数据会合法使用。用户的数据保护完全依靠企业单方面的承诺，难以进行有效的监管。
第三，中心化物联生态系统中，一个设备被攻陷，所有的设备会受到影响。例如《麻省理工 科技 评论》2017年所指出的僵尸物联网，可以通过感染并控制摄像头、监视器等物联设备，造成大规模网络瘫痪。
区块链技术重塑物联网
区块链技术可以利用区块链独特的不可篡改的分布式账本记录特性，构建底层通讯节点、建立链上算力生态、依托分布式存储用于计算服务等区块链技术的综合应用，将全球闲置算力整合起来，通过构建“边缘算力”模式为有需求的用户提供d性可扩容的算力交易、算力租赁等服务。为用户打造一个开放、公平、透明和低门槛的去中心化算力资源共享平台，同时结合丰富的行业经验为全球客户提供更优质的服务。
简单来说就是Arex算力资源平台利用分布式计算模式将全球的闲置算力进行整合，从而构建出高数量级的“边缘算力”，并以此为算力源对需要的应用场景进行高能输出。
边缘算力的应用场景到底有多广阔？
边缘计算将数据处理从云中心转移到网络边缘，计算和数据存储可以分散到互联网靠近物联终端、传感器和用户的边缘，不仅可以缓解云带宽压力，还可以优化面向感知驱动的网络服务架构。（例如家里的空调、热水器与冰箱、安防摄像头等可以通过边缘计算进行协调运行，即使是在连接不上云服务器的情况下，也能确保最佳的节能和服务状态。）
第三方数据分析机构IDC预测，在2020年全球将有约500亿的智能设备接入互联网，除了目前大火的5G通信外，包括大数据人工智能穿戴产品、无人驾驶技术、智慧城市服务等，其中40%的数据需要边缘计算服务。由此可见边缘计算有着强大市场潜力，也是当前各服务商争夺的热点。
无人驾驶技术：
无人驾驶
智能穿戴设备：
智慧城市：
要回答物联网云平台是不是还有机会的问题，首先要搞清楚几方面的状况：
一是定位。从技术角度来说，你是做物联网云平台的那一层，IaaS、PaaS、SaaS，单做某层或是混合？而技术的定位取决于：（1）你觉得那一块是你发掘出的空白或者你觉得有前景？（2）为你的客户提供什么样的价值（3）你想做什么样的商业模式。这三个问题依次定推，最后才决定了你了的技术定位和技术架构。找准定位，这是你开始一切的起点。
二是资源。这个我就不多说了，包括资金、技术、人脉、产业链合作，这是你保障自己可以开始有效行动的基础。
三是团队。团队是真正去实施理想的载体，可以是几个人的创业“作坊”，也可以是有一定规模的公司，也可以是松散的联盟组织。
其实，物联网的市场何其大，需要的云服务何其多，宏观市场和细分市场规模都足够你有所作为。做不做，做不做得好在于自己。至于，做不做设备终端，就看你是怎么玩了。
机会很大
物联网平台承上启下，是物联网产业链枢纽。按照逻辑关系和功能物联网平台从下到上提供终端管理、连接管理、应用支持、业务分析等主要功能。
通信技术发展促进连接数迅速猛增，物联网迎来告诉发展引爆点
连接数告诉增长是物联网行业发展基础
物联网发展路径为连接--感知--智能，目前处于物联网发展第一阶段即物联网连接数快速增长阶段。到2018年，全球物联网连接数将超过手机连接数。
物联网发展第一阶段：物联网连接大规模建立阶段，越来越多的设备在放入通信模块后通过移动网络（LPWA\GSM\3G\LTE\5G等）、WiFi、蓝牙、RFID、ZigBee等连接技术连接入网，在这一阶段网络基础设施建设、连接建设及管理、终端智能化是核心。爱立信预测到2021年，全球的移动连接数将达到275亿，其中物联网连接数将达到157亿、手机连接数为86亿。智能制造、智能物流、智能安防、智能电力、智能交通、车联网、智能家居、可穿戴设备、智慧医疗等领域连接数将呈指数级增长。该阶段中最大投资机会主要在于网络基础设施建设、通讯芯片和模组、各类传感器、连接管理平台、测量表具等。
物联网发展第二阶段：大量连接入网的设备状态被感知，产生海量数据，形成了物联网大数据。这一阶段传感器、计量器等器件进一步智能化，多样化的数据被感知和采集，汇集到云平台进行存储、分类处理和分析，此时物联网也成为云计算平台规模最大的业务之一。根据IDC的预测， 2020年全球数据总量将超过40ZB(相当于4万亿GB)，这一数据量将是2012年的22倍，年复合增长率48%。这一阶段，云计算将伴随物联网快速发展。该阶段主要投资机会在AEP平台、云存储、云计算、数据分析等。
物联网发展第三阶段：初始人工智能已经实现，对物联网产生数据的智能分析和物联网行业应用及服务将体现出核心价值。Gartner 预测2020 年物联网应用与服务产值将达到2620 亿美元，市场规模超过物联网基础设施领域的4 倍。该阶段物联网数据发挥出最大价值，企业对传感数据进行分析并利用分析结果构建解决方案实现商业变现，同时运营商坐拥大量用户数据信息，通过数据的变现将大幅改善运营商的收入。该阶段投资者机会主要在于物联网综合解决方案提供商、人工智能、机器学习厂商等
物联网云平台是一个专门为物联网定制的云平台，物联网与普通的互联网是不同的:物联网终端设备比普通互联网手机端,电脑端多出几个数量级;普通互联网对>物联网的应用如下：
1、智能仓库。物联网一个很好的应用。它能准确的提供仓库管理各个环节数据的真实性，对于生产企业，可以根据这个数据合理的把控库存量，调整生产量。物联网中利用SNHGES系统的库位管理功能，可以准确提供货物库存位置，这就大大提高了仓库管理的效率。
2、智能物流。运用条形码、传感器、射频识别技术、全球定位等先进的物联网通信技术，实现物流业运输、仓储、配送、装卸等各个环节的智能化。不仅货物运输更加的自动化，而且作出的全面分析还能及时的处理问题对物流过程作出调整，优化了管理。大大提高了物流行业的服务水平，还节约了成本。
3、智能医疗。利用物联网技术，实现患者和医务人员、医疗机构、医疗设备的互动，实现医疗智能化。物联网医疗设备中的传感器与移动设备可以对患者的生理状态进行捕捉，把生命指数记录到电子健康文件中，不仅自己可以查看，也方便了医生的查阅，实现远程的医疗看病。很好的解决当前的医疗资源分布不均，看病难的问题。
4、智能家庭。物联网的出现让我们的日常生活更加的便捷。不远的将来一台手机，就可以 *** 作家里大多数的电器，查看它们的运行状态。寒冷的冬天，我们可以提前打开家里的空调，回到家就暖暖的。物联网还能准确的定位家庭成员的位置，你再也不用担心孩子跑的找不见人，省心省力。
5、智能农业。物联网在农业中的应用就更加的广泛。监测温湿度，监视土壤酸碱度，查看家禽的状态。在这些数据的支持下，农户就可以合理进行科学评估，安排施肥，灌溉。监测到的天气情况比如降水，风力等又为我们抗灾、减灾提供了依据。提高了产量，降低了减产风险。
6、智能交通。物联网将整个交通设备连在一起。主要是用图像识别为核心技术。可以准确的收集到交通车流量信息，通过信号灯等设备进行流量的控制，这个技术的运用，会让堵车成为历史。管理人员利用这个技术能将道路、车辆的情况掌握的一清二楚，驾驶违章无处可逃，交通事故也能及时的得到处理。人们的出行得到了很大的方便。
7、智能电力。电力工程是一项重大的民生工程，对电网的安全检测是一项必修科目。以南方电网与中国移动通过M2M技术进行的合作为例，因为物联网的运用，使得自动化计量系统开始启动，使得故障评价处理时间得到一倍的缩减。
工业物联网云平台推荐是一个基于云计算、大数据、人工智能等前沿技术的智能制造平台，它集数据采集、数据存储、数据处理、数据分析、决策支持等功能于一体，可以实现设备的远程监控、预测性维护、异常检测以及生产调度、设备管理等工业应用。
工业物联网云平台推荐的主要特点包括以下几个方面：
一、开放性
工业物联网云平台是一个开放的平台，它采用标准化的接口和协议，与各种硬件设备、传感器、机器人等工业设备实现无缝对接，与各种软件系统、应用服务实现互联互通。同时，平台还提供了丰富的API，方便开发者和企业自主开发和集成精细化的应用。
二、可扩展性
工业物联网云平台是一个高度可扩展的平台，它可以支撑海量设备数据的采集、存储、处理、分析和应用，能够灵活地满足用户的不同需求。此外，平台还提供了多样化的工具、算法和应用组件，方便用户根据实际情况进行定制化。
三、协作性
工业物联网云平台是一个强调协作的平台，它鼓励企业之间、企业和研究机构之间、企业和政府之间等多种形式的合作，共同推动工业物联网技术的创新和应用。平台还提供了多种合作机制和服务，包括共享设备、协同工作、技术支持、数据交换等，为用户提供全方位的支持。
四、安全性
工业物联网云平台推荐是一个高度安全的平台，它采用了多种安全技术和加密方案，保障用户数据的机密性、完整性和可用性。平台还提供了完善的权限管理和安全审计机制，有效防范各类网络攻击。
工业物联网云平台推荐，上海力控科技ThingNet物联网云平台是基于以往的物联网产品，以及目前市场上的各种云平台优点，精心打造的一款实现设备上云的多功能产品，该物联网云平台面向设备而使用，例如大型的空调机组、空压机、泵等等设备的上云，云平台提供从设备接入、运行监控、设备资产管理、工业数据预知分析等一站式SaaS服务，使用对象可以为设备厂家、设备运维厂家、以及相关设备管理型公司等。
物联网云平台需具备以下功能。(1)业务受理、开通、计费功能
要成为物联网业务的服务提供商，需要建立一套面向客户、传感器厂商、第三方行业应用提供商的运营服务体系，包括组织、流程、产品、支撑系统，其中支撑系统应具备业务受理、开通、计费等功能，能够提供物联网产品的快速开通服务。
(2)信息采集、存储、计算、展示功能
物联网云平台需要支持通过无线或有线网络采集传感网络节点上的物品感知信息，进行格式转换、保存和分析计算。相比互联网相对静态的数据，在物联网环境下，将更多地涉及基于时间和空间特征、动态的超大规模数据计算，并且不同行业的计算模型不同。这些应用所产生的海量数据对物联网运营平台的采集、存储、计算能力都提出了巨大的挑战。
(3)行业的灵活拓展应用模式
不同行业的业务规则和流程不同，其应用的功能和计算需求也有差别，例如在大气环保监控应用中，需要根据大气环境监测设备上采集到的降尘、一氧化碳、二氧化硫等数据，按一定的指标计算规则进行分析计算，得出分析结果，展现到监控中心计算机或监控人员手机上;而在电力抄表应用中，对于采集到的用户电表读数，将会用于计算当月用电量和电费，生成电费账单，进而支持收费销账。
因此物联网云平台不可能是一个封闭自运行的应用系统，需要具备第三方行业应用的集成能力即要能提供给第三方合作开发者灵活拓展的云端应用开发API接口，从而能够满足不同行业应用的差异化功能要求。
消息队列（Message Queue）是一种进程间通信或同一进程的不同线程间的通信方式。
Broker（消息服务器）
Broker的概念来自与Apache ActiveMQ，通俗的讲就是MQ的服务器。
Producer（生产者）
业务的发起方，负责生产消息传输给broker
Consumer（消费者）
业务的处理方，负责从broker获取消息并进行业务逻辑处理
Topic（主题）
发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅 者，实现消息的广播
Queue（队列）
PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收。
Message（消息体）
根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输
点对点模型用于消息生产者和消息消费者之间点到点的通信。
点对点模式包含三个角色：
每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，可以放在内存 中也可以持久化，直到他们被消费或超时。
特点：
发布订阅模型包含三个角色：
多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。
特点：
AMQP即Advanced Message Queuing Protocol，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
优点：可靠、通用
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。
优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统
STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互 *** 作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。
优点：命令模式（非topic\queue模式）
XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时 *** 作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其 *** 作系统和浏览器不同。
优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大
RabbitMQ 是实现 AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 RabbitMQ 主要是为了实现系统之间的双向解耦而实现的。当生产者大量产生数据时，消费者无法快速消费，那么需要一个中间层。保存这个数据。
RabbitMQ 是一个开源的 AMQP 实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。
Channel（通道）
道是两个管理器之间的一种单向点对点的的通信连接，如果需要双向交流，可以建立一对通道。
Exchange（消息交换机）
Exchange类似于数据通信网络中的交换机，提供消息路由策略。
RabbitMq中，producer不是通过信道直接将消息发送给queue，而是先发送给Exchange。一个Exchange可以和多个Queue进行绑定，producer在传递消息的时候，会传递一个ROUTING_KEY，Exchange会根据这个ROUTING_KEY按照特定的路由算法，将消息路由给指定的queue。和Queue一样，Exchange也可设置为持久化，临时或者自动删除。
Exchange有4种类型：direct(默认)，fanout， topic， 和headers。
不同类型的Exchange转发消息的策略有所区别：
Binding（绑定）
所谓绑定就是将一个特定的 Exchange 和一个特定的 Queue 绑定起来。Exchange 和Queue的绑定可以是多对多的关系。
Routing Key（路由关键字）
exchange根据这个关键字进行消息投递。
vhost（虚拟主机）
在RabbitMq server上可以创建多个虚拟的message broker，又叫做virtual hosts (vhosts)。每一个vhost本质上是一个mini-rabbitmq server，分别管理各自的exchange，和bindings。vhost相当于物理的server，可以为不同app提供边界隔离，使得应用安全的运行在不同的vhost实例上，相互之间不会干扰。producer和consumer连接rabbit server需要指定一个vhost。
假设P1和C1注册了相同的Broker，Exchange和Queue。P1发送的消息最终会被C1消费。
基本的通信流程大概如下所示：
Consumer收到消息时需要显式的向rabbit broker发送basic。ack消息或者consumer订阅消息时设置auto_ack参数为true。
在通信过程中，队列对ACK的处理有以下几种情况：
即消息的Ackownledge确认机制，为了保证消息不丢失，消息队列提供了消息Acknowledge机制，即ACK机制，当Consumer确认消息已经被消费处理，发送一个ACK给消息队列，此时消息队列便可以删除这个消息了。如果Consumer宕机/关闭，没有发送ACK，消息队列将认为这个消息没有被处理，会将这个消息重新发送给其他的Consumer重新消费处理。
消息的收发处理支持事务，例如：在任务中心场景中，一次处理可能涉及多个消息的接收、处理，这应该处于同一个事务范围内，如果一个消息处理失败，事务回滚，消息重新回到队列中。
消息的持久化，对于一些关键的核心业务来说是非常重要的，启用消息持久化后，消息队列宕机重启后，消息可以从持久化存储恢复，消息不丢失，可以继续消费处理。
fanout 模式
模式特点：
direct 模式
任何发送到Direct Exchange的消息都会被转发到routing_key中指定的Queue。
如果一个exchange 声明为direct，并且bind中指定了routing_key，那么发送消息时需要同时指明该exchange和routing_key。
简而言之就是：生产者生成消息发送给Exchange， Exchange根据Exchange类型和basic_publish中的routing_key进行消息发送 消费者：订阅Exchange并根据Exchange类型和binding key(bindings 中的routing key) ，如果生产者和订阅者的routing_key相同，Exchange就会路由到那个队列。
topic 模式
前面讲到direct类型的Exchange路由规则是完全匹配binding key与routing key，但这种严格的匹配方式在很多情况下不能满足实际业务需求。
topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到binding key与routing key相匹配的Queue中，但这里的匹配规则有些不同。
它约定：
以上图中的配置为例，routingKey=”quickorangerabbit”的消息会同时路由到Q1与Q2，routingKey=”lazyorangefox”的消息会路由到Q1，routingKey=”lazybrownfox”的消息会路由到Q2，routingKey=”lazypinkrabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）；routingKey=”quickbrownfox”、routingKey=”orange”、routingKey=”quickorangemalerabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey。
RabbitMQ，部署分三种模式：单机模式，普通集群模式，镜像集群模式。
普通集群模式
多台机器部署，每个机器放一个rabbitmq实例，但是创建的queue只会放在一个rabbitmq实例上，每个实例同步queue的元数据。
如果消费时连的是其他实例，那个实例会从queue所在实例拉取数据。这就会导致拉取数据的开销，如果那个放queue的实例宕机了，那么其他实例就无法从那个实例拉取，即便开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，但得等这个实例恢复了，然后才可以继续从这个queue拉取数据， 这就没什么高可用可言，主要是提供吞吐量 ，让集群中多个节点来服务某个queue的读写 *** 作。
镜像集群模式
queue的元数据和消息都会存放在多个实例，每次写消息就自动同步到多个queue实例里。这样任何一个机器宕机，其他机器都可以顶上，但是性能开销太大，消息同步导致网络带宽压力和消耗很重，另外，没有扩展性可言，如果queue负载很重，加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue。此时，需要开启镜像集群模式，在rabbitmq管理控制台新增一个策略，将数据同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
Kafka 是 Apache 的子项目，是一个高性能跨语言的分布式发布/订阅消息队列系统（没有严格实现 JMS 规范的点对点模型，但可以实现其效果），在企业开发中有广泛的应用。高性能是其最大优势，劣势是消息的可靠性（丢失或重复），这个劣势是为了换取高性能，开发者可以以稍降低性能，来换取消息的可靠性。
一个Topic可以认为是一类消息，每个topic将被分成多个partition(区)，每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset为一个long型数字，它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几乎不允许对消息进行“随机读写”。
Kafka和JMS（Java Message Service）实现(activeMQ)不同的是:即使消息被消费，消息仍然不会被立即删除。日志文件将会根据broker中的配置要求，保留一定的时间之后删除；比如log文件保留2天，那么两天后，文件会被清除，无论其中的消息是否被消费。kafka通过这种简单的手段，来释放磁盘空间，以及减少消息消费之后对文件内容改动的磁盘IO开支。
对于consumer而言，它需要保存消费消息的offset，对于offset的保存和使用，有consumer来控制；当consumer正常消费消息时，offset将会"线性"的向前驱动，即消息将依次顺序被消费。事实上consumer可以使用任意顺序消费消息，它只需要将offset重置为任意值。(offset将会保存在zookeeper中，参见下文)
kafka集群几乎不需要维护任何consumer和producer状态信息，这些信息有zookeeper保存；因此producer和consumer的客户端实现非常轻量级，它们可以随意离开，而不会对集群造成额外的影响。
partitions的设计目的有多个。最根本原因是kafka基于文件存储。通过分区，可以将日志内容分散到多个server上，来避免文件尺寸达到单机磁盘的上限，每个partiton都会被当前server(kafka实例)保存；可以将一个topic切分多任意多个partitions，来消息保存/消费的效率。此外越多的partitions意味着可以容纳更多的consumer，有效提升并发消费的能力。(具体原理参见下文)。
一个Topic的多个partitions，被分布在kafka集群中的多个server上；每个server(kafka实例)负责partitions中消息的读写 *** 作；此外kafka还可以配置partitions需要备份的个数(replicas)，每个partition将会被备份到多台机器上，以提高可用性。
基于replicated方案，那么就意味着需要对多个备份进行调度；每个partition都有一个server为"leader"；leader负责所有的读写 *** 作，如果leader失效，那么将会有其他follower来接管(成为新的leader)；follower只是单调的和leader跟进，同步消息即可。由此可见作为leader的server承载了全部的请求压力，因此从集群的整体考虑，有多少个partitions就意味着有多少个"leader"，kafka会将"leader"均衡的分散在每个实例上，来确保整体的性能稳定。
Producers
Producer将消息发布到指定的Topic中，同时Producer也能决定将此消息归属于哪个partition；比如基于"round-robin"方式或者通过其他的一些算法等。
Consumers
本质上kafka只支持Topic。每个consumer属于一个consumer group；反过来说，每个group中可以有多个consumer。发送到Topic的消息，只会被订阅此Topic的每个group中的一个consumer消费。
如果所有的consumer都具有相同的group，这种情况和queue模式很像；消息将会在consumers之间负载均衡。
如果所有的consumer都具有不同的group，那这就是"发布-订阅"；消息将会广播给所有的消费者。
在kafka中，一个partition中的消息只会被group中的一个consumer消费；每个group中consumer消息消费互相独立；我们可以认为一个group是一个"订阅"者，一个Topic中的每个partions，只会被一个"订阅者"中的一个consumer消费，不过一个consumer可以消费多个partitions中的消息。kafka只能保证一个partition中的消息被某个consumer消费时，消息是顺序的。事实上，从Topic角度来说，消息仍不是有序的。
Kafka的设计原理决定，对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。
Guarantees
Kafka就比较适合高吞吐量并且允许少量数据丢失的场景，如果非要保证“消息可靠传输”，可以使用JMS。
Kafka Producer 消息发送有两种方式(配置参数 producertype)：
对于同步方式(producertype=sync)？Kafka Producer 消息发送有三种确认方式(配置参数 acks)：
kafka的设计初衷是希望作为一个统一的信息收集平台，能够实时的收集反馈信息，并需要能够支撑较大的数据量，且具备良好的容错能力。
持久性
kafka使用文件存储消息，这就直接决定kafka在性能上严重依赖文件系统的本身特性。且无论任何OS下，对文件系统本身的优化几乎没有可能。文件缓存/直接内存映射等是常用的手段。因为kafka是对日志文件进行append *** 作，因此磁盘检索的开支是较小的；同时为了减少磁盘写入的次数，broker会将消息暂时buffer起来，当消息的个数(或尺寸)达到一定阀值时，再flush到磁盘，这样减少了磁盘IO调用的次数。
性能
需要考虑的影响性能点很多，除磁盘IO之外，我们还需要考虑网络IO，这直接关系到kafka的吞吐量问题。kafka并没有提供太多高超的技巧；对于producer端，可以将消息buffer起来，当消息的条数达到一定阀值时，批量发送给broker；对于consumer端也是一样，批量fetch多条消息。不过消息量的大小可以通过配置文件来指定。对于kafka broker端，似乎有个sendfile系统调用可以潜在的提升网络IO的性能:将文件的数据映射到系统内存中，socket直接读取相应的内存区域即可，而无需进程再次copy和交换。 其实对于producer/consumer/broker三者而言，CPU的开支应该都不大，因此启用消息压缩机制是一个良好的策略；压缩需要消耗少量的CPU资源，不过对于kafka而言，网络IO更应该需要考虑。可以将任何在网络上传输的消息都经过压缩。kafka支持gzip/snappy等多种压缩方式。
生产者
负载均衡: producer将会和Topic下所有partition leader保持socket连接；消息由producer直接通过socket发送到broker，中间不会经过任何“路由层“。事实上，消息被路由到哪个partition上，有producer客户端决定。比如可以采用“random““key-hash““轮询“等，如果一个topic中有多个partitions，那么在producer端实现“消息均衡分发“是必要的。
其中partition leader的位置(host:port)注册在zookeeper中，producer作为zookeeper client，已经注册了watch用来监听partition leader的变更事件。
异步发送：将多条消息暂且在客户端buffer起来，并将他们批量的发送到broker，小数据IO太多，会拖慢整体的网络延迟，批量延迟发送事实上提升了网络效率。不过这也有一定的隐患，比如说当producer失效时，那些尚未发送的消息将会丢失。
消费者
consumer端向broker发送“fetch”请求，并告知其获取消息的offset；此后consumer将会获得一定条数的消息；consumer端也可以重置offset来重新消费消息。
在JMS实现中，Topic模型基于push方式，即broker将消息推送给consumer端。不过在kafka中，采用了pull方式，即consumer在和broker建立连接之后，主动去pull(或者说fetch)消息；这中模式有些优点，首先consumer端可以根据自己的消费能力适时的去fetch消息并处理，且可以控制消息消费的进度(offset)；此外，消费者可以良好的控制消息消费的数量，batch fetch。
其他JMS实现，消息消费的位置是有prodiver保留，以便避免重复发送消息或者将没有消费成功的消息重发等，同时还要控制消息的状态。这就要求JMS broker需要太多额外的工作。在kafka中，partition中的消息只有一个consumer在消费，且不存在消息状态的控制，也没有复杂的消息确认机制，可见kafka broker端是相当轻量级的。当消息被consumer接收之后，consumer可以在本地保存最后消息的offset，并间歇性的向zookeeper注册offset。由此可见，consumer客户端也很轻量级。
对于JMS实现，消息传输担保非常直接:有且只有一次(exactly once)。
在kafka中稍有不同:
at most once: 消费者fetch消息，然后保存offset，然后处理消息；当client保存offset之后，但是在消息处理过程中出现了异常，导致部分消息未能继续处理。那么此后"未处理"的消息将不能被fetch到，这就是"at most once"。
at least once: 消费者fetch消息，然后处理消息，然后保存offset。如果消息处理成功之后，但是在保存offset阶段zookeeper异常导致保存 *** 作未能执行成功，这就导致接下来再次fetch时可能获得上次已经处理过的消息，这就是"at least once"，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态。
exactly once: kafka中并没有严格的去实现(基于2阶段提交，事务)，我们认为这种策略在kafka中是没有必要的。
通常情况下“at-least-once”是我们首选。(相比at most once而言，重复接收数据总比丢失数据要好)。
kafka高可用由多个broker组成，每个broker是一个节点；
创建一个topic，这个topic会划分为多个partition，每个partition存在于不同的broker上，每个partition就放一部分数据。
kafka是一个分布式消息队列，就是说一个topic的数据，是分散放在不同的机器上，每个机器就放一部分数据。
在08版本以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。
08版本以后，才提供了HA机制，也就是就是replica副本机制。每个partition的数据都会同步到其他的机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。
写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。
kafka会均匀的将一个partition的所有replica分布在不同的机器上，从而提高容错性。
如果某个broker宕机了也没事，它上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性了。
写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。
消息丢失会出现在三个环节，分别是生产者、mq中间件、消费者：
RabbitMQ
Kafka
大体和RabbitMQ相同。
Rabbitmq
需要保证顺序的消息投递到同一个queue中，这个queue只能有一个consumer，如果需要提升性能，可以用内存队列做排队，然后分发给底层不同的worker来处理。
Kafka
写入一个partition中的数据一定是有序的。生产者在写的时候 ，可以指定一个key，比如指定订单id作为key，这个订单相关数据一定会被分发到一个partition中去。消费者从partition中取出数据的时候也一定是有序的，把每个数据放入对应的一个内存队列，一个partition中有几条相关数据就用几个内存队列，消费者开启多个线程，每个线程处理一个内存队列。
整个平台通常会包含四大部分： 物联网开发平台+（智慧生活应用 、产业互联应用）+市场运营+数据分析 。整个平台框架下的文章，我都会围绕这四大部分展开。
一、 物联网开发平台 ：设备接入、消息通信、设备管理、产品开发、监控运营以及对行业应用的动态配置管理。开发者通过平台提供的接入指引、标准物模型、SDK、API、芯片模组，实现设备与云端、App终端的消息通信、设备的控制管理，实现设备智能、设备场景控制等，并可直接通过后台对设备进行OTA升级、设备监控诊断、日志分析等。
二、 智慧生活应用 。分为智能家居、电工照明、大小家电、运动健康、宠物与植物、安防监控、节能能源、户外出行等。主要通过App作为载体给到用户进行体验。App应用包括：设备控制（家、房间）、场景、内容（图文、视频、直播）、社交、商城、论坛、众测、会员等级、积分、帮助与反馈、产品百科、在线客服等大模块。
三、 产业互联应用。 物联网平台在为智慧校园、智慧楼宇、智慧酒店、智慧街道、智慧社区、智慧城市等等各领域的应用。其实就是普通硬件变成智能硬件以后，对各个领域造成的冲击，通过物联网平台系统，对所有智能设备进行分组、分群的统一管理、控制和监控，满足各种业务场景，并延伸出一些新的玩法和新的模式，让业务和场景变得更加智能和可控。
三、 市场运营。 面对C端用户、行业用户的市场运营能力构建，通过市场活动，用户运营对公域流量、私域流量的用户进行拉新、促活、转化、留存等。像通过用户画像、用户分群、用户标签等做用户精细化的管理，通过对细分用户群体 进行邮件营销、调查问卷、短信、App通知等做一些精准营销活动。
四、 数据分析 ，基于应用端（App、设备）的用户行为、 *** 作进行数据采集（采集的数据存储在数据中台）、数据分析，并通过多维度的用户标签管理，打造出全维度、多层次的用户画像；通过构建指标体系，结合用户属性、用户标签，构建出可拖拽、可自定义的统计分析报表。你好！ 物联网是新一代信息技术的重要组成部分，也是“信息化”时代的重要发展阶段。其英文名称是：“Internet of things（IoT）”。顾名思义，物联网就是物物相连的互联网。这有两层意思：其一，物联网的核心和基础仍然是互联网，是在互联网基础上的延伸和扩展的网络；其二，其用户端延伸和扩展到了任何物品与物品之间，进行信息交换和通信，也就是物物相息。物联网通过智能感知、识别技术与普适计算等通信感知技术，广泛应用于网络的融合中，也因此被称为继计算机、互联网之后世界信息产业发展的第三次浪潮。物联网是互联网的应用拓展，与其说物联网是网络，不如说物联网是业务和应用。因此，应用创新是物联网发展的核心，以用户体验为核心的创新20是物联网发展的灵魂。
PS：以上资料来自百度百科。有很多通信模块只有TCP功能，没有MQTT功能，比如WIFI，W5500等模块，还有一些NBIOT模块，但是又想连接阿里云物联网平台，官方提供了 *** 作系统，需要自己移植，很麻烦，比较难看得懂。就在想有没有一些简单一定的方法。
心想MQTT是基于TCP的，能否使用TCP转MQTT？因此就想使用TCP协议然后转MQTT协议连接阿里云物联网平台，经过试验证明是可以的。
首先我们先分析一下如何登陆接入Onenet平台。
先从它数据格式开始分析。首先我们要从后台取出三个信息，我们以这个为例。
我们把产品ID，设备名称，设备秘钥，简称三要素 (具体是什么看你自己的设备)
其实阿里云物联网平台的MQTT协议用的就是标准的，不过它加入了自己的认证方式。
MQTT协议需要上传四个参数，报活时间，clientID，用户名，密码。
那么阿里云的就在clientID，用户名，密码做了手脚。
clientID比较长，按照一定的格式
用户名：设备名和秘钥组成
密码：使用了加密串进行了加密，有sha1或者MD5加密方式
下面我们来介绍一下
MQTT接入都是发十六进制的数据。
么我们发送的时候就是这样子的一串数据
0x74 0x00 0x04 0x4d 0x51 0x54 0x54 0x04 0xC0 0078 0033 0x61 0x62 0x63 0x7c 0x73 0x65 0x63 0x75 0x72 0x65 0x6d 0x6f 0x64 0x65 0x3d 0x33 0x2c 0x73 0x69 0x67
0x6e 0x6d 0x65 0x74 0x68 0x6f 0x64 0x3d 0x68 0x6d 0x61 0x63 0x73 0x68 0x61 0x31 0x2c 0x74 0x69 0x6d 0x65 0x73 0x74 0x61 0x6d 0x70 0x3d 0x31 0x32 0x30 0x7c 0009
0x35 0x36 0x37 0x38 0x26 0x31 0x32 0x33 0x34 0028 0x32 0x32 0x32 0x37 0x35 0x30 0x44 0x45 0x44 0x46 0x45 0x34 0x46 0x37 0x37 0x34 0x30 0x30 0x32 0x45 0x45 0x38 0x37 0x45 0x45 0x44 0x32 0x39 0x43 0x46 0x44 0x30 0x36 0x33 0x38 0x43 0x35 0x46 0x36 0x36
十六进制解释
数据长度：0x74
协议数据长度 0x00 0x04
协议类型： 0x4d 0x51 0x54 0x54
协议数据： 0x04 0xC0
keepAlive数据:0078
ClientID长度:0033
ClientID: 0x61 0x62 0x63 0x7c 0x73 0x65 0x63 0x75 0x72 0x65 0x6d 0x6f 0x64 0x65 0x3d 0x33 0x2c 0x73 0x69 0x67 0x6e 0x6d 0x65 0x74 0x68 0x6f 0x64 0x3d 0x68 0x6d 0x61 0x63 0x73 0x68 0x61 0x31 0x2c 0x74 0x69 0x6d 0x65 0x73 0x74 0x61 0x6d 0x70 0x3d 0x31 0x32 0x30 0x7c
用户名:0009
用户名: 0x35 0x36 0x37 0x38 0x26 0x31 0x32 0x33 0x34
密码长度：0028
密码: 0x32 0x32 0x32 0x37 0x35 0x30 0x44 0x45 0x44 0x46 0x45 0x34 0x46 0x37 0x37 0x34 0x30 0x30 0x32 0x45 0x45 0x38 0x37 0x45 0x45 0x44 0x32 0x39 0x43 0x46 0x44 0x30 0x36 0x33 0x38 0x43 0x35 0x46 0x36 0x36复制代码上面的就是连接服务器的连接包
下面呢，我们来做个发布包(上传数据到服务器)
0x30 0x1D 0009 2f7379732f706f7374 0x7b 0x70 0x61 0x72 0x61 0x6d 0x73 0x3a 0x7b 0x74 0x65 0x6d 0x70 0x3a 0x31 0x30 0x7d 0x7d
十六进制数据解释
数据头：0x30
数据长度：0x1D
TopicName数据长度：0009
TopicName数据内容：2f7379732f706f7374
主体json数据: 0x7b 0x70 0x61 0x72 0x61 0x6d 0x73 0x3a 0x7b 0x74 0x65 0x6d 0x70 0x3a 0x31 0x30 0x7d 0x7d复制代码以上就是连接阿里云的数据包格式及发布数据的格式，由于时间问题没有做订阅的数据包分析，下一次更新订阅的内容。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）