• 关于

    数据发送工作原理

    的搜索结果

回答

井下人员定位系统的工作原理 系统人员定位分站的无线收发数据板将低频的加密数据载波信号经发射天线向外发送;人员随身携带的KGE26标识卡进入低频的发射天线工作区域后被激活(未进入发射天线工作区域标识卡不工作),同时将加密的载有目标识别码的信息经卡内高频发射模块发射出去;接收天线接收到KGE26标识卡发来的载波信号,经分站主板接收处理后,提取出目标识别码通过通过DPSK或RS485远距离通讯线送地面监控计算机,完成矿井人员自动跟踪定位管理。 望采纳

青衫无名 2019-12-02 01:17:13 0 浏览量 回答数 0

回答

喷涂定位光栅原理:光栅自动喷涂系统通过检测工件的外形,再把检测到的工件外形数据发送到微电脑PLC,这些数据经过微电脑运算处理后去控制喷枪的开关,从而实现根据工件的外形进行精准喷涂,达到节省喷涂材料的效果。 使用自动喷涂光栅,不仅操作简单,而且维护省力,省油漆,自动化程度高、工作高效等。

马铭芳 2019-12-02 01:17:02 0 浏览量 回答数 0

回答

面试题 如何保证消息的可靠性传输?或者说,如何处理消息丢失的问题? 面试官心理分析 这个是肯定的,用 MQ 有个基本原则,就是数据不能多一条,也不能少一条,不能多,就是前面说的重复消费和幂等性问题。不能少,就是说这数据别搞丢了。那这个问题你必须得考虑一下。 如果说你这个是用 MQ 来传递非常核心的消息,比如说计费、扣费的一些消息,那必须确保这个 MQ 传递过程中绝对不会把计费消息给弄丢。 面试题剖析 数据的丢失问题,可能出现在生产者、MQ、消费者中,咱们从 RabbitMQ 和 Kafka 分别来分析一下吧。 RabbitMQ 生产者弄丢了数据 生产者将数据发送到 RabbitMQ 的时候,可能数据就在半路给搞丢了,因为网络问题啥的,都有可能。 此时可以选择用 RabbitMQ 提供的事务功能,就是生产者发送数据之前开启 RabbitMQ 事务 channel.txSelect ,然后发送消息,如果消息没有成功被 RabbitMQ 接收到,那么生产者会收到异常报错,此时就可以回滚事务 channel.txRollback ,然后重试发送消息;如果收到了消息,那么可以提交事务 channel.txCommit 。 往期回顾: 【Java问答学堂】1期 为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景? 【Java问答学堂】2期 如何保证消息队列的高可用? 【Java问答学堂】3期 如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性? 【Java问答学堂】4期 如何保证消息的可靠性传输?(如何处理消息丢失的问题?) 【Java问答学堂】5期 如何保证消息的顺序性? 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题? 【Java问答学堂】7期 如果让你写一个消息队列,该如何进行架构设计? 【Java问答学堂】8期 es 的分布式架构原理能说一下么(es 是如何实现分布式的啊)? 【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊? 【Java问答学堂】10期 es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊? 【Java问答学堂】11期 es 生产集群的部署架构是什么?每个索引的数据量大概有多少? 【Java问答学堂】12期 项目中缓存是如何使用的?为什么要用缓存?缓存使用不当会造成什么后果? 【Java问答学堂】13期 redis 和 memcached 有什么区别? 【Java问答学堂】14期 redis 都有哪些数据类型?分别在哪些场景下使用比较合适? 【Java问答学堂】15期redis 的过期策略都有哪些?内存淘汰机制都有哪些? 【Java问答学堂】16期如何保证 redis 的高并发和高可用?redis 的主从复制原理能介绍 为什么使用消息队列?【Java问答学堂】17期 消息队列有什么优点和缺点?【Java问答学堂】18期 Kafka、ActiveMQ、RabbitMQ、RocketMQ的区别?【Java问答学堂】19期 如何保证消息队列的高可用?【Java问答学堂】20期 如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性?【Java问答学堂】21期

剑曼红尘 2020-05-20 19:23:55 0 浏览量 回答数 0

Quick BI 数据可视化分析平台

2020年入选全球Gartner ABI魔力象限,为中国首个且唯一入选BI产品

问题

如何保证消息的可靠性传输?或者说,如何处理消息丢失的问题?【Java问答学堂】22期

剑曼红尘 2020-05-20 19:23:46 0 浏览量 回答数 1

回答

我理解的消息推送原理是这样的: 1. 客户端发出一个http长连接请求,然后等待服务器的响应。这个请求是异步的,所以客户端可以继续工作,比如发起其他ajax请求等等。 服务器接到请求之后,并不立即发送出数据,而是hold住这个connecton。这个处理是非阻塞的,所以服务器可以继续处理其他请求。 在某个时刻,比如服务器有新数据了,服务器再主动把这个消息推送出去,即通过之前建立好的连接将数据推送给客户端。 客户端收到返回。这个时候就可以处理数据,然后再次发起新的长连接。

游客xuhte2uigqv3o 2020-03-25 09:09:50 0 浏览量 回答数 0

回答

GPS定位系统的工作原理是由地面主控站收集各监测站的观测资料和气象信息,计算各卫星的星 历表及卫星钟改正数,按规定的格式编辑导航电文,通过地面上的注入站向GPS卫星注入这些信 息。测量定位时,用户可以利用接收机的储存星历得到各个卫星的粗略位置。根据这些数据和自 身位置,由计算机选择卫星与用户联线之间张角较大的四颗卫星作为观测对象。观测时,接收机利 用码发生器生成的信息与卫星接收的信号进行相关处理,并根据导航电文的时间标和子帧计数测 量用户和卫星之间的伪距。将修正后的伪距及输入的初始数据及四颗卫星的观测值列出3个观测 方程式,即可解出接收机的位置,并转换所需要的坐标系统,以达到定位目的。 解锁原理: 共享单车智能锁中SKC111的中心控制单元通过GPRS无线通信模块与后台管理系统进行连接, 把从GPS+BDS模块获取的位置信息发送给后台管理系统;同时支持上传单车智能锁的电量信 息。 后台管理系统通过共享单车GPRS无线通信模块向中心控制单元发送解锁指令,中心控制系统接 收到后台发送的解锁指令后,通过GPIO接口控制机电锁装置(一般是小马达)进行开锁。 自行车解锁特点: 共享单车开锁方式为直接由服务器通过单车GPRS模块流量传达指令开锁。这种开锁方式速度 快,用户体验好。摩拜单车和部分新型小黄车采用这种方式。但这种开锁成功率依赖智能锁的 信号强度,在信号较弱地区容易开锁失败。 解锁的其他方式: 1、用户可以通过手机蓝牙和单车智能锁中的蓝牙模块进行通讯,并发送该信息到服务器端。后 台管理系统向用户手机中安装的app发送开锁指令,用户手机接收到后台管理系统的指令后通 手机蓝牙对共享单车蓝牙进行控制开锁。 特点:GPRS+蓝牙辅助开锁是目前主流共享单车采用的方式,优点是开锁功耗降低,不需要依 赖智能锁中模块的信号强度,用户体验好。 2、用户手机安装APP后,扫描车身二维码识别后,蓝牙芯片通过共享手机的GPS定位,获得共 享单车的位置信息,并把信息传输给云端平台。后台管理系统向用户手机中安装的app发送开 锁指令,用户手机接收到后台管理系统的指令后通手机蓝牙对共享单车蓝牙进行控制开锁。 特点:此种开锁方案中,用户通过手机中的APP完成与单车管理后台的交互,再由用户手机的 蓝牙来完成与蓝牙智能锁的交互,完成开锁和闭锁功能。

玄学酱 2019-12-02 01:17:17 0 浏览量 回答数 0

问题

Redis 集群模式的工作原理能说一下么?【Java问答】36期

剑曼红尘 2020-06-12 15:07:18 2 浏览量 回答数 1

回答

