假如數(shù)據(jù)庫(kù)連接數(shù)只有1000，怎么處理100萬的并發(fā)量呢？不能用負(fù)載均衡，有別的辦法嗎？

1. 緩存，就可以不走數(shù)據(jù)庫(kù)
2. 消息隊(duì)列，可以限制到數(shù)據(jù)庫(kù)的數(shù)量，減緩壓力
3. 連接池管理，復(fù)用連接，等待管理。
4. 數(shù)據(jù)庫(kù)優(yōu)化，讀寫優(yōu)化，提升數(shù)據(jù)庫(kù)的效率。

1、用redis將高頻查詢數(shù)據(jù)存儲(chǔ)。提高查詢速度
2、mysql做主從
3、增刪改加隊(duì)列
4、切表分庫(kù)
5、swoole解決并發(fā)
6、有必要時(shí)用grpc做服務(wù)治理
7、微服務(wù)
8、代碼分割
。。。。等等等等

又是一個(gè)面試造核彈，上班擰螺絲的過程

數(shù)據(jù)庫(kù)的話跟負(fù)載均衡真沒關(guān)系。首先是消息隊(duì)列，數(shù)據(jù)庫(kù)主從架構(gòu)。只是100萬并發(fā)我覺得通常講的是網(wǎng)絡(luò)訪問的事情而不是數(shù)據(jù)庫(kù)連接數(shù)。100萬并發(fā)不用負(fù)載均衡我還真不知道你單臺(tái)服務(wù)器如何承受這訪問量。即使是帶寬調(diào)的足夠大，我覺得用戶體驗(yàn)也不會(huì)很高。

空間換時(shí)間,把常用的表都緩存到內(nèi)存中.

首先糾正你一下，負(fù)載均衡和你這個(gè)問題沒有關(guān)系。其次是你這個(gè)問題也挺有意思的，因?yàn)檫@種場(chǎng)景很難出現(xiàn)。不過，我還是假裝你真的遇到了這種極度不平衡的場(chǎng)景。
1.用好redis，將大量請(qǐng)求工具攔截在在redis層
2.引入連接池中間件。連接池和mysql是長(zhǎng)連接，你不用擔(dān)心頻繁握手帶來的性能問題。程序從連接池中取出一個(gè)鏈接句柄，用完后會(huì)迅速放回去?？梢缘謸跻魂噧?。
除此以外，我也不知道還有什么銀彈了