搜索结果： "容量规划" (8)
全链路压测与容量规划
单接口压八万、全链路压八百——每个组件的容量账都好算，拼在一起才是真相。影子库隔离压测数据，容量公式加冗余系数，短板决定上限，压测报告要给每层一个结论。
分片规划：建索引时定死的那道数学题
随手 5 个分片，一年后被一堆小分片吃光内存；随手 1 个分片，数据涨了想拆拆不动。单分片 10 到 50GB 黄金区间、未来一年的扩容预留、rollover 滚动索引——分片数在建索引那一刻定生死。
分片治理：水位、倾斜与再平衡
拆完不是终点，是另一场长期管理的开始：每个分片的容量水位涨到哪儿了？数据是不是悄悄倾斜了？三年后的容量今天规划够不够？分片系统的健康不靠某次重构，靠一套日日看、月月盘的治理机制。
单表两亿行：一次改了八小时的 DDL，逼出了分库分表
给一张两亿行的订单表加字段，gh-ost 跑了八小时还差三个槽——dba 说这不是慢，是这张表已经不配再被改了。索引膨胀、磁盘水位、备份窗口全面告急，单库的天花板不是猜出来的，是一次次撞出来的。什么时候真的需要分库分表，这篇先把决定时刻讲清楚。
收官：稳定性体系全景图
二十篇走到收官。从一次爆单雪崩出发，装了限流、熔断、降级、隔离、超时五道闸，配了重试纪律、自适应、全链路压测三套方法论，最后归拢成一张全景图：流量进来怎么挡、故障起来怎么断、用户侧怎么保、事后怎么复盘。稳定性没有银弹，只有纵深。
多级限流：三层防线的额度分配
网关、应用、数据库各一道闸，但阈值不是随手拍——外层要略宽于内层，拒绝的对象各有分工：网关挡恶意，应用管配额，数据库做保险丝。额度分配错一层，整条防线就互相打架。
命中率：缓存体系的核心指标
缓存做得好不好，最终就浓缩成一个数字：命中率。它不是好看虚荣的仪表盘——每一次未命中都是一次回源、一笔 DB 开销、一段更高的 RT。命中率偏低，要从容量、TTL、访问模式三条线上找病根，而不是盲目加内存。
键设计与容量规划：数据进 Redis 之后的工程问题
键名是键值数据库的全部界面。聊聊键命名规范、容量估算方法和大小 value 治理，把数据塞进 Redis 之前的工程问题一次讲清。