如何做求婚网站杭州市上城区建设局网站

如何做求婚网站,杭州市上城区建设局网站,原创wordpress付费主题,优秀h5案例目录 1. 核心概念 2. 面临的挑战 3. 关键实现机制 3.1 生产端保证 3.2 Broker端保证 3.3 消费端保证 4. 完整可靠性方案 4.1 事务消息方案#xff08;如RocketMQ#xff09; 4.2 最大努力投递方案 4.3 本地消息表方案#xff08;经典#xff09; 5. 高级特性与优…目录1. 核心概念2. 面临的挑战3. 关键实现机制3.1 生产端保证3.2 Broker端保证3.3 消费端保证4. 完整可靠性方案4.1 事务消息方案如RocketMQ4.2 最大努力投递方案4.3 本地消息表方案经典5. 高级特性与优化5.1 顺序性保证5.2 批量消息可靠性5.3 监控与对账6. 不同MQ的实现差异7. 实践建议总结面试回答1.核心概念可靠性投递Reliable Delivery是指确保消息从生产者成功到达消费者即使面对网络故障、系统崩溃等异常情况也能保证不丢失、不重复、按顺序部分场景传递。2.面临的挑战网络不可靠丢包、延迟、分区节点故障生产者/消费者/中间件宕机重复消费确认机制可能引发重复顺序保证分布式环境下消息乱序3.关键实现机制3.1生产端保证// 伪代码示例生产端确认模式 public void sendWithConfirm(Message msg) { // 1. 持久化到本地数据库防丢失 messageDao.save(msg); // 2. 发送到消息队列 String msgId rabbitTemplate.convertAndSend(msg); // 3. 等待Broker确认 boolean ack waitForAck(msgId, TIMEOUT); // 4. 失败重试指数退避 if (!ack) { retryWithBackoff(msg); } // 5. 最终记录投递状态 updateDeliveryStatus(msgId, ack); }技术要点事务机制同步方式性能差不推荐确认机制Confirm普通确认每消息确认批量确认提高吞吐异步监听最佳实践本地消息表事务消息的替代方案消息持久化设置delivery_mode23.2Broker端保证消息处理流程 Producer → Broker接收 → 持久化存储 → 推送给Consumer → 等待ACK → 删除/重投持久化策略队列持久化durabletrue消息持久化delivery_mode2镜像队列多副本冗余RabbitMQ高可用集群主从切换时不丢消息3.3消费端保证// 消费端保证示例 RabbitListener(queues order.queue) public void handleOrder(OrderMessage order, Channel channel, Header(AmqpHeaders.DELIVERY_TAG) long tag) { try { // 1. 业务处理 orderService.process(order); // 2. 手动确认成功才ACK channel.basicAck(tag, false); // 3. 更新消费记录 consumeRecordService.markConsumed(order.getId()); } catch (Exception e) { // 4. 失败处理重试或进入死信队列 if (retryCount MAX_RETRY) { channel.basicNack(tag, false, true); // 重入队列 } else { channel.basicNack(tag, false, false); // 进入死信队列 alarmService.notifyAdmin(order, e); } } }消费端关键点手动ACK避免自动确认导致消息丢失幂等性设计public boolean processWithIdempotent(String msgId) { // 基于消息ID去重 if (redis.exists(processed: msgId)) { return true; // 已处理过 } // 业务处理 boolean success doBusinessLogic(); // 记录处理状态 if (success) { redis.setex(processed: msgId, 24h, 1); } return success; }死信队列DLQ处理无法消费的消息消费重试策略立即重试瞬时故障延迟重试业务依赖指数退避防止雪崩4.完整可靠性方案4.1事务消息方案如RocketMQ两阶段提交 1. 发送Half Message预备消息 2. 执行本地事务 3. 根据本地事务结果Commit/Rollback 4. Broker检查事务状态并投递/丢弃4.2最大努力投递方案# 补偿机制实现 def reliable_delivery(message): max_retries 5 for attempt in range(max_retries): try: # 尝试投递 result mq_client.send(message) if result.confirmed: log_delivery_success(message.id) return True except Exception as e: log_failure(attempt, e) if attempt max_retries - 1: # 最终失败人工介入 send_alert_to_admin(message) save_to_compensation_table(message) return False # 等待后重试 sleep(backoff_time(attempt)) return False4.3本地消息表方案经典-- 本地消息表结构 CREATE TABLE local_message ( id BIGINT PRIMARY KEY, biz_id VARCHAR(64), -- 业务ID content TEXT, -- 消息内容 status TINYINT, -- 0:待发送, 1:已发送, 2:已确认 retry_count INT, next_retry_time DATETIME, created_at TIMESTAMP );工作流程业务数据消息记录原子性写入本地DB定时任务扫描待发送消息调用MQ发送成功后更新状态消费者处理完成后反向确认对账程序定期校验数据一致性5.高级特性与优化5.1顺序性保证全局有序单队列单消费者性能低局部有序相同sharding key的消息发到同一队列牺牲场景重试队列可能破坏顺序5.2批量消息可靠性// 批量消息的可靠性处理 public class BatchMessageReliableSender { public void sendBatch(ListMessage batch) { // 1. 批量持久化到本地 batchMessageDao.saveAll(batch); // 2. 设置批次ID String batchId generateBatchId(); // 3. 发送批次消息 boolean success mqTemplate.sendBatch(batchId, batch); // 4. 批次确认或单条补偿 if (success) { markBatchDelivered(batchId); } else { // 逐条重试或记录异常 compensateFailedMessages(batch); } } }5.3监控与对账实时监控堆积情况监控消费延迟报警失败率统计定期对账-- 消息对账SQL示例 SELECT DATE(create_time) as day, COUNT(*) as total_sent, SUM(CASE WHEN status2 THEN 1 ELSE 0 END) as confirmed, SUM(CASE WHEN status1 THEN 1 ELSE 0 END) as pending FROM message_record GROUP BY DATE(create_time) HAVING total_sent ! confirmed;6.不同MQ的实现差异特性RabbitMQKafkaRocketMQ可靠性机制确认持久化镜像队列副本机制ACKExactly-Once事务消息本地存储顺序性单队列保证Partition内有序Queue内有序事务支持轻量级事务性能差支持Exactly-Once语义完整事务消息最佳适用场景业务消息、高可靠要求日志流、大数据场景金融交易、订单业务7.实践建议分级可靠性策略关键业务事务消息本地表对账普通业务确认机制重试死信队列日志类最多一次投递即可性能与可靠性的平衡同步刷盘 vs 异步刷盘同步复制 vs 异步复制根据业务重要性选择配置灾难恢复设计# 配置示例多级降级 mq: primary: url: amqp://primary timeout: 1000ms secondary: url: amqp://secondary timeout: 2000ms fallback-to-db: true # 最终降级到数据库总结消息的可靠性投递是一个系统工程需要在生产端、Broker端、消费端协同设计结合业务场景、性能要求、成本约束做出合适的选择。没有银弹方案只有最适合的方案。建议从简单方案开始随着业务复杂度增加逐步引入更完善的可靠性机制。面试回答首先消息可靠性投递指的是一个消息从发送到被消费者成功处理过程中不会丢失或重复保证最终数据的一致性。在实际系统里消息可能因为网络问题、服务重启等原因丢失或重复所以我们需要一套机制来确保可靠。为什么需要它呢比如在订单系统中用户支付成功后要通知物流系统如果消息丢了物流就不会触发用户体验就受损如果消息重复可能重复发货造成损失。所以像金融、交易这些场景可靠性特别重要。常见的实现方式我了解的有几种生产者确认机制生产者发消息后MQ比如RabbitMQ会返回一个确认ACK如果没收到ACK生产者可以重发。这样可以防止消息在发送阶段丢失。消息持久化消息保存到磁盘而不是只放在内存。这样即使MQ重启消息也不会丢。消费者手动ACK消费者处理完消息后手动告诉MQ“我已经处理完了”MQ才删除消息如果处理失败MQ可以把消息重新投递给其他消费者。避免消息在处理阶段丢失。事务消息比如RocketMQ先发一个“半消息”等本地事务执行成功再确认投递如果失败就回滚。这适用于分布式事务场景。消息去重为了避免重复消费可以在消费端做幂等性设计。比如在数据库里记录消息ID每次处理前先查一下是否已经处理过。实际中我们一般会结合业务来设计。比如一个订单状态同步的场景我可能会用生产者确认 消息持久化 消费者手动ACK 消费端幂等性。这样基本能覆盖发送、存储、消费各个环节的可靠性。当然可靠性和性能之间需要权衡比如持久化会降低吞吐量手动ACK会增加延迟。所以要根据业务需求来选择合适的方案。追加遇到过消息丢失或重复的问题你是怎么排查和解决的追加是否了解最终一致性、最大努力通知等模式 如果小假的内容对你有帮助请点赞评论收藏。创作不易大家的支持就是我坚持下去的动力