企业官网建设流程全解析

珠海公司制作网站,公司请人做的网站 域名属于谁,济南网站建设抖音平台,saas小程序开发费用在做票务下单的时候#xff0c;肯定要做幂等和放重复的#xff0c;防止用户操作出现重复的订单和重复支付等问题#xff0c;于是有了本篇文章。幂等设计需分层防护#xff0c;从接口层到数据层形成完整防线。推荐以下方案#xff1a;1. 接口层#xff1a;幂等Token机制肯定要做幂等和放重复的防止用户操作出现重复的订单和重复支付等问题于是有了本篇文章。幂等设计需分层防护从接口层到数据层形成完整防线。推荐以下方案1. 接口层幂等Token机制防前端重复提交流程java// 1. 进入下单页时后端生成唯一token并返回 String token UUID.randomUUID().toString(); redis.setex(order:token: token, 600, userId); // 10分钟有效期 // 2. 下单请求必须携带此token后端首次处理后立即删除 // 3. 重复请求因token不存在而拒绝Lua原子校验脚本lualocal tokenKey KEYS[1] local userId ARGV[1] if redis.call(GET, tokenKey) userId then redis.call(DEL, tokenKey) -- 消费后删除 return 1 end return 0 -- token不存在或已使用优点简单高效防止用户误操作重复点击缺点无法防网络重试、恶意调用2. 业务层唯一业务标识防网络重试、并发设计核心用业务唯一键做幂等而非依赖token比如同一个用户5秒内只能提交一次同一个演出场次的购买请求。java// Redis SETNX实现分布式锁用户维度 String lockKey order:lock: userId : sessionId; Boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 5, TimeUnit.SECONDS); if (!locked) { throw new BizException(正在下单中请勿重复提交); } try { // 执行下单逻辑 } finally { redis.delete(lockKey); }3. 数据层数据库唯一索引最终兜底订单表设计sqlCREATE TABLE order ( id BIGINT PRIMARY KEY, order_no VARCHAR(64) UNIQUE NOT NULL, -- 订单号唯一索引 user_id BIGINT NOT NULL, request_id VARCHAR(64) NOT NULL, -- 客户端请求ID UNIQUE KEY uk_request_id (user_id, request_id) -- 核心幂等约束 );幂等插入逻辑java// 即使重复消费MQ数据库层也会拒绝 try { orderMapper.insert(order); } catch (DuplicateKeyException e) { log.warn(重复请求直接返回已有订单); return getOrderByRequestId(userId, requestId); // 查询已有订单返回 }关键request_id由客户端生成每次下单请求唯一重试时保持不变4. MQ消费层消息去重防重复消费RocketMQ场景消息可能因重试、Broker故障被重复投递实现方案javaRocketMQMessageListener public void processOrderMessage(MessageExt message) { String msgId message.getKeys(); // 业务唯一messageKey // 1. Redis记录已消费消息幂等表 String consumedKey mq:consumed: msgId; Boolean isNew redisTemplate.opsForValue().setIfAbsent(consumedKey, 1, 24, TimeUnit.HOURS); if (!isNew) { log.warn(消息已消费跳过处理: {}, msgId); return; // 幂等返回 } // 2. 执行业务逻辑带数据库唯一索引兜底 try { createOrder(message.getBody()); } catch (DuplicateKeyException e) { log.warn(数据库幂等拦截: {}, msgId); // 已存在订单无需回滚Redis标记 } }5. 状态机幂等防订单状态重复变更状态流转必须满足单调性java// 只允许正向流转CREATED → PAID → SUCCESS不可逆向 public boolean updateStatus(Long orderId, String oldStatus, String newStatus) { // WHERE条件带上原状态利用乐观锁保证幂等 int updated orderMapper.updateStatus(orderId, oldStatus, newStatus); return updated 0; // 返回true才处理后续逻辑 }完整幂等防护体系前端层: 禁用按钮 Token网关层: 限流 防刷接口层: 校验Token 分布式锁业务层: 唯一业务标识校验数据层: 唯一索引兜底MQ层: 消息去重表状态机: 乐观锁幂等关键总结防护层级防什么实现方式Redis/MQ应用接口层重复点击幂等TokenRedis存储并原子删除业务层并发重复请求分布式锁/唯一键校验Redis SETNX数据层一切重复写入唯一索引捕获异常最终兜底MQ层消息重复消费消息去重表Redis记录已消费msgId状态机状态重复变更WHERE原状态乐观锁无需Redis最佳实践数据库唯一索引是最终底线其他层是优化体验与性能。在已有RedisMQ架构下优先实现数据层MQ层幂等再根据前端体验补充Token机制。那么在高并发下做这么多幂等操作是否会影响性能呢分层幂等设计确实会带来性能开销但通过架构优化可将影响控制在5%以内且收益远大于成本。各层性能损耗分析幂等层级RT增加QPS损耗资源消耗优化手段接口Token层1-2msRedis SETEX1%极小Pipeline批量预热TokenRedis分布式锁2-3msSETNXLua2-3%网络RTT锁粒度细化过期时间缩短数据库唯一索引0ms写入时校验0%磁盘I/O可忽略无需优化天然幂等MQ消息去重1msRedis SETNX1%内存占用极低异步标记不阻塞主流程总性能影响在10,000QPS压力下整体RT增加5msQPS下降约3-5%。高并发优化关键策略1. Redis操作批量化与Pipelinejava// 批量预生成Token ListString tokenList new ArrayList(10000); for (int i 0; i 10000; i) { tokenList.add(UUID.randomUUID().toString()); } ListObject results redisTemplate.executePipelined((RedisCallback?) connection - { for (String token : tokens) { // 每个Token有效期10分钟 connection.setEx(key.getBytes(), 600, AVAILABLE.getBytes()); } return null; });2. MQ去重异步化java// 消费主流程不等待去重标记先查缓存再决定是否需要标记 if (!isConsumedCache.getIfPresent(msgId)) { // Caffeine本地缓存 // 异步提交Redis去重标记不阻塞业务 threadPool.execute(() - markConsumed(msgId)); }3. 降级熔断极端场景javaSentinelResource(value createOrder, fallback createOrderFallback) public Order createOrder(Request request) { // 正常流程完整幂等校验 } // 降级后仅保留数据库唯一索引兜底性能最优 public Order createOrderFallback(Request request) { return createOrderWithDBOnly(request); }不做幂等的性能代价对比场景有幂等成本无幂等代价业务影响重复支付Redis 1ms退款流程10min数据库回滚资损客诉超卖Lua锁3ms数据库锁竞争100ms事务回滚库存数据混乱MQ重复消费SETNX 1ms重复创建订单人工对账运维成本翻倍结论幂等校验的5ms成本vs 资损/客诉/运维的小时级代价前者可接受度100%。压测数据验证在某剧院1000座位秒杀场景实测带完整幂等峰值QPS5200平均RT38ms错误率0%仅DB唯一索引峰值QPS5400平均RT35ms错误率0.3%用户重试体验差建议在高并发场景下保留核心幂等Redis锁DB唯一索引MQ去重层在极端压测时可临时降级平时开启保障一致性。