-
架构设计方法论:先找瓶颈,再谈方案
回头看这个活动商品与订单系统,它并不是一开始就需要复杂架构。最早只有商品页、下单接口和一张订单表。后来商品详情访问量上来了,于是加缓存;订单表变大了,于是优化索引、冷热分离;...
-
可观测性和容量规划:看不见的问题,最后都会变成事故
用户说页面慢,客服说订单偶尔失败,运营说活动转化掉了。开发打开服务器看 CPU,好像还行;看数据库,好像也没完全打满;翻日志,日志很多,但不知道该搜什么。最后大家只能在群里互...
-
系统可用性:故障一定会发生,关键是怎么收住
有一次团队以为自己有备份,直到真的需要恢复。备份文件确实存在,但恢复脚本很久没跑过;恢复出来的数据还要校验;应用连接怎么切,缓存怎么处理,消息积压怎么补,都没有完整演练。那一...
-
热点和突发流量:真正难的是不均匀
活动系统最怕的,不一定是全站流量都高。更麻烦的是一个商品突然爆了。首页总 QPS 看起来还能接受,但某个商品详情页、某条库存记录、某个活动资格接口被集中访问。平均值很好看,局...
-
接口和服务高并发:别让重试把系统拖垮
活动高峰时,库存服务先慢了。订单服务调用库存服务,原本 100ms 返回,现在变成 2 秒。订单服务等不住,开始超时;客户端看到失败,又发起重试;订单服务自己也配置了重试;库...
-
分布式一致性:系统越拆,正确性越贵
系统没拆开之前,下单这件事很简单。一个数据库事务里,创建订单、扣库存、核销优惠券。提交成功就是成功,回滚失败就是失败,边界很清楚。后来系统拆开了。订单是订单服务,库存是库存服...
-
消息队列不是银弹,它只是把压力换了一个地方
活动开始后,下单接口最先扛不住。用户点击下单,接口里要校验活动、检查库存、创建订单、扣优惠券、发通知、更新报表。平时这条链路没问题,活动流量一上来,接口开始超时。这时候很多人...
-
海量数据存储:数据多了以后,系统会先在哪里变慢
活动系统最开始只有几万条订单,大家不会认真讨论“数据生命周期”。后台想查就查,运营想导出就导出,日志临时塞数据库也没人觉得有问题。直到半年后,订单表越来越大,报表越来越慢,备...
-
数据库高并发问题:慢的不只是 SQL
活动系统运行了几个月后,最先被抱怨的不是下单,而是后台订单列表。运营同学按时间筛选订单,页面从 200ms 变成 3 秒,再后来变成 8 秒。开发第一反应通常是:SQL 慢了...
-
高并发系统里,缓存到底在保护谁?
活动刚开始的前十分钟,商品详情页先慢了。下单接口还没到峰值,支付也没出问题,但数据库 CPU 已经开始往上冲。排查后发现,大量请求都在查同一个商品详情、活动配置和库存展示。每...
专题 / 9 篇
MES现场落地手记
做 MES 系统,最怕一开始就关在会议室里画大架构图。真正的问题往往藏在产线、设备、点位表、扫码枪、测试机和现场网络里。这个系列会从现场落地视角,拆开 MES 架构该怎么做。
专题 / 11 篇
高并发海量数据系统架构
这个系列会用一个活动商品与订单系统作为贯穿案例,从缓存、数据库、消息队列、一致性、服务保护、热点流量、可用性和可观测性几个角度,讲清楚高并发系统真正要做的工程取舍。
专题 / 10 篇
一个技术负责人眼里的软件团队
带软件团队最难的往往不是把任务分下去,而是让团队对目标、节奏、质量和风险有同一套理解。这个系列会从技术负责人的视角,聊聊小团队真实交付里的那些麻烦事。
专题 / 9 篇
带团队以后,我才明白的事
带团队以后才会发现,技术负责人面对的不是简单的分任务和催进度,而是目标、节奏、质量、风险和人的状态。这个系列会聊一些真实项目里慢慢想明白的事。
专题 / 12 篇
公司把 AI 用起来
企业 AI 真正难的,往往不是选模型或搭 Agent,而是让负责人亲自使用,让员工愿意改变工作方式,再把流程和数据一点点整理成 AI 能够调用的企业能力,而不是停留在一场漂亮的演示里。
Latest