一种生产消息的方法

文档序号:9420412阅读:264来源:国知局
一种生产消息的方法
【技术领域】
[0001]本发明属于消息系统领域,具体涉及一种生产消息的方法。
【背景技术】
[0002]现有的分布式发布-订阅消息系统已经开始得到应用。典型的如LinkedIn公司开发的Kafka,之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的,分区的和可复制的提交日志服务。
[0003]Apache Kafka与传统消息系统相比,有以下不同:?它被设计为一个分布式系统,易于向外扩展;?它同时为发布和订阅提供高吞吐量;?它支持多订阅者,当失败时能自动平衡消费者;?它将消息持久化到磁盘,因此可用于批量消费,例如ETL,以及实时应用程序。
[0004]Kafka的架构包括以下组件:.话题(Topic)是特定类型的消息流。消息是字节的有效负载(Payload),话题是消息的分类名或种子(Feed)名。?生产者(Producer)是能够发布消息到话题的任何对象。.已发布的消息保存在一组服务器中,它们被称为代理(Broker)或Kafka集群。.消费者可以订阅一个或多个话题,并从Broker拉数据,从而消费这些已发布的消息。
[0005]?话题(Topic)是特定类型的消息流。消息是字节的有效负载(Payload),话题是消息的分类名或种子(Feed)名。?生产者(Producer)是能够发布消息到话题的任何对象。
[0006].已发布的消息保存在一组服务器中,它们被称为代理(Broker)或Kafka集群。
[0007].消费者可以订阅一个或多个话题,并从Broker拉数据,从而消费这些已发布的消息。
[0008]JMS实现,消息消费的位置是有prodiver保留,以便避免重复发送消息或者将没有消费成功的消息重发等,同时还要控制消息的状态.这就要求JMS broker需要太多额外的工作.在kafka中,partit1n中的消息只有一个consumer在消费,且不存在消息状态的控制,也没有复杂的消息确认机制,可见kafka broker端是相当轻量级的.当消息被consumer接收之后,consumer可以在本地保存最后消息的offset,并间歇性的向zookeeper注册offset.由此可见,consumer客户端也很轻量级.
[0009]消息传送机制:对于JMS实现,消息传输担保非常直接:有且只有一次(exactlyonce).在kafka中稍有不同:I) at most once:最多一次,这个和JMS中〃非持久化〃消息类似.发送一次,无论成败,将不会重发.2)at least once:消息至少发送一次,如果消息未能接受成功,可能会重发,直到接收成功.3) exactly once:消息只会发送一次.
[0010]目前具有中心结点的分布式消息系统都有副本结点用于容灾时切换,然而由于中心结点与副本结点之间数据同步存在不同程度的时延,使得生产者生产的消息容易出现重复、丢失冋题。
[0011]当前生产者一般采用三种方式生产消息:一是At most once方式,生产的消息可能会丢失,但绝不会重复存储;二是At least once方式,生产的消息绝不会丢失,但可能会重复存储;三是Exactly once方式,生产的消息仅存储一次,且不会丢失,很多时候这是生产者最理想的消息生产方式。

【发明内容】