1、解决方案: ftp默认模式为被动模式,开启一个随机端口建立连接。需要把内网端口限制打开, 如果是通过硬件防火墙,将防火墙开启ftp随机端口就可以了 2、两种方式的工作原理: 主动模式: Port模式FTP 客户端首先和FTP服务器的TCP 21端口建立连接,通过这个通道发送命令,客户端需要接收数据的时候在这个通道上发送PORT命令。 PORT命令包含了客户端用什么端口接收数据。在传送数据的时候,服务器端通过自己的TCP 20端口连接至客户端的指定端口发送数据。 FTP server必须和客户端建立一个新的连接用来传送数据。(可以看到在这种方式下是客户端和服务器建立控制连接,服务器向客户端建立数据连接,其中,客户端的控制连接和数据连接的端口号是大于1024的两个端口号(临时端口),而FTP服务器的数据端口为20,控制端口为21) 被动模式:  Passive模式在建立控制通道的时候和Standard模式类似,但建立连接后发送的不是Port命令,而是Pasv命令。FTP服务器收到Pasv命令后,随机打开一个临时端口(也叫自由端口,端口号大于1023小于65535)并且通知客户端在这个端口上传送数据的请求,客户端连接FTP服务器此端口,然后FTP服务器将通过这个端口进行数据的传送,这个时候FTP server不再需要建立一个新的和客户端之间的连接。(可以看到这种情况下的连接都是由客户端向服务器发起的,与下面所说的“为了解决服务器发起到客户的连接的问题,人们开发了一种不同的FTP连接方式。这就是所谓的被动方式”相对应,而服务器端的数据端口是临时端口,而不是常规的20) 很多防火墙在设置的时候都是不允许接受外部发起的连接的,所以许多位于防火墙后或内网的FTP服务器不支持PASV模式,因为客户端无法穿过防火墙打开FTP服务器的高端端口;而许多内网的客户端不能用PORT模式登陆FTP服务器,因为从服务器的TCP 20无法和内部网络的客户端建立一个新的连接,造成无法工作。 主动模式要求客户端和服务器端同时打开并且监听一个端口以建立连接。在这种情况下,客户端由于安装了防火墙会产生一些问题。所以,创立了被动模式。被动模式只要求服务器端产生一个监听相应端口的进程,这样就可以绕过客户端安装了防火墙的问题。 在被动方式FTP中,命令连接和数据连接都由客户端发起,这样就可以解决从服务器到客户端的数据端口的入方向连接被防火墙过滤掉的问题。 “答案来源于网络,供您参考”

牧明 2019-12-02 02:15:30 0 浏览量 回答数 0

回答

RAS:不对称加密算法 不对称加密算法使用两把完全不同但又是完全匹配的一对钥匙—公钥和私钥。在使用不对称加密算法加密文件时,只有使用匹配的一对公钥和私钥,才能完成对明文的加密和解密过程。加密明文时采用公钥加密,解密密文时使用私钥才能完成,而且发信方(加密者)知道收信方的公钥,只有收信方(解密者)才是唯一知道自己私钥的人。不对称加密算法的基本原理是,如果发信方想发送只有收信方才能解读的加密信息,发信方必须首先知道收信方的公钥,然后利用收信方的公钥来加密原文;收信方收到加密密文后,使用自己的私钥才能解密密文。显然,采用不对称加密算法,收发信双方在通信之前,收信方必须将自己早已随机生成的公钥送给发信方,而自己保留私钥。由于不对称算法拥有两个密钥,因而特别适用于分布式系统中的数据加密。广泛应用的不对称加密算法有RSA算法和美国国家标准局提出的DSA。以不对称加密算法为基础的加密技术应用非常广泛。 DES算法 DES算法为密码体制中的对称密码体制,又被成为美国数据加密标准,是1972年美国IBM公司研制的对称密码体制加密算法。 其密钥长度为56位,明文按64位进行分组,将分组后的明文组和56位的密钥按位替代或交换的方法形成密文组的加密方法。 DES加密算法特点:分组比较短、密钥太短、密码生命周期短、运算速度较慢。 DES工作的基本原理是,其入口参数有三个:key、data、mode。 key为加密解密使用的密钥,data为加密解密的数据,mode为其工作模式。当模式为加密模式时,明文按照64位进行分组,形成明文组,key用于对数据加密,当模式为解密模式时,key用于对数据解密。实际运用中,密钥只用到了64位中的56位,这样才具有高的安全性。

小哇 2019-12-02 01:26:22 0 浏览量 回答数 0

问题

如何自己设计一个类似 Dubbo 的 RPC 框架?【Java问答学堂】54期

剑曼红尘 2020-07-09 10:30:28 30 浏览量 回答数 1

问题

【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊?

剑曼红尘 2020-04-27 14:35:38 0 浏览量 回答数 1

回答

数据保护是指数据传输(上传数据至OSS、从OSS下载数据)过程中和处于静止状态(数据存储在OSS数据中心磁盘)期间保护数据。传输中的数据可以通过SSL或者客户端加密进行保护。静态数据可以通过以下方式进行保护: 服务器端加密 OSS将数据保存到数据中心的磁盘之前进行加密,并且在下载对象时自动进行解密。 客户端加密 可以使用客户端加密SDK,在本地进行数据加密,并将加密后的数据上传到OSS。在这种场景下,用户需要管理加密过程以及加密密钥。 说明:目前只有Python SDK支持客户端加密。代码示例请参见Python SDK客户端加密。 采用客户端加密SDK保护数据 客户端加密是指将数据发送到OSS之前在用户本地进行加密,对于数据加密密钥的使用,目前支持如下两种方式: 使用KMS托管用户主密钥使用用户自主管理密钥 使用KMS托管用户主密钥 当使用KMS托管用户主密钥用于客户端数据加密时,无需向OSS加密客户端提供任何加密密钥。只需要在上传对象时指定KMS用户主密钥ID(也就是CMK ID)。其具体工作原理如下图所示。 上传对象。 通过使用CMK ID,客户端首先向KMS发送一个请求,申请1个用于加密对象的数据密钥(Data Key)。作为响应,KMS会返回一个随机生成的数据明文密钥(Data Key)以及一个数据密文密钥(Encrypted Data Key)。 本地加密数据。 本地客户端接收到KMS返回的数据明文密钥以及数据密文密钥后,将使用数据明文密钥进行本地加密,并且将加密后的对象以及数据密文密钥上传至OSS。 下载对象。 客户端首先会从OSS服务端下载加密的对象以及作为对象元数据存储的数据密文密钥。 解密数据。 客户端将数据密文密钥以及CMK ID发送至KMS服务器。作为响应,KMS将使用指定的CMK解密,并且将数据明文密钥返回给本地加密客户端。 使用用户自主管理密钥 使用用户自主管理密钥,需要用户自主生成并保管加密密钥。当用户本地客户端加密时,由用户自主上传加密密钥(对称加密密钥或者非对称加密密钥)至本地加密客户端。其具体加密过程如下图所示。 上传对象。 用户首先向本地加密客户端提供1个用户主密钥(对称密钥或者非对称密钥)。客户端只使用此主密钥加密其随机生成的数据密钥。该过程如下: OSS本地加密客户端在本地生成一个一次性的对称密钥,即数据密钥(Data Key)。它将用于加密单个对象(针对每个对象,客户端都会随机生成1个数据密钥)。 客户端使用数据密钥加密对象。 客户端使用用户提供的主密钥来加密数据密钥。 客户端将加密的数据密钥(Encrypted Data Key)作为对象元数据的一部分上传至OSS。 下载对象。 下载对象时,客户端首先从OSS下载加密的对象以及元数据。通过使用元数据中的材料,客户端将授权确定使用哪个主密钥来解密加密的数据密钥。客户端使用解密后的数据密钥来解密对象。

剑曼红尘 2020-03-26 18:26:27 0 浏览量 回答数 0

问题

dubbo 支持的通信协议?有哪些序列化协议?说下 Hessian 的数据结构?【Java问答】48

剑曼红尘 2020-07-01 15:18:43 7 浏览量 回答数 1

回答

