|

下单成功后,要发短信、加积分、发优惠券、通知物流……如果一件件同步串着做,用户得干等到全部做完;更糟的是,只要积分服务挂了,整个下单就跟着失败——明明钱已经付了。 消息队列(MQ)就是用来拆掉这种"强耦合 + 同步等待"的。这篇讲清楚:MQ

一个用得好好的列表页或数据看板,数据一多、时间周期一拉长,就开始转圈、甚至超时。第一反应往往是"加个缓存挡一下",但很多时候根因压根不在缓存,而在查询本身 —— 它扫了太多行。 这篇把治慢查询最该懂的几件事讲清楚:怎么定位慢在哪、索引为什么

"慢了?加个缓存"——几乎是性能优化的第一反应。但缓存加完,新的麻烦才开始:穿透、击穿、雪崩、缓存和数据库对不上……这些坑大多是线上出过事才认识的。 这篇把缓存最该懂的几件事讲清楚:为什么快、怎么用、用在哪、三大坑怎么防,以及最难的——一致

后端要存数据、搭基建,选型怎么定?这篇分两个角度讲:传统业务(什么数据用什么存),和 AI 大模型基建(LLM 应用多出来的那一层)。各自怎么选、怎么搭、有哪些开源方案。 --- 第一部分 · 传统业务:什么数据用什么存 一、选型前,先想清

后台系统里"谁能看哪些数据、改哪些东西"的权限,怎么设计才能既细又不乱?这篇按"从简单到复杂"四个台阶讲清楚,配一个能跑的 demo。 一、两层权限,先别混 写代码前先分清,不然会越想越乱: - 云资源权限:谁能操作服务器、数据库、对象存储

给项目加登录,你大概率纠结过这些:个人博客想接"用 GitHub 登录"怎么搞?公司好几个内部系统,能不能登录一次全通?自己做 App 要支持手机号 + 微信 + 邮箱,用户体系怎么设计才不乱?到底是自己搭,还是直接用现成的? 这篇就是一份

平时写前端 / 全栈,服务端鉴权我一直是"会用但说不清"。这篇是我把它从头啃明白的笔记,基于公开标准(OAuth 2.0 / RFC 6749、JWT / RFC 7519),配一个能跑的最小 demo。如果你也被 JWT、OAuth、to

一篇关于把自己跑了五年的旧博客，重构成 Next.js 全栈新版本的折腾记录。涉及 2G 内存阿里云 ECS、宝塔多站点共存、Let's Encrypt 自动续期、国内 GitHub OAuth 抽风、数据零丢失迁移…如果你也在折腾自己的小

GPT 相关内容已经满天飞了，虽然有很多说法说是会代替程序员，个人认为还是为时尚早，目前前端方向的，可以看看 AI+ 方向，毕竟纯对话交互形式，是不能满足垂类领域业务需求的，涉及到交互就少不了前端，还能继续搬砖！ 另外有了 GPT 写代码效

转眼已经是老阿姨了，还在程序员圈混，只求身体健康，保住头发，早点退休🙏🌸🕊️