用 CTE 递归查询实现树形评论的分页展开
树形评论的分页是论坛和社区类产品里最容易被低估的一块。表面需求是"一页显示 20 条评论",实际难点在于:评论是嵌套的,一条根评论下面可能挂着十几层回复,你既不能让某一层的子回复被分页切口拦腰截断,也不能因为要算好层级导致每次翻页都全表扫描。很多项目最后退化成一次性把整棵树的评论全部查出来丢给前端拼,帖子一火,接口就是几百毫秒起步,内存里堆着上万行 JSON
树形评论的分页是论坛和社区类产品里最容易被低估的一块。表面需求是"一页显示 20 条评论",实际难点在于:评论是嵌套的,一条根评论下面可能挂着十几层回复,你既不能让某一层的子回复被分页切口拦腰截断,也不能因为要算好层级导致每次翻页都全表扫描。很多项目最后退化成一次性把整棵树的评论全部查出来丢给前端拼,帖子一火,接口就是几百毫秒起步,内存里堆着上万行 JSON
订单超时关单、优惠券到期提醒、15 分钟未支付自动取消、消息重投退避——这类「到点才执行」的需求,用定时任务扫数据库是最容易想到的方案,但只要表一大、并发一高,就会出现扫全表慢、多个实例重复执行、任务取到一半进程挂掉导致丢失等问题。Redis 的 ZSET(sorted set)天生适合做这件事:score 存到期时间戳,member 存任务内容,按 sco
排行榜、Top N、分组取最新一条——这类需求用窗口函数写起来最舒服。但老代码里常见的是自连接或子查询写法,数据量一上来就慢到不可用。 一个典型场景 每门课程要取分数最高的前 3 名学生。自连接写法: SELECT s.* FROM sco
调用第三方接口,网络抖一下很正常。但"失败就重试"如果写得随意,反而会把对方打挂、把自己的线程占满。一个可靠的重试客户端要同时满足:会退让、有边界、可取消。 最容易踩的坑 for i := 0; i < 3; i++ { resp,
限流是后端最常用的自我保护手段。固定窗口实现简单但有临界突刺,滑动窗口更平滑但开销大。折中方案是令牌桶:既允许合理突发,又能扛住持续高压。 为什么不用固定窗口 固定窗口(每秒计数)的问题在边界:第 0.9 秒来 100 个请求,第 1.1