每当您要将数据发送到具有纯ASCII无法表示的字符(例如“ñ”或“ö”)的服务器时,都需要使用它。 如果MySQL实例未配置为默认情况下期望来自客户端连接的UTF-8编码(很多情况取决于您的位置和平台)。 如果您不了解Unicode的工作原理,请阅读http://www.joelonsoftware.com/articles/Unicode.html。 阅读是否使用“ SET NAMES”来查看SET NAMES的替代方案以及其确切含义。

保持可爱mmm 2020-05-10 19:36:23 0 浏览量 回答数 0

问题

ES 写入数据的工作原理是什么啊?ES 查询数据的工作原理是什么啊?【Java问答学堂】27期

剑曼红尘 2020-05-27 20:28:45 22 浏览量 回答数 1

问题

zookeeper 都有哪些使用场景?【Java问答学堂】56期

剑曼红尘 2020-07-13 21:37:59 75 浏览量 回答数 1

问题

了解什么是 Redis 的雪崩、穿透和击穿?Redis 崩溃之后会怎么样?【Java问答】37期

剑曼红尘 2020-06-17 13:17:18 31 浏览量 回答数 1

问题

电商网站的商品详情页系统架构【Java问答学堂】61期

剑曼红尘 2020-07-20 13:08:17 1 浏览量 回答数 1

问题

HBase最佳实践-读性能优化策略

pandacats 2019-12-20 21:02:08 0 浏览量 回答数 0

问题

分布式事务了解吗?你们是如何解决分布式事务问题的?【Java问答学堂】58期

剑曼红尘 2020-07-16 15:11:28 5 浏览量 回答数 1

问题

如何保证缓存与数据库的双写一致性?【Java问答】38期

剑曼红尘 2020-06-16 12:58:57 36 浏览量 回答数 1

问题

如何保证消息的顺序性?【Java问答学堂】23期

剑曼红尘 2020-05-21 19:11:53 27 浏览量 回答数 1

问题

Redis 和 Memcached 的区别?Redis 的线程模型是什么?【Java问答学堂】31期

剑曼红尘 2020-06-03 20:28:14 28 浏览量 回答数 1

回答

使用自定义资源,您可以在模板中编写自定义配置逻辑,每次创建、更新(如果您更改了自定义资源)或删除资源栈时,阿里云ROS都会运行该逻辑。例如,您可能需要包含不可作为阿里云ROS资源类型的资源。您可以使用自定义资源包含这些资源。这样,您仍然可以在一个资源栈中管理所有相关资源。 自定义资源介绍 使用ALIYUN::ROS::CustomResource或Custom::MyCustomResourceTypeName资源类型在模板中定义自定义资源。自定义资源需要一个属性,即服务令牌,它指定阿里云ROS发送请求的目标,如阿里云MNS(消息服务)主题&队列,阿里云FC(函数计算)函数,或HTTP&HTTPS服务。 自定义资源必须将响应发送到预签名的响应URL。如果不能向ROS发送响应,阿里云ROS不会收到响应,资源栈操作就会失败。ResponseURL提供了公网响应的能力,IntranetResponseURL提供了阿里云内网响应的能力。 自定义资源的工作原理 自定义资源执行的任何操作均涉及三方。 template developer:创建包含自定义资源类型的模板。template developer在模板中指定服务令牌和所有输入数据。 custom resource provider:拥有自定义资源并确定如何处理和响应来自阿里云ROS的请求。custom resource provider必须提供template developer使用的服务令牌。 阿里云ROS:在资源栈操作期间,向模板中指定的服务令牌发送请求,然后等待响应,再继续资源栈操作。 template developer和custom resource provider可以是同一人员或实体,但过程相同。一般步骤如下: template developer在其模板中定义自定义资源,该模板包含服务令牌和任何输入数据参数。根据自定义资源,输入数据可能是必需;但是,服务令牌总是必需的。 服务令牌指定阿里云ROS将请求发送到的位置,例如发送到阿里云MNS主题ARN或阿里云FC函数ARN。有关更多信息,请参见 ALIYUN::ROS::CustomResource。服务令牌和输入数据的结构由custom resource provider定义。 当您使用模板创建、更新或删除自定义资源时,阿里云ROS将向指定服务令牌发送请求。服务令牌无区域限制。 在请求中,阿里云ROS包含请求类型和自定义资源向其发送请求的预签名URL等信息。有关请求中包含内容的更多信息,请参见自定义资源请求对象。 以下示例数据显示阿里云ROS在请求中包含哪些内容: { "RequestType" : "Create", "RequestId" : "unique id for this create request", "ResponseURL" : "pre-signed-url-for-create-response", "IntranetResponseURL" : "pre-signed-intranet-url-for-create-response", "ResourceType" : "Custom::MyCustomResourceType", "LogicalResourceId" : "name of resource in template", "StackId" : "stack id", "StackName" : "stack name", "ResourceOwnerId": "resource owner id", "CallerId": "caller id", "RegionId": "region id", "ResourceProperties" : { "key1" : "string", "key2" : [ "list" ], "key3" : { "key4" : "map" } } } custom resource provider处理阿里云ROS请求并向预签名URL返回SUCCESS或FAILED响应。custom resource provider提供采用JSON格式数据响应URL。 在响应中,custom resource provider还可以包含template developer。例如,如果请求成功,响应可以包含输出数据,如果请求失败,可以包含错误消息。有关响应的更多信息,请参见自定义资源响应对象。 custom resource provider负责侦听和响应请求。例如,对于阿里云MNS主题通知,custom resource provider必须侦听并响应发送到特定主题ARN的通知。阿里云ROS在预签名URL位置等待并侦听响应。 以下示例数据说明自定义资源在响应中可以包含的内容: { "Status" : "SUCCESS", "RequestId" : "unique id for this create request (copied from request)", "LogicalResourceId" : "name of resource in template (copied from request)", "StackId" : "stack id (copied from request)", "PhysicalResourceId" : "required vendor-defined physical id that is unique for that vendor", "Data" : { "keyThatCanBeUsedInGetAtt1" : "data for key 1", "keyThatCanBeUsedInGetAtt2" : "data for key 2" } } 获得SUCCESS响应后,阿里云ROS继续堆栈操作。如果收到FAILED响应或未返回任何响应,则操作失败。来自自定义资源的所有输出数据都由预签名URL响应返回。template developer可使用Fn::GetAtt函数检索该数据。

1934890530796658 2020-03-24 17:48:31 0 浏览量 回答数 0

回答

