vvhaleCH的博客

1.消费端收到消息的时候，使用Redis提供的incr，以msgID作为key（保证唯一性），value默认从1开始递增；由于消息的重复性往往是由于网络抖动造成的，所以我们一般要在自己的业务端完成消息的去重。2.当incr返回值为1的时候，设置其失效时间为2分钟，并且要注意，该消息需要被消费；在保证了rocketMQ的消息顺序性之后，还应该进行消息去重。3.当incr返回值大于1 的时候，忽略该消息。一个可用的方案就是使用Redis做缓存。

TopicPublishInfo类是用于producer端做负载均衡的关键类，producer通过这个类识别broker并选择broker。MessageQueue类描述了单个消息队列的模型。这个类用于管理队列属于那个topic，以及在哪个broker。TopicRouteData类：topic路由信息集中管理了当前topic下的所有队列信息和broker信息。成员变量brokerDatas包含了该broker的group名字和物理地址。

这里需要注意一点：假如有broker宕机，我们的生产者最少也要30秒之后才能感知到。在这期间依旧会向broker发送消息。当一条消息发送至某个broker失败之后，会向这个broker自动重发，假如还是失败，抛出异常，业务捕获异常，重新发送消息（重新选取broker）。生产者发送时，会自动轮巡所有可以发送的broker，一条消息发送成功，下一次发送消息换另一个broker发送，使消息平均落在所有broker上。

可以做集群，提供轻量级的服务发现与路由。每个nameserver记录完整的路由信息，提供等效的读写服务并支持快速存储扩展。就是一个注册中心，存储当前集群所有broker的信息、Topic和broker的对应关系。nameserver用于存储topic、broker关系信息，功能简单、稳定性高。多个nameserver之间没有通信，单台nameserver宕机不影响其他nameserver和集群。

同步的向broker发送消息，等待响应。超时则重发，本质上是一个循环，可以设置次数。broker提供多主模式。

首先要找到原因，是producer太多了，还是说consumer太少了。定位问题，然后看下消息的消费速度是否正常，正常的话，可以通过临时上线更多consumer解决问题。rocketMQ中的消息只有在commitLog被删除的时候才会消失，不会超时。也就是说没被消费的消息不存在会被超时删除这种情况。如果consumer和queue不对等，上线了多台consumer也无法解决的话，可以。不会的，消息再被消费失败后会进入重试队列。tip2：堆积的消息会不会进入死信队列？tip1：堆积时间过长消息会超时吗？