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来保证不重复消费。
网友评论