首页
沸点
课程
数据标注
HOT
AI Coding
更多
直播
活动
APP
插件
直播
活动
APP
插件
搜索历史
清空
创作者中心
写文章
发沸点
写笔记
写代码
草稿箱
创作灵感
查看更多
登录
注册
确定删除此收藏集吗
删除后此收藏集将被移除
取消
确定删除
确定删除此文章吗
删除后此文章将被从当前收藏集中移除
取消
确定删除
编辑收藏集
名称:
描述:
0
/100
公开
当其他人关注此收藏集后不可再更改为隐私
隐私
仅自己可见此收藏集
取消
确定
问题解决方案
订阅
meiy
更多收藏集
微信扫码分享
微信
新浪微博
QQ
6篇文章 · 0订阅
这样做的幂等也太全了吧
在做票务下单的时候,肯定要做幂等和放重复的,防止用户操作出现重复的订单和重复支付等问题,于是有了本篇文章。幂等设计需分层防护,从接口层到数据层形成完整防线。推荐以下方案:
Spring事件机制:解耦利器与实战
Spring事件机制:解耦利器与实战 一、为什么需要事件机制? 在传统的业务开发中,我们经常会遇到这样的场景: 这种方式存在严重问题: 强耦合:OrderService依赖太多服务 难维护:新增业务需
分库分表正在被淘汰
如果我们现在在搭建新的业务架构,如果说你们未来的业务数据量会达到千万 或者上亿的级别 还在一股脑的使用分库分表的架构,那么你们的技术负责人真的就应该提前退休了
工作十年,谈谈我的100W QPS高可用架构和系统设计经验
高可用系统设计是每个技术人必须掌握的硬核技能,但很多人只会堆功能,忽视了系统稳定性的重要性。 本文从研发规范、应用服务、存储、产品、运维部署、异常应急六大层面,手把手教你如何设计一个高可用系统,让你的
Spring状态机深度解析:从入门到生产实战
Spring状态机深度解析:从入门到生产实战 一、状态机是什么?为什么要用它? 想象一下订单系统:用户下单后,订单会经历"待支付→已支付→待发货→已发货→已完成"等一系列状态变化。如果在代码里用if-
企业级CompletableFuture并行化完整方案,接口从10s到100ms
一、企业级 CompletableFuture 核心使用原则(先定规范,再谈场景) 在进入具体场景前,先明确企业落地时必须遵守的核心原则(这是“合理使用”的前提): 原则 企业级要求 落地说明 线程池