在深圳做it的要做赌博网站吗关于市场营销的100个问题

在互联网应用中，尤其在网络不稳定的情况下，消息队列 RocketMO 的消息有可能会出现重复，这个重复简单可以概括为以下情况:

1、发送时消息重复

当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端应答失败。如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同并日 Message lD 也相同的消惠

2、投递时消息重复
消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候网络闪断。 为了保证消息至少被消费一次，消息队列 RocketMO 的服务端将在网络恢复后再次尝试投递之前已被处理过的消息，消费者后续会收到两条内容相同并且 Message lD 也相同的消息。

3、负载均衡时消息重复(包括但不限于网络抖动、Broker 重启以及订阅方应用重启)当消息队列 RocketMQ 的 Broker 或客户端重启、扩容或缩容时，会触发 Rebalance，此时消费者可能会收到重复消息。

消费者重复消息解决方案

针对消费者重复消息的解决方案，可以采用如下的几种方案。

1.采用数据库乐观锁实现. 2.采用Redis的写入，因为Redis的写入操作支持天然的幂等性。

消费数据只是单纯的写入数据库
可以在生产消息的时候为每一个消息加一个全局唯一ID，消费数据插入数据库之前根据主键ID判断数据是否存在，或者建立联合主键索引，重复插入时会报错
消费数据只是写入redis中
不需要处理，因为redis天然具有幂等性
复杂业务情况
将所有消费过的消息ID存入redis，使用redis进行消费判断，和数据库判断相比更快

1、mysql表结构

DROP TABLE IF EXISTS `message_idempotent`;
CREATE TABLE `message_idempotent` (
  `message_id` varchar(50) NOT NULL COMMENT '消息ID',
  `message_content` varchar(2000) DEFAULT NULL COMMENT '消息内容',
  `status` int DEFAULT '0' COMMENT '消费状态（0-未消费成功;1-消费成功）',
  `retry_times` int DEFAULT '0' COMMENT '重试次数',
  PRIMARY KEY (`message_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

2、redis

redis_client.set('唯一业务id', "1",过期时间一周)