1. 第一原理：数据库是唯一的“硬约束”

在整个请求链路中（Nginx -> 应用服务器 -> 缓存 -> 数据库），应用服务器是无状态的，可以无限横向扩展；缓存是易失的，只负责加速。只有数据库是有状态的、物理落盘的、具备 ACID 约束的。

• 核心结论：系统的支撑上限，最终取决于数据库的 IOPS（每秒输入输出量） 和 锁竞争频率。如果这个基础不牢靠，应用层搞再多微服务也只是“空中楼阁”。

2. “带宽”与“吞吐”的辩证法

“带宽有多大，并发就有多大”，假设你的数据库并发上限是无限大，任何sql查询的执行时间都不超过0.1ns，那么可以近似的认为你的带宽有多大，并发数就有多大

假设服务器带宽200M，每个请求1kb，那就是QPS=25600，这个数据是非常夸张的，可以认为服务器的带宽上下行流量都是压力爆棚

且达到上限了（眨眼时间7680 个请求被处理完成，即流量从到入口带宽的nginx到应用服务再到数据库在由应用处理逻辑返回到nginx到用户设备），当然这不可能

因为网卡io，磁盘io，cpu io，ram io，都要花费时间成本，其次，数据库也不可能那么快，数据库完全装内存里都不可能。

3. 性能漏斗模型：数据库是最后的瓶颈

所有的架构手段（前后端分离、CDN、服务治理、分布式事务、削峰、缓存、异步、限流、等等诸多技术）本质上都是一个“漏斗”，目的是为了过滤掉 90% 的无效请求，只让必须的数据写入请求到达数据库。

• 牢靠的基础意味着：当那 10% 的核心请求到达数据库时，数据库能以微秒级的速度完成闭环，而不产生积压。
• 反面教材：基础不牢（没索引、大事务锁表），一个请求卡住 1 秒，瞬间就会产生排队效应，把上游所有的带宽和连接数全部耗尽，这种情况， 前面得分哪怕是99分，最后的基数是0，得分也还是0