rocketmq一些小的总结

rocketmq重试机制。

  • producer端推送消息到broker失败重试:
    有很多种情况会影响生产端重试发送消息。
    1,网络不可达造成的重试:如果在生产者发送消息到broker或者broker向生产者发送结果时,因为网络原因,生产者没有获取成功响应,在这中情况下,生产者会无限次重试。
    2,broker存储过程中出现异常,会导致生产者重试。

  • consumer端消费消息失败重试。
    1,网络不可达,这种情况和生产者一样,不可达造成的重试(相当于浏览器访问一个请求没有返回200响应码,都算网络不可达)会是无限次的。
    2,由于业务业务处理的原因导致异常的出现,导致给broker的响应不是成功的结果(相当于浏览器请求返回200,成功结果,但是业务code是非成功的code),这种失败时有次数限时的重试,每次重试会延迟发送消费信息,避免短时间内消费端没有解决bug或者服务没有启动,所以有个延迟重试。

rocket的集群模式

1,单机模式:在测试环境的时候,由于资源的限制,可以选择单机,执行或者学习rocketmq的功能。

2,多master;只有master没有salve;rocketmq每个master之间是互不通信,所以,如果某个mater宕机,该台机器上的数据是无法被消费的,只有等到master重新启动才可以被消费端消费。如果宕机的master磁盘有问题,且无法恢复,会导致master的数据丢失,即消息丢失。

3,多master多slave;这种模式即每个master至少会有slave(master和slave的集群名称和接单名称一样,只是节点的id不同,而且master的id必须为0,slave的id大于0,可以是一台也可以多台slave,1,2,3,4,5标示不同的slave)。这种方式虽然需要的资源比较多,但是可以保证在master挂掉的时候,不影响消费者的消费,可以减小对消费端的影响。master和slave之间是有联系的,在配置的时候,master和slave可以配置不同的数据同步模式,可以异步复制,也可以同步双写;异步复制效率更高,但是如果master挂掉,磁盘损坏的情况下,会有少量数据丢失,但是不会想多master模式下,master挂掉并且磁盘顺坏导致这个节点下的所有的数据丢失。同步双写,是说producer发送消息的时候,只有master和slave都保存成功的时候,才告诉producer发送成功,这样即使master挂掉,slave也有完整的数据,可以保证消息不丢失,但是效率较异步复制差,这种情况一般适用于和钱相关的,不能允许丢消息的情况。

rocketmq的发布-订阅

rocketmq支持广播和发布-订阅两种消息模式。发布-订阅模式,严格意义上说必须是先启动consumer端,再启动producer端。如果先启动生产端并生产消息,之后在启动消费端,会有一些意想不到的结果。可能会导致大量的重复消费的情况。

rocketmq消费端幂等性设计。

集群模式下,生产端如果消息发送失败,生产端会重试。但是有时候,生产端发送消息broker保存成功,但是在向producer反馈的时候,网络异常,导致生产端误以为失败。重复发送消息。或者在消费端,消费成功,但是网络原因ack的时候失败。导致broker重复发送消息到消费端。或者刚启动的consumer,会消费到另一个consumer正在消费,但是还没有反馈给broker结果的消息。等等情况都会导致消费端消费的重复的消息。
这个时候,为了保证数据的一致性,必须在消费端要保证消费的幂等性。即,如果有重复的消息,直接反馈上一次消费成功的结果。如果没有消费成功,再继续消费。总之,消息只能被成功消费一次。

如何保证rocketmq消费的幂等性

在生产端发送消息的时候,message可以传递key,这个key必须是全局唯一的(可以是时间毫秒数),这样消费端在消费的时候可以看是否有改key的成功消费结果。如果有直接反馈成功结果给broker,如果没有继续消费。或者在消息中有唯一性的业务主键,这样可以使用业务主键而不使用key来保证不重复消费。

你可能感兴趣的:(rocketmq一些小的总结)