PTP是英语“传输协议(picture transfer protocol)”的缩写。PTP是最早由柯达公司与微软协商制定的一种标准，符合这种标准的图像设备在接入Windows XP系统之后可以更好地被系统和应用程序所共享，尤其在网络传输方面，系统可以直接访问这些设备用于建立网络相册时的上传、网上聊天时的传送等。
p2p，即对等网络，又称工作组，对等计算（Peer to Peer，简称p2p），网上各台计算机有相同的功能，无主从之分，一台计算机都是既可作为服务器，设定共享资源供网络中其他计算机所使用，又可以作为工作站，没有专用的服务器，也没有专用的工作站，对等网络是小型局域网常用的组网方式。
p2p的另一种意思：
P2P是英文peer-to-peer的缩写，意即个人对个人。又称点对点网络借款，是一种将小额资金聚集起来借贷给有资金需求人群的一种民间小额借贷模式。
p2p与p吐p意思相同，只是一个官话，一个土话而已。PTP一般称为P2P。P2P金融又叫P2P信贷，是互联网金融（ITFIN）的一种。意思是：点对点。P2P是英文persontoperson的缩写，意即个人对个人。P2P网络借款，又称点对点网络借款，是一种将小额资金聚集起来借贷给有资金需求人群的一种民间小额借贷模式。P2P还有一种更广泛的概念，泛指互联网金融，借助互联网、移动互联网技术的网络信贷平台及相关理财行为、金融服务。
本条内容来源于：中国法律出版社《中华人民共和国金融法典:应用版》设备安装GPS时钟芯片，同步接收GPS时钟信号（定时接收tick）。设备将GPS作为一级时钟源。系统其他时间参考该时钟源校准详细请参考如下：
GPS时钟系统
GPS时钟系统是针对自动化系统中的计算机、控制装置等进行校时的高科技产品，GPS数字产品它从GPS卫星上获取标准的时间信号，将这些信息通过各种接口类型来传输给自动化系统中需要时间信息的设备（计算机、保护装置、故障录波器、事件顺序记录装置、安全自动装置、远动RTU），这样就可以达到整个系统的时间同步。 前言 随着计算机和网络通信技术的飞速发展，火电厂热工自动化系统数字化、网络化的时代已经到来。这一方面为各控制和信息系统之间的数据交换、分析和应用提供了更好的平台、另一方面对各种实时和历史数据时间标签的准确性也提出了更高的要求。 使用价格并不昂贵的GPS时钟来统一全厂各种系统的时钟
峻峰伟业公司时钟系统
，已是目前火电厂设计中采用的标准做法。电厂内的机组分散控制系统(DCS)、辅助系统可编程控制器(PLC)、厂级监控信息系统(SIS)、电厂管理信息系统(MIS)等的主时钟通过合适的GPS时钟信号接口，得到标准的TOD(年月日时分秒)时间，然后按各自的时钟同步机制，将系统内的从时钟偏差限定在足够小的范围内，从而达到全厂的时钟同步。 一、GPS时钟及输出 11 GPS时钟 全球定位系统(Global Positioning System，GPS)由一组美国国防部在1978年开始陆续发射的卫星所组成，共有24颗卫星运行在6个地心轨道平面内，根据时间和地点，地球上可见的卫星数量一直在4颗至11颗之间变化。 GPS时钟是一种接受GPS卫星发射的低功率无线电信号，通过计算得出GPS时间的接受装置。为获得准确的GPS时间，GPS时钟必须先接受到至少4颗GPS卫星的信号，计算出自己所在的三维位置。在已经得出具体位置后，GPS时钟只要接受到1颗GPS卫星信号就能保证时钟的走时准确性。 作为火电厂的标准时钟，我们对GPS时钟的基本要求是：至少能同时跟踪8颗卫星，有尽可能短的冷、热启动时间，配有后备电池，有高精度、可灵活配置的时钟输出信号。 12 GPS时钟信号输出 目前，电厂用到的GPS时钟输出信号主要有以下三种类型： 121 1PPS/1PPM输出 此格式时间信号每秒或每分时输出一个脉冲。显然，时钟脉冲输出不含具体时间信息。 122 IRIG-B输出 IRIG(美国the Inter-Range Instrumentation Group)共有A、B、D、E、G、H几种编码标准(IRIG Standard 200-98)。其中在时钟同步应用中使用最多的是IRIG-B编码，有bc电平偏移(DC码)、1kHz正弦载波调幅(AC码)等格式。IRIG-B信号每秒输出一帧(1fps)，每帧长为一秒。一帧共有100个码元(100pps)，每个码元宽10ms，由不同正脉冲宽度的码元来代表二进制0、1和位置标志位(P)，见图122-1。 为便于理解，图122-2给出了某个IRIG-B时间帧的输出例子。其中的秒、分、时、天(自当年1月1日起天数)用BCD码表示，控制功能码(Control Functions，CF)和标准二进制当天秒数码(Straight Binary Seconds Time of Day，SBS)则以一串二进制“0”填充(CF和SBS可选用，本例未采用)。 123 RS-232/RS-422/RS-485输出 此时钟输出通过EIA标准串行接口发送一串以ASCII码表示的日期和时间报文，每秒输出一次。时间报文中可插入奇偶校验、时钟状态、诊断信息等。此输出目前无标准格式，下图为一个用17个字节发送标准时间的实例： 13 电力自动化系统GPS时钟的应用 电力自动化系统内有众多需与GPS时钟同步的系统或装置，如DCS、PLC、NCS、SIS、MIS、RTU、故障录波器、微机保护装置等。在确定GPS时钟时应注意以下几点： (1)这些系统分属热控、电气、系统专业，如决定由DCS厂商提供的GPS时钟实现时间同步(目前通常做法)，则在DCS合同谈判前，就应进行专业间的配合，确定时钟信号接口的要求。(GPS时钟一般可配置不同数量、型式的输出模块，如事先无法确定有关要求，则相应合同条款应留有可调整的余地。) (2)各系统是否共用一套GPS时钟装置，应根据系统时钟接口配合的难易程度、系统所在地理位置等综合考虑。各专业如对GPS时钟信号接口型式或精度要求相差较大时，可各自配置GPS时钟，这样一可减少专业间的相互牵制，二可使各系统时钟同步方案更易实现。另外，当系统之间相距较远(例如化水处理车间、脱硫车间远离集控楼)时，为减少时钟信号长距离传送时所受的电磁干扰，也可就地单设GPS时钟。分设GPS时钟也有利于减小时钟故障所造成的影响。 (3)IRIG-B码可靠性高、接口规范，如时钟同步接口可选时，可优先采用。但要注意的是，IRIG-B只是B类编码的总称，具体按编码是否调制、有无CF和SBS等又分成多种(如IRIG-B000等)，故时钟接收侧应配置相应的解码卡，否则无法达到准确的时钟同步。 (4)1PPS/1PPM脉冲并不传送TOD信息，但其同步精度较高，故常用于SOE模件的时钟同步。RS-232时间输出虽然使用得较多，但因无标准格式，设计中应特别注意确认时钟信号授、受双方时钟报文格式能否达成一致。 (5)火电厂内的控制和信息系统虽已互连，但因各系统的时钟同步协议可能不尽相同，故仍需分别接入GPS时钟信号。即使是通过网桥相连的机组DCS和公用DCS，如果时钟同步信号在网络中有较大的时延，也应考虑分别各自与GPS时钟同步。 二、西门子TELEPERMXP时钟同步方式 这里以西门子公司的TXP系统为例，看一下DCS内部及时钟是如何同步的。 TXP的电厂总线是以CSMA/CD为基础的以太网，在总线上有二个主时钟：实时发送器(RTT)和一块AS620和CP1430通讯/时钟卡。正常情况下，RTT作为TXP系统的主时钟，当其故约40s后，作为备用时钟的CP1430将自动予以替代(实际上在ES680上可组态2块)CP1430作为后备主时钟)。见图2-1。 RTT可自由运行(free running)，也可与外部GPS时钟通过TTY接口(20mA电流回路)同步。与GPS时钟的同步有串行报文(长32字节、9600波特、1个启动位、8个数据位、2个停止位)和秒/分脉冲二种方式。 RTT在网络层生成并发送主时钟对时报文，每隔10s向电厂总线发送一次。RTT发送时间报文最多等待1ms。如在1ms之内无法将报文发到总线上，则取消本次时间报文的发送：如报文发送过程被中断，则立即生成一个当前时间的报文。时钟报文具有一个多播地址和特殊帧头，日期为从19840101至当天的天数，时间为从当天00：00：00，000h至当前的ms值，分辨率为10ms。 OM650从电厂总线上获取时间报文。在OM650内，使用Unix功能将时间传送给终端总线上的SU、OT等。通常由一个PU作为时间服务器，其他OM650设备登录为是境客户。 AS620的AP在启动后，通过调用“同步”功能块，自动与CP1430实现时钟同步。然后CP1430每隔6s与AP对时。 TXP时钟的精度如下： 从上述TXP时钟同步方式及时钟精度可以看出，TXP系统内各进钟采用的是主从分级同步方式，即下级时钟与上级时钟同步，越是上一级的时钟其精度越高。 三、时钟及时钟同步误差 31 时钟误差 众所周知，计算机的时钟一般都采用石英晶体振荡器。晶振体连续产生一定频率的时钟脉冲，计数器则对这些脉冲进行累计得到时间值。由于时钟振荡器的脉冲受环境温度、匀载电容、激励电平以及晶体老化等多种不稳定性因素的影响，故时钟本身不可避免地存在着误差。例如，某精度为±20ppm的时钟，其每小时的误差为：(1×60×60×1000ms)×(20/106)＝72ms，一天的累计误差可达173s；若其工作的环境温度从额定25℃变为45℃，则还会增加±25ppm的额外误差。可见，DCS中的时钟若不经定期同步校准，其自由运行一段时间后的误差可达到系统应用所无法忍受的程度。 随着晶振制造技术的发展，目前在要求高精度时钟的应用中，已有各种高稳定性晶振体可供选用，如TCXO(温度补偿晶振)、VCXO(压控晶振)、OCXO(恒温晶振)等。 32 时钟同步误差 如果对类似于TXP的时钟同步方式进行分析，不难发现时钟在自上而下的同步过程中产生的DCS的绝对对时误差可由以下三部分组成： 321 GPS时钟与卫星发射的UTC(世界协调时)的误差 这部分的误差由GPS时钟的精度所决定。对1PPS输出，以脉冲前沿为准时沿，精度一般在几十ns至1μs之间；对IRIG-B码和RS-232串行输出，如以中科院国家授时中心的地钟产品为例，其同步精度以参考码元前沿或起始相对于1PPS前沿的偏差计，分别达03μs和02ms。 322 DCS主时钟与GPS时钟的同步误差 DCS网络上的主时钟与GPS时钟通过“硬接线”方式进行同步。一般通过DCS某站点内的时钟同步卡接受GPS时钟输出的标准时间编码、硬件。例如，如在接受端对RS-232输出的ASCII码字节的发送延迟进行补偿，或对IRIG-B编码采用码元载波周期计数或高频销相的解码卡，则主时钟与GPS时钟的同步精度可达很高的精度。 323 DCS各站点主从时钟的同步误差 DCS主时钟与各站点从时钟通过网络进行同步，其间存在着时钟报文的发送时延、传播时延、处理时延。表现在：(1)在主时钟端生成和发送时间报文时，内核协议处理、 *** 作系统对同步请求的调用开销、将时间报文送至网络通信接口的时间等；(2)在时间报文上网之前，还必须等待网络空闲(对以太网)，遇冲突还要重发；(3)时间报文上网后，需一定时间通过DCS网络媒介从主时钟端传送到子时钟端(电磁波在光纤中的传播速度为2/3光速，对DCS局域网而言，传播时延为几百ns，可忽略不计)；(4)在从时钟端的网络通信接口确认是时间报文后，接受报文、记录报文到达时间、发出中断请求、计算并校正从时钟等也需要时间。这些时延或多或少地造成了DCS主从时钟之间、从从时钟之间的时间同步误差。 当然，不同网络类型的DCS、不同的时钟通信协议和同步算法，可使网络对时的同步精度各不相同，上述分析只是基于一般原理上探讨。事实上，随着人们对网络时钟同步技术的不懈研究，多种复杂但又高效、高精确的时钟同步协议和算法相继出现并得到实际应用。例如，互联网上广为采用的网络时间协议(Network Time Protocol，NTP)在DCS局域网上已能提供±1ms的对时精度(如GE的ICS分散控制系统)，而基于IEEE1588的标准精确时间协议(Standard Precision Time Protocol，PTP)能使实时控制以太网上的主、从时钟进行亚微秒级同步。 四、时钟精度与SOE设计 虽然DCS的普通开关量扫描速率已达1ms，但为满足SOE分辨率≤1ms的要求，很长一段时间内，人们都一直都遵循这样的设计方法，即将所有SOE点置于一个控制器之下，将事件触发开关量信号以硬接线接入SOE模件，其原因就在于不同控制器其时钟存在着一定的误差。关于这一点，西门子在描述其TXP系统的FUN B模件分散配置的工程实际情况来看，由于时钟不能同步而无法做到1ms SOE分辩率，更有甚至因时钟相差近百ms，造成SOE事件记录顺序的颠倒。 那么，如何既能满足工程对于SOE分散设计的要求(如设置了公用DCS后，机组SOE与公用系SOE应分开，或希望进入控制器的MFT、ETS的跳闸信号无需经输出再返至SOE模件就能用于SOE等)，又不过分降低SOE分辨率呢通过对DCS产品的分析不难发现，通常采用的办法就是将控制器或SOE模件的时钟直接与外部GPS时钟信号同步。例如，在ABB Symphony中，SOEServerNode(一般设在公用DCS网上)的守时主模件(INTKM01)接受IRIG-B时间编码，并将其产生的RS-485时钟同步信号链接到各控制器(HCU)的SOE时间同步模件(LPD250A)，其板载硬件计时器时钟可外接1PPM同步脉冲，每分钟自动清零一次；再如，MAX1000＋PLUS的分散处理单元(DPU 4E)可与IRIG-B同步，使DPU的DI点可同时用做SOE，由于采用了1PPM或RS-485、IRIG-B硬接线时钟“外同步”，避开了DCS时钟经网络同步目前精度还较差的问题，使各受控时钟之间的偏差保持在较小的范围内，故SOE点分散设计是可行的。 由此可见，在工程设计中应结合采用的DCS特点来确定SOE的设计方案。不可将1ms的开关量扫描速率或1ms的控制器(或SOE模件)时钟相对误差等同于1ms的SOE分辨率，从而简单地将SOE点分散到系统各处。同时也应看到，SOE点“分散”同“集中”相比，虽然分辨率有所降低，但只要时钟相对误差很小(如与1ms关一个数量级)，还是完全能满足电厂事故分析实际需要的。 五、结束语 51 目前火电厂各控制系统已不再是各自独立的信息孤岛，大量的实时数据需在不同地方打上时戳，然后送至SIS、MIS，用于各种应用中。因此，在设计中应仔细考虑各种系统的时钟同步方案和需达到的时钟同步精度。 52 在DCS设计中不仅要注意了解系统主、从时钟的绝对对时精度，更应重视时钟之间的相对误差。因为如要将SOE点分散设计的同时又不过分降低事件分辨率，其关键就在于各时钟的偏差应尽可能小。 53 完全有理由相信，随着网络时钟同步技术的不断发展，通过网络对系统各时钟进行高精度的同步将变得十分平常。今后电厂各系统的对时准确性将大大提高，像SOE点分散设计这种基于高精确度时钟的应用将会不断出现。
消息队列（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中有几条相关数据就用几个内存队列，消费者开启多个线程，每个线程处理一个内存队列。
1
/12
PTP 授时同步原理时间同步含义是指按照接收到的标准时间通过调整频率和相位来调整被授时设备内部的时钟。时钟的相位用数值表示出来其实就是我们所说的时刻。时间同步有授时和守时两大主要功能，通俗的说，授时就是“对表”，通过不定期地对表动作，将本地时间与标准时间进行相位同步；守时即是在对表的间隙里，本地时间与标准时间之间不能出现太大的偏差。
2
/12
PTP 授时原理为在同一个局域网中, 主时钟周期性地发送时间同步报文, 从时钟接收该同步报文, 同时随机性的给主时钟发送延迟请求报文, 然后通过同步算法调整自身时钟的偏差。
3
/12
从主时钟所在的系统中由 PTP 协议进行组包同步数据流, 然后经过传输层, 网络层, 数据链路层。网络多播负责将数据流发送给交换机, 交换机将转发该数据报文到同一个多播组, 同一个多播组的从时钟将接收到该同步报文, 从链路层传送送到 PTP 协议层进行解包处理。同时从时钟发送的延迟请求报文过程将由从时钟协议层组包, 然后通过网络链路传回到主时钟，来回传送的原理类似。
4
/12
经往返反复计算,得到比较理想的偏差数值后,通过计算从时钟和主时钟之间的偏差比率计算得到从时钟和主时钟之间的一个相位差和频率差, 将所获偏差补尝给从时钟设备, 从而达到主从时钟设备的一致。
5
/12
PTP 授时钟硬件的设计，ptp 授时精度从理论上来说主要受两方面的影响，一方面是打时间戳的位置另外是软件同步的算法。打时间戳目前可以在物理层、数据链路层和应用层上进行，同时精度会依次降低。
SYN2401型PTP主时钟
6
/12
本文讨论的是基于以太网的传输媒介, 在物理层打时间戳的方式, 该方式实现可以获得较高的同步精度。该方式下的 PTP 数据报文流改变标准的以太网物理层芯片, 使用精度更高的具有 IEEE1588 PTP 功能的太网物理层芯片。一般来讲硬件单元包括 UDP 用户数据包协议传输层、网络连接协议 IP 传输层、MAC 数据链路层、 传输层和 PHY 物理层。
7
/12
PTP 授时钟软件的设计
软件采用了分层模型, 模块化设计的思想,协议栈与平台相关的部分分开, 这样可以很方便的移植到任何平台下, 在系统调试和功能的删除添加 *** 作非常的方便。
系统初始化单元主要用于对定时器、系统日志模块、配置模块等进行初始化。其中初始化包括但不限于资源分配、创建定时器、创建消息队列以及初始化系统日志等。其中定时器用于完成 PTP 协议交互时的逻辑 *** 作,保证 PTP 协议的正常运转。消息队列负责为用户提供一个外部的 API 接口,方便获取 PTP 协议运转过程中发生的异常信息。
SYN2401型PTP主时钟
8
/12
在这里需要说明一下人机交互单元，这一单元主要由配置模块和测试模块组成， 前者用于提供参数配置接口, 接收用户输入的配置请求,根据配置请求对PTP 协议的实现的系统参数进行配置；后者负责提供用于测试的应用程序编程接口, 并对该测试请求要求的 PTP 协议的功能进行测试。用户输入的测试请求,就是通过测试模块完成的。
9
/12
协议引擎单元包括定时器、PTP 报文处理模块、网络通讯模块、同步算法模块和时钟处理模块。定时器顾名思义为 PTP 协议的运行提供定时功能,一般有同步间隔定时器、接收超时定时器和延迟请求间隔定时器等三种类型的定时器。ptp 报文处理模块一般处理同步报文、跟随报文、延迟请求报文和延迟响应报文， 根据 ptp 协议组织并封装各种 ptp 报文, 通过网络通讯模块发送 ptp 报文, 或从网络通讯模块接收 ptp 报文,并获取各 PTP 报文的发送时间戳和接收时间戳。
SYN2401型PTP主时钟
10
/12
ptp 授时时钟产品为适应更高精度的时间同步，推出纳秒级的时间同步技术 PTP。相关的 ptp 授时系列产品包括 PTP 主时钟和从时钟，除此之外还有 PTP 授时板卡，其中板卡分为串口授时和总线控制两种，采用高速集成芯片实现硬件时间戳打标功能，大幅度提高了对时和授时精度。
11
/12
ptp 授时钟主要分为主时钟和从时钟，一般 1588 时钟都是主从成套使用， 因此可以选择 SYN2401型PTP主时钟和SYN2403型PTP从时钟，如果有 1588 时钟集成能力，可以选择各种 1588 时钟板卡，有核心板卡和整块板卡，1588 核心板卡体积小巧，可以做主时钟也可以做从时钟，性价比极高，时间信息、非连续调控设备时钟。
12
/12
时间同步有2个主要功能：授时和守时，用通俗的语音描述，授时就是“对表”通过不定期地对表动作，将本地时刻与标准时刻相位同步；守时保证在对表的间隙里， 本地时刻与标准时刻偏差不要太大。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）