與哪些因素有關(guān)

1. 后端服務(wù)器集群節(jié)點(diǎn)數(shù)量，數(shù)量越多，QPS越高
2. 后端服務(wù)器節(jié)點(diǎn)的運(yùn)行配置：運(yùn)行內(nèi)存、Cpu核數(shù)等等，硬件資源決定單節(jié)點(diǎn)處理能力
3. 接口本身做的事情

a. 做的事情多耗時(shí)長(zhǎng)（預(yù)估QPS會(huì)相對(duì)應(yīng)低）

b. 做的事情少耗時(shí)短（預(yù)估QPS會(huì)相對(duì)應(yīng)高）

4.系統(tǒng)架構(gòu)

a. 完善的流量負(fù)載均衡架構(gòu)，實(shí)現(xiàn)流量的有效分發(fā)和負(fù)載均衡，避免成為QPS瓶頸

b. 緩存技術(shù)，減輕數(shù)據(jù)庫(kù)的壓力，避免數(shù)據(jù)庫(kù)成為QPS瓶頸

c. 集群模式的數(shù)據(jù)庫(kù)，避免數(shù)據(jù)庫(kù)成為QPS瓶頸

d. 靜態(tài)資源通過(guò)CDN加速，避免成為QPS瓶頸

如何預(yù)估？

首先需要知道一個(gè)請(qǐng)求處理完畢的時(shí)間（這個(gè)請(qǐng)求里可能做很多事情，但是這個(gè)我們暫時(shí)不管），一個(gè)請(qǐng)求處理完畢的時(shí)間我們是可以知道的。（我們?nèi)フ{(diào)用這個(gè)接口多次得到平均值即可）

理論計(jì)算公式

1. QPS（單節(jié)點(diǎn)） = 線程數(shù)（如 Tomcat 線程池）/ 平均請(qǐng)求處理時(shí)間（秒）

a. 例如：若線程池大小為 200，單個(gè)請(qǐng)求處理時(shí)間為 50ms（0.05秒）

ⅰ. SprigBoot 默認(rèn)使用Tomcat，而Tomcat線程池的最大線程數(shù)就是200，所以在默認(rèn)配置下，SprigBoot 應(yīng)用可以并發(fā)處理 200 請(qǐng)求

則 QPS（單節(jié)點(diǎn)） = 200 / 0.05= 4000

2.QPS（集群）= QPS（單節(jié)點(diǎn)）* 節(jié)點(diǎn)數(shù)

例如集群有4個(gè)節(jié)點(diǎn)，則 QPS（集群）= 4000 * 4 = 16000

單個(gè)請(qǐng)求處理的時(shí)間是受到

“系統(tǒng)架構(gòu)”、“接口本身做的事情”“后端服務(wù)器節(jié)點(diǎn)運(yùn)行配置”“后端服務(wù)器節(jié)點(diǎn)數(shù)量”

等等因素共同影響的 但這實(shí)際上是一個(gè)近似已知值（我們?nèi)フ{(diào)用這個(gè)接口多次得到平均值即可）

QPS瓶頸

我們想想QPS的瓶頸在哪？其實(shí)很多方面，就像前面說(shuō)的QPS與哪些因素有關(guān)

但一般來(lái)說(shuō) QPS 最可能的瓶頸在于數(shù)據(jù)庫(kù) (例如MySQL)

應(yīng)該說(shuō)多少Q(mào)PS

面試官如果問(wèn)接口的QPS多少，如何回答比較合理？

首先我們一定可以知道這個(gè)接口處理的平均耗時(shí)是多久？假設(shè)是200ms

一些項(xiàng)目背景暫時(shí)假設(shè)為如下情況，因個(gè)人而定

• 假設(shè)有 n 臺(tái)后端服務(wù)器
• 假設(shè)后端服務(wù)器的配置是 2核4G內(nèi)存
• 假設(shè)接口做了一些事情
• 假設(shè)對(duì)于一些系統(tǒng)架構(gòu)上，做了一些優(yōu)化、或者沒(méi)有做優(yōu)化

那么

1. QPS（單節(jié)點(diǎn)） = 線程數(shù)（如 Tomcat 線程池）/ 平均請(qǐng)求處理時(shí)間（秒）

a. 若線程池大小為 200，單個(gè)請(qǐng)求處理時(shí)間為 100ms（0.01秒）

b. 則 QPS（單節(jié)點(diǎn)） = 200 / 0.01= 2000

2.QPS（集群）= QPS（單節(jié)點(diǎn)）* 節(jié)點(diǎn)數(shù) = 2000 * n

沒(méi)有壓測(cè)的情況下，我們就可以說(shuō)這個(gè)理論計(jì)算得出的值。但是理論僅僅是理論

如果有壓測(cè)，那其實(shí)是另外更好的一種情況，因?yàn)閴簻y(cè)得到的數(shù)據(jù)往往是更加準(zhǔn)確的。

例如壓測(cè)過(guò)程：使用 JMeter 進(jìn)行了壓力測(cè)試，逐步增加并發(fā)線程數(shù)，直到接口的響應(yīng)時(shí)間超過(guò)預(yù)設(shè)閾值（如 200ms）或錯(cuò)誤率超過(guò) 1%。此時(shí)就可以知道接口可以抗住的QPS

示例：

面試官：“你在項(xiàng)目中負(fù)責(zé)的訂單查詢接口，QPS 是多少？”你的回答：“訂單查詢接口的 QPS 在‘雙11’大促期間峰值達(dá)到 5,000，日常平均 QPS 約為 1,200。我們通過(guò)以下步驟得出這一數(shù)據(jù)：

1. 壓測(cè)階段：JMeter 進(jìn)行了壓力測(cè)試，逐步增加并發(fā)線程數(shù)，發(fā)現(xiàn)當(dāng) QPS 達(dá)到 2,000 時(shí)，響應(yīng)時(shí)間達(dá)到300ms。
2. 瓶頸分析：通過(guò) Arthas 追蹤發(fā)現(xiàn)，80% 的請(qǐng)求耗時(shí)在數(shù)據(jù)庫(kù)查詢上。
3. 優(yōu)化措施(僅為舉例，具體情況依據(jù)個(gè)人而定)：

○ 引入 Redis 緩存熱點(diǎn)商品數(shù)據(jù)，緩存命中率提升至 90%；

○ 對(duì)訂單表按用戶 ID 進(jìn)行分庫(kù)分表，單表數(shù)據(jù)量從 1 億減少到 1 千萬(wàn)；

○ 將日志記錄改為異步寫(xiě)入 Kafka，減少主線程耗時(shí)。

4.優(yōu)化結(jié)果：最終壓測(cè) QPS 提升到 5,000，且響應(yīng)時(shí)間穩(wěn)定在 80ms 以內(nèi)。此外，線上監(jiān)控顯示，實(shí)際高峰期的 QPS 與壓測(cè)結(jié)果基本一致，系統(tǒng)未出現(xiàn)超時(shí)或宕機(jī)?！?/span>