[0012]为了确保出现网络故障、中心结点切换时不会导致生产消息丢失、重复,本发明设计了一种Exactly once方式生产消息的方法。
[0013]技术方案,详细如下:一种生产消息的方法,包括当前中心结点存储消息进程和所有副本结点同步消息进程;
[0014]步骤一、当前中心结点接收消息生产者生产的消息,判断其是否为重试消息,如为重试消息,进入步骤二,否则进入步骤三;
[0015]步骤二、判断消息状态及其处理结点:当前中心结点在数据库中查询并获取重试消息状态及其处理结点,如其状态为“成功”或其状态为“处理中”且其处理结点为当前中心结点,则返回相应的响应给消息生产者,结束当前生产消息进程;如其状态为“失败”或其状态为“处理中”且其处理结点非当前中心结点,则进入步骤三;
[0016]步骤三、当前中心结点开始存储此消息,若存储失败,设置此消息状态为“失败”并将消息状态及其处理结点保存到数据库中,返回失败响应给消息生产者,结束当前生产消息进程;如存储成功,设置此消息状态为“处理中”并将消息状态及其处理结点保存到数据库中,当前中心结点在设定的等待时间内等待所有副本结点同步消息;
[0017]所有副本结点同步消息进程步骤与当前中心结点存储消息进程同步进行,包括以下步骤:
[0018]步骤一:各个副本结点周期性地向当前中心结点发起消息同步请求,同步请求里含有其当前已存储的消息位置;
[0019]步骤二:中心结点接收到消息同步请求,读取各个副本结点当前已存储的消息位置,记录所有副本结点共同到达的消息位置,即消息水位,将所有结点(包括当前中心结点和所有副本结点)处在消息水位及之前的消息状态设置为“成功”,同时向各个副本结点发送其当前已存储消息位置之后的消息及所记录的消息水位;
[0020]步骤三:各个副本结点存储消息,同时进行步骤一;
[0021]进一步的,当前中心结点存储消息进程步骤一中判断是否为重试消息和步骤二中判断消息状态及其处理结点,使得当网络故障或中心结点切换等情况发生时,不会生产重复消息。
[0022]进一步的,所有副本结点同步消息进程的步骤二中,当前中心结点向各个副本结点发送所记录的消息水位,当前中心结点切换时,所有结点(包括当前中心结点和所有副本结点)清除处在消息水位之后的数据,使得不会生产重复消息。
[0023]—种生产消息的方法,当前中心结点存储消息进程的步骤三中当前中心结点存储消息成功,设置此消息状态为“处理中”和所有副本结点同步消息进程的步骤二中消息水位的记录以及将所有结点(包括当前中心结点和所有副本结点)处在消息水位及之前的消息状态设置为“成功”,保证所有结点处在消息水位及之前的数据一致性,使得当网络故障或中心结点切换等情况发生时,不会丢失消息。
[0024]—种生产消息的方法,当前中心结点存储消息进程和所有副本结点同步消息进程同步进行后即完成当前生产消息进程,具体有两种结果:
[0025]结果1:在等待时间内,消息水位到达当前生产的消息位置,所有结点(包括当前中心结点和所有副本结点)处在当前生产的消息位置及之前的消息状态设置为“成功”;
[0026]结果2:在等待时间内,消息水位未到达当前生产的消息位置,所有结点(包括当前中心结点和所有副本结点)处在消息水位及之前的消息状态设置为“成功”,当前中心结点处在消息水位之后的消息状态仍为“处理中”。
[0027]本发明的有益效果,其显著优点为:
[0028](I)判断是否为重试消息、判断消息状态及其处理结点以及当前中心结点切换时所有结点(包括当前中心结点和所有副本结点)清除处在消息水位之后的数据,保证当网络故障或中心结点切换等情况发生时,不会生产重复消息;
[0029](2)当前中心结点存储消息成功时设置此消息状态为“处理中”、消息水位的记录以及将所有结点(包括当前中心结点和所有副本结点)处在消息水位及之前的消息状态设置为“成功”,保证所有结点处在消息水位及之前的数据一致性,使得当网络故障或中心结点切换等情况发生时,不会丢失消息。
【附图说明】
[0030]图1为本发明实施例1生产消息前当前中心结点与所有副本结点消息存储示意图。
[0031]图2为本发明实施例生产消息的流程图。
[0032]图3为本发明实施例生产消息后当前中心结点与所有副本结点消息存储示意图。
[0033]图4为本发明实施例切换当前中心结点后所有结点消息存储示意图,亦作为本发明实施例2生产消息前当前中心结点与所有副本结点消息存储示意图。
【具体实施方式】
[0034]为了使本发明的目的、技术方案和优点更加清楚,下面结合附图和具体实施例对本发明进行详细描述。
[0035]如图1所示,为本发明实施例1生产消息前当前中心结点与所有副本结点消息存储示意图。消息存储时有一个中心结点和两个副本结点,本实施例1假设消息生产者已生产消息5,给出生产消息者生产消息6前当前中心结点与所有副本结点消息存储的两种情形:上方A情形示出当前消息水位到达消息4(消息水位即所有副本结点共同到达的消息位置),其中当前中心结点处在消息水位之后的消息状态为“处理中”,即当前中心结点消息5的消息状态为“处理中”,当前中心结点和副本结点2已存储的消息5对消息消费者不可见;下方B情形示出当前消息水位到达消息5。两种情形均满足所有结点(包括当前中心结点和所有副本结点)处在消息水位及之前的消息状态为“成功”,已“成功”生产的消息才对消费者可见。
[0036]如图2所示,为本发明实施例生产消息的流程图。本发明实施例1生产消息前当前中心结点与所有副本结点消息存储示意图如图1所示,此流程图对于图1的A、B两种情形均适用。本实施例1假设生产者生产消息6。
[0037]当前中心结点存储消息进程,包括以下步骤:
[0038]步骤201:当前中心结点接收消息生产者生产的消息,判断其是否为重试消息,如为重试消息,进入步骤202,否则进入步骤203 ;本实施例1消息6不为重试消息。
[0039]步骤202:当前中心结点在数据库中查询并获取重试消息状态及其处理结点,如其状态为“成功”或其状态为“处理中”且其处理结点为当前中心结点,则返回相应的响应给消息生产者,结束当前生产消息进程,如其状态为“失败”或其状态为“处理中”且其处理结点非当前中心结点,则进入步骤203。
[0040]步骤203:当前中心结点存储此消息,若存储失败,设置此消息状态为“失败”并将消息状态及其处理结点保存到数据库中,返回失败响应给消息生产者,结束当前生产消息进程,如存储成功,设置此消息状态为“处理中”并将消息状态及其处理结点保存到数
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1