最佳实践 #

生产者 #

• 一个应用尽可能用一个Topic，而消息子类型则可以用tags来标识。
• 每个消息在业务层面一般建议映射到业务的唯一标识并设置到keys字段，方便将来定位消息丢失问题。常见的设置策略使用订单Id、用户Id、请求Id等比较离散的唯一标识来处理。
• 消息发送成功或者失败要打印消息日志，用于业务排查问题。Send消息方法只要不抛异常，就代表发送成功。
• Producer的send方法本身支持内部重试，如果业务要求消息发送不能丢，仍然需要对可能出现的异常做兜底，比如消息存到DB后续重试。

消费者 #

• 消费过程幂等，如果业务对消费重复非常敏感，务必要在业务层面进行去重处理。
• 消费慢可以在同一个消费组下面增加消费者数量来提高并行度。
• 如果消息量较少，建议在消费入口方法打印消息，消费耗时等，方便后续排查问题。

Broker #

Broker 角色分为 ASYNC_MASTER（异步主机）、SYNC_MASTER（同步主机）以及SLAVE（从机）。如果对消息的可靠性要求比较严格，可以采用 SYNC_MASTER加SLAVE的部署方式。如果对消息可靠性要求不高，可以采用ASYNC_MASTER加SLAVE的部署方式。如果只是测试方便，则可以选择仅ASYNC_MASTER或仅SYNC_MASTER的部署方式。

JVM选项 #

推荐使用最新发布的 JDK 版本，生产环境 JVM 配置如下所示：

-server -Xms8g -Xmx8g -Xmn4g 

当 JVM 是默认 8 字节对齐，建议配置最大堆内存不要超过 32 G，否则会影响 JVM 的指针压缩技术，浪费内存。

订阅关系一致 #

订阅关系一致是指，同一个消费者组下所有消费者实例所订阅的Topic、Tag必须完全一致。如果订阅关系（消费者分组名-Topic-Tag）不一致，会导致消费消息紊乱，甚至消息丢失。