北京
一个列表请求，会触发240～470次MongoDB查询。这不是压测造出来的极端值，是读见（BestBlogs 3.0 中文版）内测期间真实发生的页面卡顿来源。
作者把整条请求链路摊开看了一遍：Next.js → Nginx → API → Redis/MongoDB。卡的地方不止一处，但最扎眼的是数据库往返次数——列表里逐项补充数据，形成了典型的N+1查询。
要点一：把N+1改成批量读
专栏列表请求原本要打240～470次MongoDB查询。改法是批量读取，再配合索引优化，数据库往返次数直接降到个位数。这一步是整轮优化里收益最直接的。
要点二：43%的跨机房流量要挪窝
排查中发现有43%的流量在跨机房跑。作者的处理是把主要入口迁到与数据节点同机房的位置，让在线API尽量靠近数据库，慢节点保留为备用。跨机房延迟和同机房延迟不是一个量级，这部分流量挪回来，等待时间自然缩水。
要点三：重复读加缓存，串行改并行
身份验证这类高频读操作，每次请求都要重复走一遍。作者给它加了缓存，同时把可以独立的请求从串行改成并行执行，减少冗余等待与串行阻塞，提高资源利用率。
要点四：观测体系补上
优化之外，作者基于阿里云ARMS搭了全链路观测体系。性能问题最怕的是看不见——链路上一段慢，没有观测就只能靠猜。
三项改动落地后，服务端取数中位耗时下降约81%。从240～470次查询到个位数往返，从43%跨机房流量到同机房就近访问，这套组合拳没有一项是黑科技，全是把链路一段段拆开、把浪费一段段掐掉。
对做后端的人来说，这份排查记录的价值在于顺序：先看请求链路，再定位往返次数，最后才谈缓存和并行。顺序反了，优化就容易变成拍脑袋。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
