边缘优先：把数据库放到离用户最近的地方

传统架构里，一个渲染请求往往要横跨半个地球去访问中心数据库。我们把这件事算过一遍账：一次跨区往返大约 150–200ms，而这个成本会在一次页面渲染中被乘以若干倍——查用户、查文章、查分类、查评论，四次往返就是 600ms 以上。

边缘数据库改变了这个算式。当计算和数据都在同一个机房时，单次查询往往只有个位数毫秒。真正需要重新思考的，是数据一致性与写入路径：读多写少的博客场景几乎立刻受益，而写操作仍然要回到主库。

实践中有三点值得注意。第一，把「读」和「写」的路径分开设计，读路径尽量只依赖就近副本。第二，不要在渲染过程中做 N+1 查询，边缘的优势会被查询次数吃掉。第三，为跨区写准备好重试与幂等，网络抖动是常态而不是异常。

这套架构并不适合所有场景。强一致的事务、复杂的多表聚合、需要长连接的实时协作，仍然适合放在中心。但对内容型站点来说，边缘优先几乎总是更优解。