現(xiàn)在架構(gòu)是php+mysql,在大并發(fā)下根本抗不住，加了redis緩存只能解決部分問(wèn)題，還有很多實(shí)時(shí)的數(shù)據(jù)不能緩存起來(lái)的，有沒(méi)有一個(gè)好的解決方案呢。打算拆分業(yè)務(wù)了，但是最終還是會(huì)遇到mysql扛不住的問(wèn)題，煩惱
10 回答
鳳凰求蠱
TA貢獻(xiàn)1825條經(jīng)驗(yàn) 獲得超4個(gè)贊
MySQL可以做讀寫(xiě)分離，一主多從，寫(xiě)主庫(kù)讀從庫(kù)。
如果讀寫(xiě)分離都撐不住，通常瓶頸在主庫(kù)上，就要考慮做水平拆分（而不是按業(yè)務(wù)拆分）了。
守著一只汪
TA貢獻(xiàn)1872條經(jīng)驗(yàn) 獲得超4個(gè)贊
為什么不先把這些實(shí)時(shí)數(shù)據(jù)保存在redis中，然后找個(gè)計(jì)算機(jī)空余的時(shí)間再同步到mysql中，這樣會(huì)好點(diǎn)吧
墨色風(fēng)雨
TA貢獻(xiàn)1853條經(jīng)驗(yàn) 獲得超6個(gè)贊
簡(jiǎn)單的關(guān)系型數(shù)據(jù)也是可以放在redis中的。mysql始終都是抗不住的。如果流量很大，分拆出很大的那一部分單獨(dú)優(yōu)化也是比較好的。
一只名叫tom的貓
TA貢獻(xiàn)1906條經(jīng)驗(yàn) 獲得超3個(gè)贊
Mysql的架構(gòu)方式也是很多的嘛~
讀寫(xiě)分離~
一主多從
根據(jù)業(yè)務(wù)情況垂直拆分
水平拆分。
表不經(jīng)常改，可以使用SqlCache
優(yōu)化數(shù)據(jù)庫(kù)配置，如innodb buffer等
redis也是個(gè)不錯(cuò)的緩存手段。
實(shí)時(shí)數(shù)據(jù)也是可以通過(guò)redis來(lái)實(shí)現(xiàn)啊，它并不僅僅是個(gè)緩存。
數(shù)據(jù)實(shí)時(shí)性要求不高的地方，也可以考慮中間件，延遲更新、批量處理等。
方式很多吧，寫(xiě)的比較亂，真正的使用還是要結(jié)合你的實(shí)際項(xiàng)目需求。
蕭十郎
TA貢獻(xiàn)1815條經(jīng)驗(yàn) 獲得超13個(gè)贊
這個(gè)問(wèn)題太籠統(tǒng)了。。你說(shuō)扛不住，那阿里巴巴是怎么做的。
數(shù)據(jù)庫(kù)拆分+緩存+異步處理。。。大并發(fā)，有效請(qǐng)求是多少呢。
慕姐8265434
TA貢獻(xiàn)1813條經(jīng)驗(yàn) 獲得超2個(gè)贊
多大的并發(fā)？多大的數(shù)據(jù)量？說(shuō)不定只是sql寫(xiě)的不夠優(yōu)化導(dǎo)致的
拉莫斯之舞
TA貢獻(xiàn)1820條經(jīng)驗(yàn) 獲得超10個(gè)贊
- 數(shù)據(jù)庫(kù)做好索引
- 頻繁寫(xiě)入的數(shù)據(jù)建議加消息隊(duì)列(可以減輕大部分?jǐn)?shù)據(jù)庫(kù)壓力，讓SQL負(fù)載趨于平穩(wěn))
- php的話(huà)FPM配置也優(yōu)化一下
- 10 回答
- 0 關(guān)注
- 575 瀏覽
添加回答
舉報(bào)
0/150
提交
取消