Kafka是一款开源的、轻量级的、分布式、可分区和具有复制备份的（Replicated）、基于ZooKeeper协调管理的分布式流平台的功能强大的消息系统。作为一个流式处理平台，必须具备以下3个关键特性：
1) 能够允许发布和订阅流数据。
2) 存储流数据时提供相应的容错机制。
3) 当流数据到达时能够被及时处理。
消息流系统kafka的基本结构包括生产者和消费者，以及kafka集群。
生产者负责生产消息，将消息写入Kafka集群；消费者从Kafka集群中拉取消息。
消息是Kafka通信的基本单位 ，由一个 固定长度的消息头 和一个 可变长度的消息体 构成。
Kafka将 一组消息 抽象归纳为一个主题（Topic），也就是说，一个主题是对消息的一个分类。 生产者将消息指定主题发送到kafka集群，消费者订阅主题或主题的某些分区进行消费。
Kafka将一组消息归纳为一个主题，而 每个主题又被分成一个或多个分区(Partition) 。每个分区由一系列有序、不可变的消息组成，是一个有序队列。 每个分区在物理上对应为一个文件夹 ，分区的命名规则为主题名称后接“—”连接符，之后再接分区编号，分区编号从0开始，编号最大值为分区的总数减1。
分区使得Kafka在并发处理上变得更加容易，理论上来说，分区数越多吞吐量越高，但这要根据集群实际环境及业务场景而定。同时，分区也是Kafka保证消息被顺序消费以及对消息进行负载均衡的基础。
疑问和答案 ：分区如何保证消息被顺序消费？每个分区内的消息是有序的，但不同分区间如何保证？猜测是分区从存储空间上比较大，分区个数少。顺序消费的主要因素在分区内的消息，分区间的可以忽略。高吞吐率顺序写磁盘估计也是这个原因。
Kafka只能保证一个分区之内消息的有序性，并不能保证跨分区消息的有序性。 每条消息被追加到相应的分区中，是顺序写磁盘，因此效率非常高，这是Kafka高吞吐率的一个重要保证 。同时与传统消息系统不同的是，Kafka并不会立即删除已被消费的消息，由于磁盘的限制消息也不会一直被存储，因此 Kafka提供两种删除老数据的策略 ，一是基于消息已存储的时间长度，二是基于分区的大小。这两种策略都能通过配置文件进行配置。
每个分区又有一至多个副本（Replica），分区的副本分布在集群的不同代理上，以提高可用性。
从存储角度上分析，分区的每个副本在逻辑上抽象为一个日志（Log）对象，即分区的副本与日志对象是一一对应的。每个主题对应的 分区数 可以在Kafka启动时所加载的配置文件中配置，也可以在创建主题时指定。当然，客户端还可以在主题创建后修改主题的分区数。
为什么副本要分Leader和Follower？ 如果没有Leader副本，就需要所有的副本都同时负责读/写请求处理，同时还得保证这些副本之间数据的一致性，假设有n个副本则需要有n×n条通路来同步数据，这样数据的一致性和有序性就很难保证。
为解决这个问题，Kafka选择分区的一个副本为Leader，该分区其他副本为Follower，只有 Leader副本 才负责处理客户端 读/写请求 ，Follower副本从Leader副本同步数据。
引入Leader副本后客户端只需与Leader副本进行交互，这样数据一致性及顺序性就有了保证。Follower副本从Leader副本同步消息，对于n个副本只需n-1条通路即可，这样就使得系统更加简单而高效。
副本Follower与Leader的角色并不是固定不变的，如果Leader失效，通过相应的选举算法将从其他Follower副本中选出新的Leader副本。
疑问 ：leader副本和follower副本是如何选出来的？通过zookeeper选举的嘛？
Kafka在ZooKeeper中动态维护了一个 ISR（In-sync Replica） ，即保存同步的副本列表，该列表中保存的是与Leader副本保持消息同步的所有副本对应的代理节点id。 如果一个Follower副本宕机或是落后太多 ，则该Follower副本节点将 从ISR列表中移除 。 本书用宕机 来特指某个代理失效的情景，包括但不限于代理被关闭，如代理被人为关闭或是发生物理故障、心跳检测过期、网络延迟、进程崩溃等。
任何发布到分区的消息会被直接追加到日志文件的尾部（分区目录下以“.log”为文件名后缀的数据文件），而每条 消息 在日志文件中的位置都会对应一个按序递增的 偏移量 。偏移量是一个分区下严格有序的 逻辑值 ，它并不表示消息在磁盘上的物理位置。由于Kafka几乎不允许对消息进行随机读写，因此Kafka并没有提供额外索引机制到存储偏移量。
消费者可以通过控制消息偏移量来对消息进行消费 ，如消费者可以指定消费的起始偏移量。 为了保证消息被顺序消费，消费者已消费的消息对应的偏移量也需要保存 。需要说明的是，消费者对消息偏移量的操作并不会影响消息本身的偏移量。旧版消费者将消费偏移量保存到ZooKeeper当中， 而新版消费者是将消费偏移量保存到Kafka内部一个主题当中。 当然，消费者也可以自己在外部系统保存消费偏移量，而无需保存到Kafka中。
推测 ：一个主题有多个分区，一个分区有多个副本。一个主题(一类消息)有多个分区(消息被分段)，一个分区(每段消息)有多个副本(每段消息的副本数)。消息一旦发给kafka，就会分配一个偏移量，在多个副本中的偏移量是一样的。这样的话，消费者通过偏移量消费时对于多个副本就没有差异性。
Kafka集群由一个或多个Kafka实例构成，每一个Kafka实例称为代理（Broker），通常也称代理为Kafka服务器（KafkaServer）。在生产环境中Kafka集群一般包括一台或多台服务器，我们可以在一台服务器上配置一个或多个代理。 每一个代理都有唯一的标识id，这个id是一个非负整数 。在一个Kafka集群中，每增加一个代理就需要为这个代理配置一个与该集群中其他代理不同的id, id值可以选择任意非负整数即可，只要保证它在整个Kafka集群中唯一，这个id就是代理的名字，也就是在启动代理时配置的broker.id对应的值。
生产者（Producer）负责将消息发送给代理，也就是向Kafka代理发送消息的客户端。
消费者（Comsumer）以拉取（pull）方式拉取数据，它是消费的客户端。在Kafka中 每一个消费者都属于一个特定消费组 （ConsumerGroup），可以为每个消费者指定一个消费组，以groupId代表消费组名称，通过group.id配置设置。 如果不指定消费组 ，则该消费者属于默认消费组test-consumer-group。
每个消费者有一个全局唯一的id ，通过配置项client.id指定， 如果客户端没有指定消费者的id， Kafka会自动为该消费者生成一个全局唯一的id，格式为${groupId}-${hostName}-${timestamp}-${UUID前8位字符}。 同一个主题的一条消息只能被同一个消费组下某一个消费者消费 ，但不同消费组的消费者可同时消费该消息。 消费组是Kafka用来实现对一个主题消息进行广播和单播的手段 ，实现消息广播只需指定各消费者均属于不同的消费组，消息单播则只需让各消费者属于同一个消费组。
推论： kafka消息是按照消息类型(主题)，在一个消费者组中只能消费一次。也就是一个消费者组只消费一类型的消息。如果某个服务要消费一类消息，必须将自己置为不同的消费者组。
Kafka利用ZooKeeper保存相应元数据信息， Kafka元数据信息包括如代理节点信息、Kafka集群信息、旧版消费者信息及其消费偏移量信息、主题信息、分区状态信息、分区副本分配方案信息、动态配置信息等。 Kafka在启动或运行过程当中会在ZooKeeper上创建相应节点 来保存元数据信息， Kafka通过监听机制在这些节点注册相应监听器来监听节点元数据的变化 ，从而由ZooKeeper负责管理维护Kafka集群，同时通过ZooKeeper我们能够很方便地对Kafka集群进行水平扩展及数据迁移。
以办公场景为例，比如员工入职通知，放假通知等业务通知，由oa系统处理具体的业务逻辑，再调用消息推送api，触达到目标用户。
效果示例
以协同办公为例，员工收到系统推送的工作通知，有新任务需要处理。
员工点击工作通知，可以查看具体详情，每条通知有不同的发送者昵称和头像。这种通知类型是一种新的会话类型，全部聚合在同一个会话。
OpenIM简介
OpenIM：从服务端到客户端SDK开源即时通讯整体解决方案。开发者可以轻松替代第三方IM云服务，打造具备聊天、社交功能的app，也可以在自身应用中集成SDK，以提供即时通讯能力。开源IM的价值在于“一切皆可控”“我的信息我做主”，无论是技术，还是信息安全。
整体超过7.2K star，OpenIM作为开源IM的领跑者，持续添加新功能，包括消息推送api，群聊已读。服务端和sdk都是Apache-2.0 License授权协议，可以免费使用。带有UI的产品需要商业授权，有兴趣的客户可以联系我们深度交流。
5X8小时vip专属服务，包括：
（1）一对一技术咨询，微信 电话等各种方式；
（2）sdk使用辅导咨询；
（3）服务端架构及部署答疑；
（4）IM新需求优先排期；
（5）bug优先修复；
（6）系统维护和故障响应；
web端体验：https://open-im-online.rentsoft.cn/
安卓端体验：https://www.pgyer.com/OpenIM
iOS端体验：
https://testflight.apple.com/join/o956rTGx
单机性能及容量总结
服务器资源：8核16G内存， 6个机械磁盘，每个磁盘100G， mongo 分片，10MB带宽。
容量：用户同时在线10万以上，消息条数10亿。
性能评估：同时在线用户10万，每秒钟发送消息900条，（从发送者发出消息到接收到消息）消息延时1秒
可靠性总结
每条消息都能被对方精确收到，并成功落地app本地db。对于失败的3条消息，接收方确实没有收到，确保系统消息一致性。
系统具备优秀的平行扩展能力，除存储模块外，其他模块都无状态，支持亿级用户，千亿消息量。
github地址：https://github.com/OpenIMSDK/Open-IM-Server
开发者中心：https://doc.rentsoft.cn/#/
简要描述
管理员通过后台接口发送通知类型消息
请求URL
http://x.x.x.x:10000/manager/send_msg
请求方式
POST
请求示例
{
"operationID": "Oa notification operationID111",
"sendID": "openIM123456",
"recvID": "18712345678",
"senderPlatformID": 2,
"senderFaceURL": "http://www.head.com",
"senderNickname": "系统通知2",
"content": {
"notificationName": "公文管理",
"notificationFaceURL": "http://www.head1.com",
"notificationType": 1,
"text": "大家好，今天是...",
"externalUrl":"",
"mixType": 0,
"pictureElem": {
"sourcePath": "",
"sourcePicture": {
"uuid": "",
"type": "",
"size": 0,
"width": 0,
"height": 0,
"url": ""
},
"bigPicture": {
"uuid": "",
"type": "",
"size": 0,
"width": 0,
"height": 0,
"url": ""
},
"snapshotPicture": {
"uuid": "",
"type": "",
"size": 0,
"width": 0,
"height": 0,
"url": ""
}
},
"soundElem": {
"uuid": "",
"soundPath": "",
"sourceUrl": "",
"dataSize": 0,
"duration": 0
},
"videoElem": {
"videoPath": "",
"videoUUID": "",
"videoUrl": "",
"videoType": "",
"videoSize": 0,
"duration": 0,
"snapshotPath": "",
"snapshotUUID": "",
"snapshotSize": 0,
"snapshotUrl": "",
"snapshotWidth": 0,
"snapshotHeight": 0
},
"fileElem": {
"filePath": "",
"uuid": "",
"sourceUrl": "",
"fileName": "",
"fileSize": 0
},
"ex": ""
},
"contentType": 1400,
"sessionType": 4,
"isOnlineOnly": false,
"offlinePushInfo": {
"title": "admin revoke your message",
"desc": "",
"ex": "",
"iOSPushSound": "default",
"iOSBadgeCount": false
}
}Copy to clipboardErrorCopied
请求参数
参数名类型必选说明
operationIDstring是操作ID，保持唯一，建议用当前时间微秒+随机数，用于后台链路追踪问题使用
sendIDstring是管理员ID，为后台config文件中配置的管理员ID中一个，默认openIM123456
recvIDstring是接收者userID
senderPlatformIDint否发送者平台号，模拟用户发送时填写， 1->IOS,2->Android,3->Windows,4->OSX,5->Web,5->MiniWeb,7->Linux
senderFaceURLstring否发送者头像，用于客户端通知会话产生
senderNicknamestring否发送者昵称，用于客户端通知会话产生
contentobject是消息的具体内容，内部是json 对象
notificationNamestring是通知标题
notificationFaceURLstring是通知头像
notificationTypeint是通知类型，如：1代表入职通知，2代表离职通知
textstring是通知正文e
externalUrlstring否通知点击后需要跳转到的地址链接(不填则无需跳转)
mixTypeint是通知混合类型 0：纯文字通知 1：文字+图片通知 2：文字+视频通知 3：文字+文件通知
pictureElemobject否图片元素对象
sourcePictureobject否原图
bigPictureobject否大图
snapshotPictureobject否缩略图
soundElemobject否声音元素对象
videoElemobject否视频元素对象
fileElemobject否文件元素对象
uuidstring否对象唯一ID用于缓存使用
type/videoType/string否图片类型/视频类型
size/dataSize/videoSize/snapshotSize/fileSizeint否多媒体文件大小，单位字节
width/snapshotWidthint否图片/视频缩略图宽度
height/snapshotHeightint否图片/视频缩略图高度
url/sourceUrl/videoUrlstring否图片/文件/视频的URL
sourcePath/soundPath/videoPath/filePathstring否文件路径，可不填写
fileNamestring否文件名字
exstring否扩展字段
contentTypeint是消息类型固定为1400
sessionTypeint是通知会话类型固定为4
isOnlineOnlybool否改字段设置为true时候，发送的消息服务器不会存储，接收者在线才会收到，不在线该消息丢失。
offlinePushInfoobject否离线推送的具体内容，如果不填写，使用服务器默认推送标题
titlestring否推送的标题
descstring否推送的具体描述
exstring否扩展字段
iOSPushSoundstring否IOS的推送声音
iOSBadgeCountbool否IOS推送消息是否计入桌面图标未读数
返回示例
{
"errCode": 0,
"errMsg": "",
"data": {
"serverMsgID": "",
"clientMsgID": "",
"sendTime": 1645697804432
}
}Copy to clipboardErrorCopied
返回参数
参数名类型说明
errCodeint0成功，非0失败
errMsgstring错误信息
sendTimeint消息发送的具体时间，具体为毫秒的时间戳
serverMsgIDstring服务器生成的消息的唯一ID
clientMsgIDstring客户端生成的消息唯一ID，默认情况使用这个为主键
消息类型格式描述
简要描述
管理员消息发送字段中contentType支持的消息类型说明以及消息content的具体字段说明。
ContentType消息类型说明
ContentType值类型说明
101文本消息
102图片消息
103音频消息
104视频消息
105文件消息
106群聊中的@类型消息
107合并转发类型消息
108名片消息
109地理位置类型消息
110自定义消息
111撤回类型消息
112已读回执类型消息
114引用类型消息
Content具体内容
content内部为具体的json对象，不同的消息类型是不同的json对象
文本消息
{
...,
"content": {
"text": "nihao"
},
....
}Copy to clipboardErrorCopied
参数名必选类型说明
text是string文本消息的具体内容
自定义消息
{
...,
"content": {
"data": "",
"description": "",
"extension": ""
},
....
}Copy to clipboardErrorCopied
参数名类型必选说明
datajson string是用户自定义的消息为json对象转换后的string
descriptionjson string否扩展的描述信息为json对象转换后的string，可以不使用
extensionjson string否扩展字段，暂时不使用
一、消息中间件相关知识
1、概述
消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。
2、消息中间件的组成
2.1 Broker
消息服务器，作为server提供消息核心服务
2.2 Producer
消息生产者，业务的发起方，负责生产消息传输给broker，
2.3 Consumer
消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理
2.4 Topic
2.5 Queue
2.6 Message
消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输
3 消息中间件模式分类
3.1 点对点
PTP点对点:使用queue作为通信载体
说明：
消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。 Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
说明：
queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。
4 消息中间件的优势
4.1 系统解耦
交互系统之间没有直接的调用关系，只是通过消息传输，故系统侵入性不强，耦合度低。
4.2 提高系统响应时间
例如原来的一套逻辑，完成支付可能涉及先修改订单状态、计算会员积分、通知物流配送几个逻辑才能完成；通过MQ架构设计，就可将紧急重要（需要立刻响应）的业务放到该调用方法中，响应要求不高的使用消息队列，放到MQ队列中，供消费者处理。
4.3 为大数据处理架构提供服务
通过消息作为整合，大数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能支持。
4.4 Java消息服务——JMS
Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
5 消息中间件应用场景
5.1 异步通信
有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
5.2 解耦
降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
5.3 冗余
有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
5.4 扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。
5.5 过载保护
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5.6 可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
5.7 顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
5.8 缓冲
在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。
5.9 数据流处理
分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。
6 消息中间件常用协议
6.1 AMQP协议
AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。
优点：可靠、通用
6.2 MQTT协议
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。
优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统
6.3 STOMP协议
STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。
优点：命令模式（非topic\queue模式）
6.4 XMPP协议
XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。
优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大
6.5 其他基于TCP/IP自定义的协议
有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。
7 常见消息中间件MQ介绍
7.1 RocketMQ
阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。
具有以下特点：
官方提供了一些不同于kafka的对比差异：
https://rocketmq.apache.org/docs/motivation/
7.2 RabbitMQ
使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。
7.3 ActiveMQ
Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。
7.4 Redis
使用C语言开发的一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
7.5 Kafka
Apache下的一个子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统，具有以下特性：
7.6 ZeroMQ
号称最快的消息队列系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常使用，偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，开发成本高。因此ZeroMQ具有一个独特的非中间件的模式，更像一个socket library，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。但是ZeroMQ仅提供非持久性的队列，如果down机，数据将会丢失。如：Twitter的Storm中使用ZeroMQ作为数据流的传输。
ZeroMQ套接字是与传输层无关的：ZeroMQ套接字对所有传输层协议定义了统一的API接口。默认支持 进程内(inproc) ，进程间(IPC) ，多播，TCP协议，在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建立，断开和重连逻辑。
特性：
二、主要消息中间件的比较
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）