MQTT协议 MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)最早是IBM开发的一个即时通讯协议,MQTT协议是为大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备通讯而设计的一种协议。 MQTT协议的优势是可以支持所有平台,它几乎可以把所有的联网物品和互联网连接起来。 它具有以下主要的几项特性:1、使用发布/订阅消息模式,提供一对多的消息发布和应用程序之间的解耦;2、消息传输不需要知道负载内容;3、使用 TCP/IP 提供网络连接;4、有三种消息发布的服务质量:QoS 0:“最多一次”,消息发布完全依赖底层 TCP/IP 网络。分发的消息可能丢失或重复。例如,这个等级可用于环境传感器数据,单次的数据丢失没关系,因为不久后还会有第二次发送。QoS 1:“至少一次”,确保消息可以到达,但消息可能会重复。QoS 2:“只有一次”,确保消息只到达一次。例如,这个等级可用在一个计费系统中,这里如果消息重复或丢失会导致不正确的收费。5、小型传输,开销很小(固定长度的头部是 2 字节),协议交换最小化,以降低网络流量;6、使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制;在MQTT协议中,一个MQTT数据包由:固定头(Fixed header)、 可变头(Variable header)、 消息体(payload)三部分构成。MQTT的传输格式非常精小,最小的数据包只有2个bit,且无应用消息头。下图是MQTT为可靠传递消息的三种消息发布服务质量 发布/订阅模型允许MQTT客户端以一对一、一对多和多对一方式进行通讯。 下图是MQTT的发布/订阅消息模式 CoAP协议 CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。由于目前物联网中的很多设备都是资源受限型的,所以只有少量的内存空间和有限的计算能力,传统的HTTP协议在物联网应用中就会显得过于庞大而不适用。因此,IETF的CoRE工作组提出了一种基于REST架构、传输层为UDP、网络层为6LowPAN(面向低功耗无线局域网的IPv6)的CoAP协议。 CoAP采用与HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。CON——需要被确认的请求,如果CON请求被发送,那么对方必须做出响应。NON——不需要被确认的请求,如果NON请求被发送,那么对方不必做出回应。ACK——应答消息,接受到CON消息的响应。RST——复位消息,当接收者接受到的消息包含一个错误,接受者解析消息或者不再关心发送者发送的内容,那么复位消息将会被发送。 CoAP消息格式使用简单的二进制格式,最小为4个字节。 一个消息=固定长度的头部header + 可选个数的option + 负载payload。Payload的长度根据数据报长度来计算。 主要是一对一的协议 举个例子: 比如某个设备需要从服务器端查询当前温度信息。 请求消息(CON): GET /temperature , 请求内容会被包在CON消息里面响应消息 (ACK): 2.05 Content “22.5 C” ,响应内容会被放在ACK消息里面 CoAP与MQTT的区别 MQTT和CoAP都是行之有效的物联网协议,但两者还是有很大区别的,比如MQTT协议是基于TCP,而CoAP协议是基于UDP。从应用方向来分析,主要区别有以下几点: 1、MQTT协议不支持带有类型或者其它帮助Clients理解的标签信息,也就是说所有MQTT Clients必须要知道消息格式。而CoAP协议则相反,因为CoAP内置发现支持和内容协商,这样便能允许设备相互窥测以找到数据交换的方式。 2、MQTT是长连接而CoAP是无连接。MQTT Clients与Broker之间保持TCP长连接,这种情形在NAT环境中也不会产生问题。如果在NAT环境下使用CoAP的话,那就需要采取一些NAT穿透性手段。 3、MQTT是多个客户端通过中央代理进行消息传递的多对多协议。它主要通过让客户端发布消息、代理决定消息路由和复制来解耦消费者和生产者。MQTT就是相当于消息传递的实时通讯总线。CoAP基本上就是一个在Server和Client之间传递状态信息的单对单协议。 HTTP协议http的全称是HyperText Transfer Protocol,超文本传输协议,这个协议的提出就是为了提供和接收HTML界面,通过这个协议在互联网上面传出web的界面信息。 HTTP协议的两个过程,Request和Response,两个都有各自的语言格式,我们看下是什么。请求报文格式:(注意这里有个换行) 响应报文格式:(注意这里有个换行) 方法method:       这个很重要,比如说GET和POST方法,这两个是很常用的,GET就是获取什么内容,而POST就是向服务器发送什么数据。当然还有其他的,比如HTTP 1.1中还有:DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8个方法(HTTP Method历史:HTTP 0.9 只有GET方法;HTTP 1.0 有GET、POST、HEAD三个方法)。请求URL:       这里填写的URL是不包含IP地址或者域名的,是主机本地文件对应的目录地址,所以我们一般看到的就是“/”。版本version:       格式是HTTP/.这样的格式,比如说HTTP/1.1.这个版本代表的就是我们使用的HTTP协议的版本,现在使用的一般是HTTP/1.1状态码status:       状态码是三个数字,代表的是请求过程中所发生的情况,比如说200代表的是成功,404代表的是找不到文件。原因短语reason-phrase:       是状态码的可读版本,状态码就是一个数字,如果你事先不知道这个数字什么意思,可以先查看一下原因短语。首部header:       注意这里的header我们不是叫做头,而是叫做首部。可能有零个首部也可能有多个首部,每个首部包含一个名字后面跟着一个冒号,然后是一个可选的空格,接着是一个值,然后换行。实体的主体部分entity-body:       实体的主体部分包含一个任意数据组成的数据块,并不是所有的报文都包含实体的主体部分,有时候只是一个空行加换行就结束了。 下面我们举个简单的例子: 请求报文:GET /index.html HTTP/1.1    Accept: text/*Host: www.myweb.com 响应报文:HTTP/1.1 200 OKContent-type: text/plainContent-length: 3  HTTP与CoAP的区别 CoAP是6LowPAN协议栈中的应用层协议,基于REST(表述性状态传递)架构风格,支持与REST进行交互。通常用户可以像使用HTTP协议一样用CoAP协议来访问物联网设备。而且CoAP消息格式使用简单的二进制格式,最小为4个字节。HTTP使用报文格式对于嵌入式设备来说需要传输数据太多,太重,不够灵活。 XMPP协议 XMPP(可扩展通讯和表示协议)是一种基于可扩展标记语言(XML)的协议, 它继承了在XML环境中灵活的发展性。可用于服务类实时通讯、表示和需求响应服务中的XML数据元流式传输。XMPP以Jabber协议为基础,而Jabber是即时通讯中常用的开放式协议。   基本网络结构 XMPP中定义了三个角色,客户端,服务器,网关。通信能够在这三者的任意两个之间双向发生。 服务器同时承担了客户端信息记录,连接管理和信息的路由功能。网关承担着与异构即时通信系统 的互联互通,异构系统可以包括SMS(短信),MSN,ICQ等。基本的网络形式是单客户端通过 TCP/IP连接到单服务器,然后在之上传输XML。 功能 传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送(比如QQ),要么用纯文本指令加空格加参数加换行符的方式发送(比如MSN)。而XMPP传输的即时通讯指令的逻辑与以往相仿,只是协议的形式变成了XML格式的纯文本。举个例子看看所谓的XML(标准通用标记语言的子集)流是什么样子的?客户端:123456<?xmlversion='1.0'?>to='example_com'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>服务器:1234567<?xmlversion='1.0'?>from='example_com'id='someid'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>工作原理XMPP核心协议通信的基本模式就是先建立一个stream,然后协商一堆安全之类的东西, 中间通信过程就是客户端发送XML Stanza,一个接一个的。服务器根据客户端发送的信息 以及程序的逻辑,发送XML Stanza给客户端。但是这个过程并不是一问一答的,任何时候 都有可能从一方发信给另外一方。通信的最后阶段是关闭流,关闭TCP/IP连接。  网络通信过程中数据冗余率非常高,网络流量中70% 都消耗在 XMPP 协议层了。对于物联网来说,大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备,省电、省流量是所有底层服务的一个关键技术指标,XMPP协议看起来已经落后了。 SoAP协议 SoAP(简单对象访问协议)是交换数据的一种协议规范,是一种轻量的、简单的、 基于可扩展标记语言(XML)的协议,它被设计成在WEB上交换结构化的和固化的信息。  SOAP 可以和现存的许多因特网协议和格式结合使用,包括超文本传输协议(HTTP), 简单邮件传输协议(SMTP),多用途网际邮件扩充协议(MIME)。它还支持从消息系统到 远程过程调用(RPC)等大量的应用程序。SOAP使用基于XML的数据结构和超文本传输协议 (HTTP)的组合定义了一个标准的方法来使用Internet上各种不同操作环境中的分布式对象。 总结: 从当前物联网应用发展趋势来分析,MQTT协议具有一定的优势。因为目前国内外主要的云计算服务商,比如阿里云、AWS、百度云、Azure以及腾讯云都一概支持MQTT协议。还有一个原因就是MQTT协议比CoAP成熟的要早,所以MQTT具有一定的先发优势。但随着物联网的智能化和多变化的发展,后续物联网应用平台肯定会兼容更多的物联网应用层协议。 作者:HFK_Frank 来源:CSDN 原文:https://blog.csdn.net/acongge2010/article/details/79142380 版权声明:本文为博主原创文章,转载请附上博文链接!

auto_answer 2019-12-02 01:55:21 0 浏览量 回答数 0

回答

北斗导航系统 北斗卫星导航定位系统,是中国自行研制开发的区域性有源三维卫星定位与通信系统(CNSS),是除美国的GPS、俄罗斯的GLONASS之后第三个成熟的卫星导航系统。 该系统由三颗(两颗工作卫星、一颗备用卫星)北斗定位卫星(北斗一号)、地面控制中心为主的地面部份、北斗用户终端三部分组成。可向用户提供全天候、二十四小时的即时定位服务,定位精度可达数十柰秒(ns)的同步精度,其精度与GPS相当。 三颗导航定位卫星的发射时间分别为: 2000年10月31日; 2000年12月21日; 2003年5月25日,第三颗是备用卫星。 系统构成与工作原理 北斗卫星导航定位系统的系统构成有:两颗地球静止轨道卫星、地面中心站、用户终端。 北斗卫星导航定位系统的基本工作原理是“双星定位”:以2颗在轨卫星的已知坐标为圆心,各以测定的卫星至用户终端的距离为半径,形成2个球面,用户终端将位于这2个球面交线的圆弧上。地面中心站配有电子高程地图,提供一个以地心为球心、以球心至地球表面高度为半径的非均匀球面。用数学方法求解圆弧与地球表面的交点即可获得用户的位置。 由于在定位时需要用户终端向定位卫星发送定位信号,由信号到达定位卫星时间的差值计算用户位置,所以被称为“有源定位”。 北斗星导航系统与GPS系统比较 1、覆盖范围:北斗导航系统是覆盖中国本土的区域导航系统。覆盖范围东经约70°一140°,北纬5°一55°。GPS是覆盖全球的全天候导航系统。能够确保地球上任何地点、任何时间能同时观测到6-9颗卫星(实际上最多能观测到11颗)。 2、卫星数量和轨道特性:北斗导航系统是在地球赤道平面上设置2颗地球同步卫星颗卫星的赤道角距约60°。GPS是在6个轨道平面上设置24颗卫星,轨道赤道倾角55°,轨道面赤道角距60°。航卫星为准同步轨道,绕地球一周11小时58分。 3、定位原理:北斗导航系统是主动式双向测距二维导航。地面中心控制系统解算,供用户三维定位数据。GPS是被动式伪码单向测距三维导航。由用户设备独立解算自己三维定位数据。“北斗一号”的这种工作原理带来两个方面的问题,一是用户定位的同时失去了无线电隐蔽性,这在军事上相当不利,另一方面由于设备必须包含发射机,因此在体积、重量上、价格和功耗方面处于不利的地位。 4、定位精度:北斗导航系统三维定位精度约几十米,授时精度约100ns。GPS三维定位精度P码目前己由16m提高到6m,C/A码目前己由25-100m提高到12m,授时精度日前约20ns。 5、用户容量:北斗导航系统由于是主动双向测距的询问--应答系统,用户设备与地球同步卫星之间不仅要接收地面中心控制系统的询问信号,还要求用户设备向同步卫星发射应答信号,这样,系统的用户容量取决于用户允许的信道阻塞率、询问信号速率和用户的响应频率。因此,北斗导航系统的用户设备容量是有限的。GPS 是单向测距系统,用户设备只要接收导航卫星发出的导航电文即可进行测距定位,因此GPS的用户设备容量是无限的。 6、生存能力:和所有导航定位卫星系统一样,“北斗一号”基于中心控制系统和卫星的工作,但是“北斗一号”对中心控制系统的依赖性明显要大很多,因为定位解算在那里而不是由用户设备完成的。为了弥补这种系统易损性,GPS正在发展星际横向数据链技术,使万一主控站被毁后GPS卫星可以独立运行。而“北斗一号” 系统从原理上排除了这种可能性,一旦中心控制系统受损,系统就不能继续工作了。 7、实时性:“北斗一号”用户的定位申请要送回中心控制系统,中心控制系统解算出用户的三维位置数据之后再发回用户,其间要经过地球静止卫星走一个来回,再加上卫星转发,中心控制系统的处理,时间延迟就更长了,因此对于高速运动体,就加大了定位的误差。此外,“北斗一号”卫星导航系统也有一些自身的特点,其具备的短信通讯功能就是GPS所不具备的。 中新网西昌4月14日电 (记者 孙自法) 中国有关部门负责人十四日在此间表示,在未来几年里,中国将陆续发射系列北斗导航卫星,计划二○○八年左右满足中国及周边地区用户对卫星导航系统的需求,并进行系统组网和试验,逐步扩展为全球卫星导航系统。   当天凌晨,中国在西昌卫星发射中心用“长征三号甲”运载火箭,成功将一颗北斗导航卫星送入太空。而两个月前,中国已在西昌成功发射一颗北斗导航试验卫星。   中国这个要逐步扩展为全球卫星导航系统的北斗导航系统(COMPASS),将主要用于国家经济建设,为中国的交通运输、气象、石油、海洋、森林防火、灾害预报、通信、公安以及其他特殊行业提供高效的导航定位服务。   据悉,建设中的中国北斗导航系统(COMPASS)空间段计划由五颗静止轨道卫星和三十颗非静止轨道卫星组成,提供两种服务方式,即开放服务和授权服务。   卫星导航系统为人类带来了巨大的社会和经济效益,目前世界上只有少数几个国家能够自主研制生产卫星导航系统,正在运行的有美国的GPS系统和俄罗斯的GLONASS系统,欧洲的伽利略全球卫星定位计划也在紧锣密鼓地进行当中。(完) 中关宝评论:随着此星的发射及随后的计划,中国北斗导航系统已将已前北以前的北斗双星定位概概念改变,中国也即将成为世界的卫星导航定位强国。

聚小编 2019-12-02 01:16:55 0 浏览量 回答数 0

回答

Lease 机制是最重要的分布式协议,广泛应用于各种实际的分布式系统中。 基于lease 的分布式cache 系统 基本的问题背景如下:在一个分布式系统中,有一个中心服务器节点,中心服务器存储、维护 着一些数据,这些数据是系统的元数据。系统中其他的节点通过访问中心服务器节点读取、修改其 上的元数据。由于系统中各种操作都依赖于元数据,如果每次读取元数据的操作都访问中心服务器 节点,那么中心服务器节点的性能成为系统的瓶颈。为此,设计一种元数据cache,在各个节点上 cache 元数据信息,从而减少对中心服务器节点的访问,提高性能。另一方面,系统的正确运行严 格依赖于元数据的正确,这就要求各个节点上cache 的数据始终与中心服务器上的数据一致,cache 中的数据不能是旧的脏数据。最后,设计的cache 系统要能最大可能的处理节点宕机、网络中断等 异常,最大程度的提高系统的可用性。 为此,利用lease 机制设计一套cache 系统,其基本原理为如下。中心服务器在向各节点发送数 据时同时向节点颁发一个lease。每个lease 具有一个有效期,和信用卡上的有效期类似,lease 上的 有效期通常是一个明确的时间点,例如12:00:10,一旦真实时间超过这个时间点,则lease 过期失效。 这样lease 的有效期与节点收到lease 的时间无关,节点可能收到lease 时该lease 就已经过期失效。 这里首先假设中心服务器与各节点的时钟是同步的,下节中讨论时钟不同步对lease 的影响。中心服 务器发出的lease 的含义为:在lease 的有效期内,中心服务器保证不会修改对应数据的值。因此, 节点收到数据和lease 后,将数据加入本地Cache,一旦对应的lease 超时,节点将对应的本地cache 数据删除。中心服务器在修改数据时,首先阻塞所有新的读请求,并等待之前为该数据发出的所有 lease 超时过期,然后修改数据的值。 基于lease 的cache,客户端节点读取元数据 判断元数据是否已经处于本地cache 且lease 处于有效期内 1.1 是:直接返回cache 中的元数据 1.2 否:向中心服务器节点请求读取元数据信息 1.2.1 服务器收到读取请求后,返回元数据及一个对应的lease 1.2.2 客户端是否成功收到服务器返回的数据 1.2.2.1 失败或超时:退出流程,读取失败,可重试 1.2.2.2 成功:将元数据与该元数据的lease 记录到内存中,返回元数据 基于lease 的cache,客户端节点修改元数据流程 2.1 节点向服务器发起修改元数据请求。 2.2 服务器收到修改请求后,阻塞所有新的读数据请求,即接收读请求,但不返回数据。 2.3 服务器等待所有与该元数据相关的lease 超时。 2.4 服务器修改元数据并向客户端节点返回修改成功。 上述机制可以保证各个节点上的cache 与中心服务器上的中心始终一致。这是因为中心服务器 节点在发送数据的同时授予了节点对应的lease,在lease 有效期内,服务器不会修改数据,从而客 户端节点可以放心的在lease 有效期内cache 数据。上述lease 机制可以容错的关键是:服务器一旦 发出数据及lease,无论客户端是否收到,也无论后续客户端是否宕机,也无论后续网络是否正常, 服务器只要等待lease 超时,就可以保证对应的客户端节点不会再继续cache 数据,从而可以放心的 修改数据而不会破坏cache 的一致性。 上述基础流程有一些性能和可用性上的问题,但可以很容易就优化改性。优化点一:服务器在 修改元数据时首先要阻塞所有新的读请求,造成没有读服务。这是为了防止发出新的lease 从而引起 不断有新客户端节点持有lease 并缓存着数据,形成“活锁”。优化的方法很简单,服务器在进入修 改数据流程后,一旦收到读请求则只返回数据但不颁发lease。从而造成在修改流程执行的过程中, 客户端可以读到元数据,只是不能缓存元数据。进一步的优化是,当进入修改流程,服务器颁发的 lease 有效期限选择为已发出的lease 的最大有效期限。这样做,客户端可以继续在服务器进入修改 流程后继续缓存元数据,但服务器的等待所有lease 过期的时间也不会因为颁发新的lease 而不断延 长。 最后,=cache 机制与多副本机制的区别。Cache 机制与多副本机制的相似之处都 是将一份数据保存在多个节点上。但Cache 机制却要简单许多,对于cache 的数据,可以随时删除 丢弃,并命中cache 的后果仅仅是需要访问数据源读取数据;然而副本机制却不一样,副本是不能 随意丢弃的,每失去一个副本,服务质量都在下降,一旦副本数下降到一定程度,则往往服务将不 再可用。 lease 机制的分析 lease 的定义:Lease 是由颁发者授予的在某一有效期内的承诺。颁发者一旦发 出lease,则无论接受方是否收到,也无论后续接收方处于何种状态,只要lease 不过期,颁发者一 定严守承诺;另一方面,接收方在lease 的有效期内可以使用颁发者的承诺,但一旦lease 过期,接 收方一定不能继续使用颁发者的承诺。 Lease 机制具有很高的容错能力。首先,通过引入有效期,Lease 机制能否非常好的容错网络异 常。Lease 颁发过程只依赖于网络可以单向通信,即使接收方无法向颁发者发送消息,也不影响lease 的颁发。由于lease 的有效期是一个确定的时间点,lease 的语义与发送lease 的具体时间无关,所以 同一个lease 可以被颁发者不断重复向接受方发送。即使颁发者偶尔发送lease 失败,颁发者也可以 简单的通过重发的办法解决。一旦lease 被接收方成功接受,后续lease 机制不再依赖于网络通信, 即使网络完全中断lease 机制也不受影响。再者,Lease 机制能较好的容错节点宕机。如果颁发者宕 机,则宕机的颁发者通常无法改变之前的承诺,不会影响lease 的正确性。在颁发者机恢复后,如果 颁发者恢复出了之前的lease 信息,颁发者可以继续遵守lease 的承诺。如果颁发者无法恢复lease 信息,则只需等待一个最大的lease 超时时间就可以使得所有的lease 都失效,从而不破坏lease 机制。 例如上节中的cache 系统的例子中,一旦服务器宕机,肯定不会修改元数据,重新恢复后,只需等 待一个最大的lease 超时时间,所有节点上的缓存信息都将被清空。对于接受方宕机的情况,颁发者 不需要做更多的容错处理,只需等待lease 过期失效,就可以收回承诺,实践中也就是收回之前赋予 的权限、身份等。最后,lease 机制不依赖于存储。颁发者可以持久化颁发过的lease 信息,从而在 宕机恢复后可以使得在有效期的lease 继续有效。但这对于lease 机制只是一个优化,如之前的分析, 即使颁发者没有持久化lease 信息,也可以通过等待一个最大的lease 时间的方式使得之前所有颁发 的lease 失效,从而保证机制继续有效。 Lease 机制依赖于有效期,这就要求颁发者和接收者的时钟是同步的。一方面,如果颁发者的 时钟比接收者的时钟慢,则当接收者认为lease 已经过期的时候,颁发者依旧认为lease 有效。接收 者可以用在lease 到期前申请新的lease 的方式解决这个问题。另一方面,如果颁发者的时钟比接收 者的时钟快,则当颁发者认为lease 已经过期的时候,接收者依旧认为lease 有效,颁发者可能将lease 颁发给其他节点,造成承诺失效,影响系统的正确性。对于这种时钟不同步,实践中的通常做法是 将颁发者的有效期设置得比接收者的略大,只需大过时钟误差就可以避免对lease 的有效性的影响。 基于lease 机制确定节点状态 分布式协议依赖于对节点状态认知的全局一致性,即一旦节点Q 认为某个节点 A 异常,则节点A 也必须认为自己异常,从而节点A 停止作为primary,避免“双主”问题的出现。 解决这种问题有两种思路,第一、设计的分布式协议可以容忍“双主”错误,即不依赖于对节点状 态的全局一致性认识,或者全局一致性状态是全体协商后的结果;第二、利用lease 机制。对于第一 种思路即放弃使用中心化的设计,而改用去中心化设计,超过本节的讨论范畴。下面着重讨论利用 lease 机制确定节点状态。 由中心节点向其他节点发送lease,若某个节点持有有效的lease,则认为该节点正常可以提供服 务。用于例2.3.1 中,节点A、B、C 依然周期性的发送heart beat 报告自身状态,节点Q 收到heart beat 后发送一个lease,表示节点Q 确认了节点A、B、C 的状态,并允许节点在lease 有效期内正常工 作。节点Q 可以给primary 节点一个特殊的lease,表示节点可以作为primary 工作。一旦节点Q 希 望切换新的primary,则只需等前一个primary 的lease 过期,则就可以安全的颁发新的lease 给新的 primary 节点,而不会出现“双主”问题。 在实际系统中,若用一个中心节点发送lease 也有很大的风险,一旦该中心节点宕机或网络异常, 则所有的节点没有lease,从而造成系统高度不可用。为此,实际系统总是使用多个中心节点互为副 本,成为一个小的集群,该小集群具有高可用性,对外提供颁发lease 的功能。chubby 和zookeeper 都是基于这样的设计。 lease 的有效期时间选择 工程中,常选择的lease 时长是10 秒级别,这是一个经 过验证的经验值,实践中可以作为参考并综合选择合适的时长。

kun坤 2020-04-24 15:31:41 0 浏览量 回答数 0

问题

分布式服务接口的幂等性如何设计(比如不能重复扣款)?【Java问答学堂】52期

剑曼红尘 2020-07-08 09:15:27 3 浏览量 回答数 1

回答

Kafka 是目前主流的分布式消息引擎及流处理平台,经常用做企业的消息总线、实时数据管道,本文挑选了 Kafka 的几个核心话题,帮助大家快速掌握 Kafka,包括: Kafka 体系架构 Kafka 消息发送机制 Kafka 副本机制 Kafka 控制器 Kafka Rebalance 机制 因为涉及内容较多,本文尽量做到深入浅出,全面的介绍 Kafka 原理及核心组件,不怕你不懂 Kafka。 1. Kafka 快速入门 Kafka 是一个分布式消息引擎与流处理平台,经常用做企业的消息总线、实时数据管道,有的还把它当做存储系统来使用。早期 Kafka 的定位是一个高吞吐的分布式消息系统,目前则演变成了一个成熟的分布式消息引擎,以及流处理平台。 1.1 Kafka 体系架构 Kafka 的设计遵循生产者消费者模式,生产者发送消息到 broker 中某一个 topic 的具体分区里,消费者从一个或多个分区中拉取数据进行消费。拓扑图如下: 目前,Kafka 依靠 Zookeeper 做分布式协调服务,负责存储和管理 Kafka 集群中的元数据信息,包括集群中的 broker 信息、topic 信息、topic 的分区与副本信息等。 ** 1.2 Kafka 术语** 这里整理了 Kafka 的一些关键术语: Producer:生产者,消息产生和发送端。 Broker:Kafka 实例,多个 broker 组成一个 Kafka 集群,通常一台机器部署一个 Kafka 实例,一个实例挂了不影响其他实例。 Consumer:消费者,拉取消息进行消费。 一个 topic 可以让若干个消费者进行消费,若干个消费者组成一个 Consumer Group 即消费组,一条消息只能被消费组中一个 Consumer 消费。 Topic:主题,服务端消息的逻辑存储单元。一个 topic 通常包含若干个 Partition 分区。 Partition:topic 的分区,分布式存储在各个 broker 中, 实现发布与订阅的负载均衡。若干个分区可以被若干个 Consumer 同时消费,达到消费者高吞吐量。一个分区拥有多个副本(Replica),这是Kafka在可靠性和可用性方面的设计,后面会重点介绍。 message:消息,或称日志消息,是 Kafka 服务端实际存储的数据,每一条消息都由一个 key、一个 value 以及消息时间戳 timestamp 组成。 offset:偏移量,分区中的消息位置,由 Kafka 自身维护,Consumer 消费时也要保存一份 offset 以维护消费过的消息位置。 1.3 Kafka 作用与特点 Kafka 主要起到削峰填谷(缓冲)、系统解构以及冗余的作用,主要特点有: 高吞吐、低延时:这是 Kafka 显著的特点,Kafka 能够达到百万级的消息吞吐量,延迟可达毫秒级; 持久化存储:Kafka 的消息最终持久化保存在磁盘之上,提供了顺序读写以保证性能,并且通过 Kafka 的副本机制提高了数据可靠性。 分布式可扩展:Kafka 的数据是分布式存储在不同 broker 节点的,以 topic 组织数据并且按 partition 进行分布式存储,整体的扩展性都非常好。 高容错性:集群中任意一个 broker 节点宕机,Kafka 仍能对外提供服务。 2. Kafka 消息发送机制 Kafka 生产端发送消息的机制非常重要,这也是 Kafka 高吞吐的基础,生产端的基本流程如下图所示: 主要有以下方面的设计: 2.1 异步发送 Kafka 自从 0.8.2 版本就引入了新版本 Producer API,新版 Producer 完全是采用异步方式发送消息。生产端构建的 ProducerRecord 先是经过 keySerializer、valueSerializer 序列化后,再是经过 Partition 分区器处理,决定消息落到 topic 具体某个分区中,最后把消息发送到客户端的消息缓冲池 accumulator 中,交由一个叫作 Sender 的线程发送到 broker 端。 这里缓冲池 accumulator 的最大大小由参数 buffer.memory 控制,默认是 32M,当生产消息的速度过快导致 buffer 满了的时候,将阻塞 max.block.ms 时间,超时抛异常,所以 buffer 的大小可以根据实际的业务情况进行适当调整。 2.2 批量发送 发送到缓冲 buffer 中消息将会被分为一个一个的 batch,分批次的发送到 broker 端,批次大小由参数 batch.size 控制,默认16KB。这就意味着正常情况下消息会攒够 16KB 时才会批量发送到 broker 端,所以一般减小 batch 大小有利于降低消息延时,增加 batch 大小有利于提升吞吐量。 那么生成端消息是不是必须要达到一个 batch 大小时,才会批量发送到服务端呢?答案是否定的,Kafka 生产端提供了另一个重要参数 linger.ms,该参数控制了 batch 最大的空闲时间,超过该时间的 batch 也会被发送到 broker 端。 2.3 消息重试 此外,Kafka 生产端支持重试机制,对于某些原因导致消息发送失败的,比如网络抖动,开启重试后 Producer 会尝试再次发送消息。该功能由参数 retries 控制,参数含义代表重试次数,默认值为 0 表示不重试,建议设置大于 0 比如 3。 3. Kafka 副本机制 前面提及了 Kafka 分区副本(Replica)的概念,副本机制也称 Replication 机制是 Kafka 实现高可靠、高可用的基础。Kafka 中有 leader 和 follower 两类副本。 3.1 Kafka 副本作用 Kafka 默认只会给分区设置一个副本,由 broker 端参数 default.replication.factor 控制,默认值为 1,通常我们会修改该默认值,或者命令行创建 topic 时指定 replication-factor 参数,生产建议设置 3 副本。副本作用主要有两方面: 消息冗余存储,提高 Kafka 数据的可靠性; 提高 Kafka 服务的可用性,follower 副本能够在 leader 副本挂掉或者 broker 宕机的时候参与 leader 选举,继续对外提供读写服务。 3.2 关于读写分离 这里要说明的是 Kafka 并不支持读写分区,生产消费端所有的读写请求都是由 leader 副本处理的,follower 副本的主要工作就是从 leader 副本处异步拉取消息,进行消息数据的同步,并不对外提供读写服务。 Kafka 之所以这样设计,主要是为了保证读写一致性,因为副本同步是一个异步的过程,如果当 follower 副本还没完全和 leader 同步时,从 follower 副本读取数据可能会读不到最新的消息。 3.3 ISR 副本集合 Kafka 为了维护分区副本的同步,引入 ISR(In-Sync Replicas)副本集合的概念,ISR 是分区中正在与 leader 副本进行同步的 replica 列表,且必定包含 leader 副本。 ISR 列表是持久化在 Zookeeper 中的,任何在 ISR 列表中的副本都有资格参与 leader 选举。 ISR 列表是动态变化的,并不是所有的分区副本都在 ISR 列表中,哪些副本会被包含在 ISR 列表中呢?副本被包含在 ISR 列表中的条件是由参数 replica.lag.time.max.ms 控制的,参数含义是副本同步落后于 leader 的最大时间间隔,默认10s,意思就是说如果某一 follower 副本中的消息比 leader 延时超过10s,就会被从 ISR 中排除。Kafka 之所以这样设计,主要是为了减少消息丢失,只有与 leader 副本进行实时同步的 follower 副本才有资格参与 leader 选举,这里指相对实时。 3.4 Unclean leader 选举 既然 ISR 是动态变化的,所以 ISR 列表就有为空的时候,ISR 为空说明 leader 副本也“挂掉”了,此时 Kafka 就要重新选举出新的 leader。但 ISR 为空,怎么进行 leader 选举呢? Kafka 把不在 ISR 列表中的存活副本称为“非同步副本”,这些副本中的消息远远落后于 leader,如果选举这种副本作为 leader 的话就可能造成数据丢失。Kafka broker 端提供了一个参数 unclean.leader.election.enable,用于控制是否允许非同步副本参与 leader 选举;如果开启,则当 ISR 为空时就会从这些副本中选举新的 leader,这个过程称为 Unclean leader 选举。 前面也提及了,如果开启 Unclean leader 选举,可能会造成数据丢失,但保证了始终有一个 leader 副本对外提供服务;如果禁用 Unclean leader 选举,就会避免数据丢失,但这时分区就会不可用。这就是典型的 CAP 理论,即一个系统不可能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)中的两个。所以在这个问题上,Kafka 赋予了我们选择 C 或 A 的权利。 我们可以根据实际的业务场景选择是否开启 Unclean leader选举,这里建议关闭 Unclean leader 选举,因为通常数据的一致性要比可用性重要的多。 4. Kafka 控制器 控制器(Controller)是 Kafka 的核心组件,它的主要作用是在 Zookeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一个 broker 都能充当控制器的角色,但在运行过程中,只能有一个 broker 成为控制器。 这里先介绍下 Zookeeper,因为控制器的产生依赖于 Zookeeper 的 ZNode 模型和 Watcher 机制。Zookeeper 的数据模型是类似 Unix 操作系统的 ZNode Tree 即 ZNode 树,ZNode 是 Zookeeper 中的数据节点,是 Zookeeper 存储数据的最小单元,每个 ZNode 可以保存数据,也可以挂载子节点,根节点是 /。基本的拓扑图如下: Zookeeper 有两类 ZNode 节点,分别是持久性节点和临时节点。持久性节点是指客户端与 Zookeeper 断开会话后,该节点依旧存在,直到执行删除操作才会清除节点。临时节点的生命周期是和客户端的会话绑定在一起,客户端与 Zookeeper 断开会话后,临时节点就会被自动删除。 Watcher 机制是 Zookeeper 非常重要的特性,它可以在 ZNode 节点上绑定监听事件,比如可以监听节点数据变更、节点删除、子节点状态变更等事件,通过这个事件机制,可以基于 ZooKeeper 实现分布式锁、集群管理等功能。 4.1 控制器选举 当集群中的任意 broker 启动时,都会尝试去 Zookeeper 中创建 /controller 节点,第一个成功创建 /controller 节点的 broker 则会被指定为控制器,其他 broker 则会监听该节点的变化。当运行中的控制器突然宕机或意外终止时,其他 broker 能够快速地感知到,然后再次尝试创建 /controller 节点,创建成功的 broker 会成为新的控制器。 4.2 控制器功能 前面我们也说了,控制器主要作用是管理和协调 Kafka 集群,那么 Kafka 控制器都做了哪些事情呢,具体如下: 主题管理:创建、删除 topic,以及增加 topic 分区等操作都是由控制器执行。 分区重分配:执行 Kafka 的 reassign 脚本对 topic 分区重分配的操作,也是由控制器实现。 Preferred leader 选举:这里有一个概念叫 Preferred replica 即优先副本,表示的是分配副本中的第一个副本。Preferred leader 选举就是指 Kafka 在某些情况下出现 leader 负载不均衡时,会选择 preferred 副本作为新 leader 的一种方案。这也是控制器的职责范围。 集群成员管理:控制器能够监控新 broker 的增加,broker 的主动关闭与被动宕机,进而做其他工作。这里也是利用前面所说的 Zookeeper 的 ZNode 模型和 Watcher 机制,控制器会监听 Zookeeper 中 /brokers/ids 下临时节点的变化。 数据服务:控制器上保存了最全的集群元数据信息,其他所有 broker 会定期接收控制器发来的元数据更新请求,从而更新其内存中的缓存数据。 从上面内容我们大概知道,控制器可以说是 Kafka 的心脏,管理和协调着整个 Kafka 集群,因此控制器自身的性能和稳定性就变得至关重要。 社区在这方面做了大量工作,特别是在 0.11 版本中对控制器进行了重构,其中最大的改进把控制器内部多线程的设计改成了单线程加事件队列的方案,消除了多线程的资源消耗和线程安全问题,另外一个改进是把之前同步操作 Zookeeper 改为了异步操作,消除了 Zookeeper 端的性能瓶颈,大大提升了控制器的稳定性。 5. Kafka 消费端 Rebalance 机制 前面介绍消费者术语时,提到了消费组的概念,一个 topic 可以让若干个消费者进行消费,若干个消费者组成一个 Consumer Group 即消费组 ,一条消息只能被消费组中的一个消费者进行消费。我们用下图表示Kafka的消费模型。 5.1 Rebalance 概念 就 Kafka 消费端而言,有一个难以避免的问题就是消费者的重平衡即 Rebalance。Rebalance 是让一个消费组的所有消费者就如何消费订阅 topic 的所有分区达成共识的过程,在 Rebalance 过程中,所有 Consumer 实例都会停止消费,等待 Rebalance 的完成。因为要停止消费等待重平衡完成,因此 Rebalance 会严重影响消费端的 TPS,是应当尽量避免的。 5.2 Rebalance 发生条件 关于何时会发生 Rebalance,总结起来有三种情况: 消费组的消费者成员数量发生变化 消费主题的数量发生变化 消费主题的分区数量发生变化 其中后两种情况一般是计划内的,比如为了提高消息吞吐量增加 topic 分区数,这些情况一般是不可避免的,后面我们会重点讨论如何避免因为组内消费者成员数发生变化导致的 Rebalance。 5.3 Kafka 协调器 在介绍如何避免 Rebalance 问题之前,先来认识下 Kafka 的协调器 Coordinator,和之前 Kafka 控制器类似,Coordinator 也是 Kafka 的核心组件。 主要有两类 Kafka 协调器: 组协调器(Group Coordinator) 消费者协调器(Consumer Coordinator) Kafka 为了更好的实现消费组成员管理、位移管理,以及 Rebalance 等,broker 服务端引入了组协调器(Group Coordinator),消费端引入了消费者协调器(Consumer Coordinator)。每个 broker 启动的时候,都会创建一个 GroupCoordinator 实例,负责消费组注册、消费者成员记录、offset 等元数据操作,这里也可以看出每个 broker 都有自己的 Coordinator 组件。另外,每个 Consumer 实例化时,同时会创建一个 ConsumerCoordinator 实例,负责消费组下各个消费者和服务端组协调器之前的通信。可以用下图表示协调器原理: 客户端的消费者协调器 Consumer Coordinator 和服务端的组协调器 Group Coordinator 会通过心跳不断保持通信。 5.4 如何避免消费组 Rebalance 接下来我们讨论下如何避免组内消费者成员发生变化导致的 Rebalance。组内成员发生变化无非就两种情况,一种是有新的消费者加入,通常是我们为了提高消费速度增加了消费者数量,比如增加了消费线程或者多部署了一份消费程序,这种情况可以认为是正常的;另一种是有消费者退出,这种情况多是和我们消费端代码有关,是我们要重点避免的。 正常情况下,每个消费者都会定期向组协调器 Group Coordinator 发送心跳,表明自己还在存活,如果消费者不能及时的发送心跳,组协调器会认为该消费者已经“死”了,就会导致消费者离组引发 Rebalance 问题。这里涉及两个消费端参数:session.timeout.ms 和 heartbeat.interval.ms,含义分别是组协调器认为消费组存活的期限,和消费者发送心跳的时间间隔,其中 heartbeat.interval.ms 默认值是3s,session.timeout.ms 在 0.10.1 版本之前默认 30s,之后默认 10s。另外,0.10.1 版本还有两个值得注意的地方: 从该版本开始,Kafka 维护了单独的心跳线程,之前版本中 Kafka 是使用业务主线程发送的心跳。 增加了一个重要的参数 max.poll.interval.ms,表示 Consumer 两次调用 poll 方法拉取数据的最大时间间隔,默认值 5min,对于那些忙于业务逻辑处理导致超过 max.poll.interval.ms 时间的消费者将会离开消费组,此时将发生一次 Rebalance。 此外,如果 Consumer 端频繁 FullGC 也可能会导致消费端长时间停顿,从而引发 Rebalance。因此,我们总结如何避免消费组 Rebalance 问题,主要从以下几方面入手: 合理配置 session.timeout.ms 和 heartbeat.interval.ms,建议 0.10.1 之前适当调大 session 超时时间尽量规避 Rebalance。 根据实际业务调整 max.poll.interval.ms,通常建议调大避免 Rebalance,但注意 0.10.1 版本之前没有该参数。 监控消费端的 GC 情况,避免由于频繁 FullGC 导致线程长时间停顿引发 Rebalance。 合理调整以上参数,可以减少生产环境中 Rebalance 发生的几率,提升 Consumer 端的 TPS 和稳定性。 6.总结 本文总结了 Kafka 体系架构、Kafka 消息发送机制、副本机制,Kafka 控制器、消费端 Rebalance 机制等各方面核心原理,通过本文的介绍,相信你已经对 Kafka 的内核知识有了一定的掌握,更多的 Kafka 原理实践后面有时间再介绍。

剑曼红尘 2020-04-16 18:15:45 0 浏览量 回答数 0

问题

搜索引擎抓取系统概述(含搜索引擎工作原理等)

kideny 2019-12-01 21:30:39 5387 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站