企业官网建设流程全解析

wordpress网站聊天插件,网站建设企业类型是什么,阿里巴巴装修网站,外管局网站先支后收怎么做报告前言 幂等性是防止重复操作的关键机制。很多线上问题都是因为没有做幂等#xff1a;用户连点两次创建了两个订单、弱网重试导致重复扣款、重复发送短信。这篇给你5个常见场景的幂等性设计方法。 一、什么是幂等性 定义#xff1a;同一个请求执行多次#xff0c;结果和执行…前言幂等性是防止重复操作的关键机制。很多线上问题都是因为没有做幂等用户连点两次创建了两个订单、弱网重试导致重复扣款、重复发送短信。这篇给你5个常见场景的幂等性设计方法。一、什么是幂等性定义同一个请求执行多次结果和执行一次一样。举例查询操作天然幂等查10次结果一样删除操作幂等删除已删除的记录结果还是删除创建操作不幂等创建10次会有10条记录❌扣款操作不幂等扣10次会扣10次钱❌二、5个常见场景详解场景1创建订单防止重复创建场景描述用户点击提交订单按钮因网络慢连点了3次或者前端自动重试导致重复提交。问题创建了3个订单用户投诉客服工作量增加。解决方案前端防护按钮防抖500ms提交后立即禁用按钮显示提交中...后端幂等幂等键 用户ID 购物车ID 时间戳前端生成UUID实现逻辑收到请求时先查询幂等键是否存在Redis或数据库如存在返回原订单号和订单状态HTTP 200如不存在创建订单保存幂等键有效期24小时返回新订单号PRD写法接口名称创建订单 幂等性要求必须支持幂等 幂等键userId_cartId_uuid前端生成UUID 幂等逻辑 1. 收到请求时先查询幂等键是否存在 2. 如存在返回原订单号HTTP 200isDuplicatetrue 3. 如不存在创建订单保存幂等键到Redis有效期24小时 4. 返回新订单号isDuplicatefalse 幂等键有效期24小时 重复请求返回 { code: 200, message: 订单已创建, data: { orderId: ORD20250101001, isDuplicate: true, createdAt: 2025-01-01 10:00:00 } }技术实现示例// 伪代码 function createOrder(userId, cartId, idempotencyKey) { // 1. 检查幂等键 const existingOrder redis.get(idempotencyKey); if (existingOrder) { return { orderId: existingOrder.orderId, isDuplicate: true }; } // 2. 创建订单 const order db.createOrder({ userId, cartId }); // 3. 保存幂等键 redis.set(idempotencyKey, { orderId: order.id }, 24 * 3600); return { orderId: order.id, isDuplicate: false }; }场景2支付扣款防止重复扣款场景描述用户支付时网络超时前端或支付网关自动重试3次导致重复扣款。问题扣了3次钱用户投诉需要退款影响用户体验和公司信誉。解决方案幂等键订单号唯一标识实现逻辑支付前先查询订单支付状态如已支付直接返回成功不调用支付接口如未支付调用支付接口成功后更新订单状态支付接口内部也要做幂等支付网关通常支持PRD写法接口名称支付扣款 幂等性要求必须支持幂等 幂等键订单号orderId 幂等逻辑 1. 支付前先查询订单支付状态 2. 如已支付直接返回成功HTTP 200 3. 如未支付调用支付接口成功后更新订单状态为已支付 4. 支付接口内部也要做幂等使用支付流水号 幂等键有效期永久订单支付状态不可逆 重复支付请求返回 { code: 200, message: 订单已支付, data: { orderId: ORD20250101001, payStatus: paid, paidAt: 2025-01-01 10:00:00 } }注意事项支付接口必须支持幂等使用支付流水号作为幂等键支付成功后订单状态必须立即更新避免并发问题支付失败时不要更新订单状态允许用户重试场景3发送短信防止重复发送场景描述系统故障导致短信发送接口被调用多次或者用户快速点击发送验证码按钮。问题用户收到多条相同短信浪费短信费用影响用户体验。解决方案幂等键手机号 短信模板ID 业务ID如订单号实现逻辑发送前先查询幂等键是否存在如存在且在有效期内如1分钟直接返回成功不发送如不存在或已过期发送短信保存幂等键有效期1分钟返回发送结果PRD写法接口名称发送短信 幂等性要求必须支持幂等 幂等键手机号_模板ID_业务ID如13800138000_VERIFY_ORD001 幂等逻辑 1. 发送前先查询幂等键是否存在 2. 如存在且在有效期内1分钟直接返回成功不发送 3. 如不存在或已过期发送短信保存幂等键到Redis有效期1分钟 4. 返回发送结果 幂等键有效期1分钟防止短时间内重复发送 重复请求返回 { code: 200, message: 短信已发送, data: { isDuplicate: true, sentAt: 2025-01-01 10:00:00 } }扩展场景验证码短信1分钟内相同手机号模板只发送一次通知短信相同业务ID如订单号只发送一次营销短信相同手机号活动ID每天只发送一次场景4库存扣减防止超卖场景描述两个用户同时购买最后1件商品或者秒杀活动时大量并发请求。问题库存变成-1超卖问题用户下单后无法发货影响用户体验。解决方案使用乐观锁版本号机制实现逻辑查询库存时同时获取版本号version扣减库存时使用版本号作为条件UPDATE stock SET qty qty - 1, version version 1 WHERE id ? AND version ?如果更新影响行数0说明版本号不匹配已被其他请求修改返回库存不足如果更新影响行数0说明扣减成功PRD写法接口名称库存扣减 幂等性要求必须支持幂等使用乐观锁 幂等键订单号防止重复扣减 并发控制乐观锁版本号 实现方式 1. 查询库存时返回版本号version 2. 扣减库存时使用版本号作为条件 UPDATE stock SET qty qty - 1, version version 1 WHERE id ? AND version ? AND qty 0 3. 如果更新影响行数0说明版本号不匹配或库存不足返回库存不足 4. 如果更新影响行数0说明扣减成功 用户提示库存不足请选择其他商品 恢复路径无库存已售罄技术实现示例// 伪代码 function deductStock(productId, orderId, quantity) { // 1. 检查幂等键防止重复扣减 const existingDeduction redis.get(deduct:${orderId}); if (existingDeduction) { return { success: true, isDuplicate: true }; } // 2. 查询库存和版本号 const stock db.query(SELECT qty, version FROM stock WHERE id ?, productId); if (stock.qty quantity) { return { success: false, message: 库存不足 }; } // 3. 使用乐观锁扣减库存 const affectedRows db.execute( UPDATE stock SET qty qty - ?, version version 1 WHERE id ? AND version ? AND qty ?, [quantity, productId, stock.version, quantity] ); if (affectedRows 0) { return { success: false, message: 库存不足请重试 }; } // 4. 保存幂等键 redis.set(deduct:${orderId}, { productId, quantity }, 3600); return { success: true, isDuplicate: false }; }注意事项乐观锁适合读多写少的场景性能高如果冲突频繁可以考虑悲观锁SELECT FOR UPDATE秒杀场景建议使用Redis分布式锁或消息队列削峰场景5数据导入防止重复导入场景描述用户上传Excel导入数据因网络问题重复上传或者用户误操作重复点击导入按钮。问题数据重复需要人工清理影响数据准确性。解决方案幂等键文件MD5文件内容唯一标识实现逻辑上传文件后计算文件MD5导入前先查询文件MD5是否已导入如已导入返回该文件已导入和导入记录如未导入执行导入保存文件MD5和导入记录PRD写法接口名称数据导入 幂等性要求必须支持幂等 幂等键文件MD5文件内容唯一标识 幂等逻辑 1. 上传文件后计算文件MD5 2. 导入前先查询文件MD5是否已导入 3. 如已导入返回该文件已导入和导入记录导入时间、导入条数等 4. 如未导入执行导入保存文件MD5和导入记录到数据库 幂等键有效期永久文件内容不变MD5不变 重复导入返回 { code: 200, message: 该文件已导入, data: { isDuplicate: true, importedAt: 2025-01-01 10:00:00, importedCount: 100 } }扩展场景批量导入相同文件MD5只导入一次增量导入相同文件MD5导入时间只导入一次数据更新相同文件MD5业务ID只更新一次三、幂等键设计原则幂等键的设计直接影响幂等性的有效性需要遵循以下原则设计原则唯一性幂等键必须能唯一标识一次业务操作稳定性相同业务操作幂等键必须相同可读性幂等键最好包含业务信息便于排查问题长度限制幂等键长度要适中避免过长影响性能场景幂等键设计生成方式有效期存储位置创建订单userId_cartId_uuid前端生成UUID24小时Redis支付扣款订单号系统生成永久数据库发送短信手机号_模板ID_业务ID系统生成1分钟Redis库存扣减订单号防重复 版本号防并发系统生成订单生命周期Redis 数据库数据导入文件MD5系统计算永久数据库常见错误错误1使用时间戳作为幂等键时间戳会变化无法保证唯一性❌ 错误幂等键 userId timestamp ✅ 正确幂等键 userId cartId uuid错误2幂等键包含随机数随机数每次不同无法保证幂等❌ 错误幂等键 userId random() ✅ 正确幂等键 userId cartId uuid前端生成重试时保持不变错误3幂等键有效期设置过长占用存储空间❌ 错误发送短信幂等键有效期24小时 ✅ 正确发送短信幂等键有效期1分钟业务需求决定错误4幂等键只存Redis不存数据库Redis故障时丢失❌ 错误支付幂等键只存Redis ✅ 正确支付幂等键存数据库永久有效不能丢失四、PRD模板与最佳实践标准PRD模板接口名称创建订单 接口路径POST /api/orders 幂等性要求必须支持幂等 【幂等键设计】 幂等键userId_cartId_uuid 生成方式前端生成UUID重试时保持不变 组成规则{userId}_{cartId}_{uuid} 示例12345_67890_a1b2c3d4-e5f6-7890-abcd-ef1234567890 【幂等逻辑】 1. 收到请求时先查询幂等键是否存在Redis 2. 如存在返回原订单号和订单状态HTTP 200isDuplicatetrue 3. 如不存在执行业务逻辑创建订单 4. 业务逻辑成功后保存幂等键到Redis有效期24小时 5. 返回新订单号isDuplicatefalse 【幂等键存储】 存储位置Redis 有效期24小时 Key格式idempotency:order:{userId}_{cartId}_{uuid} Value格式{orderId: ORD001, status: created, createdAt: 2025-01-01 10:00:00} 【重复请求返回】 HTTP状态码200 响应体 { code: 200, message: 订单已创建, data: { orderId: ORD20250101001, isDuplicate: true, status: created, createdAt: 2025-01-01 10:00:00 } } 【异常处理】 1. Redis故障降级到数据库查询性能较低但保证可用性 2. 幂等键冲突返回请求处理中请稍候防止并发问题 3. 业务逻辑失败不保存幂等键允许重试最佳实践前端生成幂等键前端生成UUID重试时保持不变这样前端重试时可以带上相同的幂等键幂等键包含业务信息幂等键最好包含业务信息如userId、cartId便于排查问题幂等键有效期合理根据业务需求设置有效期不要过长或过短幂等键存储选择临时性幂等键如创建订单存Redis设置过期时间永久性幂等键如支付存数据库永久有效幂等键查询优化使用Redis的SETNX命令保证原子性幂等键降级方案Redis故障时降级到数据库查询保证可用性幂等键监控监控幂等键命中率评估幂等性效果实现检查清单[ ] 幂等键设计合理唯一性、稳定性、可读性[ ] 幂等键生成方式正确前端生成UUID重试时保持不变[ ] 幂等键存储位置正确临时性存Redis永久性存数据库[ ] 幂等键有效期合理根据业务需求设置[ ] 幂等逻辑实现正确先查询存在则返回不存在则执行[ ] 重复请求返回正确HTTP 200isDuplicatetrue[ ] 异常处理完善Redis故障降级、幂等键冲突处理[ ] 前端防抖实现按钮防抖提交后禁用[ ] 日志记录完善记录幂等键、请求参数、处理结果[ ] 监控告警配置监控幂等键命中率、异常情况五、常见错误与陷阱错误1幂等键设计不合理问题使用时间戳作为幂等键导致每次请求幂等键都不同无法保证幂等性。❌ 错误示例 幂等键 userId timestamp 问题时间戳每次不同无法保证幂等性 ✅ 正确示例 幂等键 userId cartId uuid前端生成重试时保持不变错误2幂等键只存Redis不存数据库问题Redis故障时幂等键丢失导致重复操作。❌ 错误示例 支付幂等键只存Redis 问题Redis故障时幂等键丢失可能导致重复扣款 ✅ 正确示例 支付幂等键存数据库永久有效不能丢失 临时性幂等键如创建订单可以只存Redis错误3幂等键有效期设置不合理问题幂等键有效期过长占用存储空间有效期过短导致正常重试失败。❌ 错误示例 发送短信幂等键有效期24小时过长占用空间 创建订单幂等键有效期1分钟过短正常重试可能失败 ✅ 正确示例 发送短信幂等键有效期1分钟业务需求决定 创建订单幂等键有效期24小时业务需求决定错误4幂等逻辑实现不正确问题先执行业务逻辑再保存幂等键导致并发时重复执行。❌ 错误示例 1. 执行业务逻辑创建订单 2. 保存幂等键 问题并发时两个请求都执行了业务逻辑 ✅ 正确示例 1. 查询幂等键是否存在 2. 如存在返回原结果 3. 如不存在执行业务逻辑保存幂等键使用SETNX保证原子性错误5重复请求返回错误状态码问题重复请求返回4xx错误导致前端认为请求失败继续重试。❌ 错误示例 重复请求返回 HTTP 400 Bad Request 问题前端认为请求失败继续重试导致无限循环 ✅ 正确示例 重复请求返回 HTTP 200 OKisDuplicatetrue 前端根据isDuplicate判断是否重复不再重试错误6前端没有防抖处理问题用户快速点击按钮发送多个请求虽然后端做了幂等但浪费资源。❌ 错误示例 前端没有防抖用户快速点击发送多个请求 问题虽然后端做了幂等但浪费资源增加服务器压力 ✅ 正确示例 前端按钮防抖500ms提交后立即禁用按钮显示提交中... 减少不必要的请求提升用户体验六、FAQQ1幂等键由前端生成还是后端生成答建议前端生成如UUID这样前端重试时可以带上相同的幂等键。如果后端生成前端重试时无法获取相同的幂等键导致幂等性失效。前端生成的优势前端重试时可以带上相同的幂等键减少后端压力不需要生成幂等键更好的用户体验前端可以控制重试逻辑Q2幂等键存在哪里答根据业务需求选择存储位置临时性幂等键如创建订单存Redis设置过期时间性能高永久性幂等键如支付存数据库永久有效不能丢失混合方案Redis 数据库Redis作为缓存数据库作为持久化Q3所有接口都要做幂等吗答不是。需要做幂等的接口创建操作创建订单、创建用户、创建商品等修改操作支付扣款、库存扣减、积分扣减等发送操作发送短信、发送邮件、发送推送等不需要做幂等的接口查询操作查询订单、查询用户、查询商品等天然幂等删除操作删除订单、删除用户等天然幂等删除已删除的记录结果还是删除Q4幂等键和分布式锁有什么区别答幂等键和分布式锁是两种不同的机制幂等键防止重复操作允许并发请求但只执行一次分布式锁防止并发操作同一时间只允许一个请求执行使用场景幂等键适合创建订单、支付扣款等场景允许并发但只执行一次分布式锁适合库存扣减、秒杀等场景不允许并发必须串行执行Q5幂等键冲突了怎么办答幂等键冲突是正常情况表示重复请求应该返回原结果而不是报错。如果使用Redis的SETNX命令可以保证原子性避免并发问题。Q6Redis故障时幂等性怎么保证答需要降级方案临时性幂等键降级到数据库查询性能较低但保证可用性永久性幂等键直接存数据库不依赖Redis混合方案Redis 数据库Redis作为缓存数据库作为持久化Q7幂等键有效期怎么设置答根据业务需求设置创建订单24小时订单创建后24小时内不会重复创建发送短信1分钟1分钟内不会重复发送支付扣款永久支付状态不可逆数据导入永久文件内容不变MD5不变Q8如何监控幂等性效果答监控以下指标幂等键命中率重复请求占比评估幂等性效果幂等键存储量Redis/数据库中的幂等键数量评估存储压力幂等键查询耗时查询幂等键的耗时评估性能影响重复操作次数没有幂等键的重复操作次数评估业务影响工具入口生成幂等性设计思维导图