數(shù)據(jù)庫前加一個(gè)消息隊(duì)列，是不是通用做法？

ruifengzhangyi

連接池直接操作db是一個(gè)方法，但是用消息隊(duì)列是不是更好？

cokeboL

連接池是車道數(shù)量，單個(gè)數(shù)據(jù)庫連接上的消息隊(duì)列是每個(gè)車道上的車的數(shù)量，一個(gè)是載體，一個(gè)是載荷，這倆沒有可比性。

ruifengzhangyi

你的意思是，連接池+消息隊(duì)列，是正解。但是我接觸過的公司往往只選擇其一。

ruifengzhangyi

你的意思是，連接池+消息隊(duì)列是正解

ruifengzhangyi

回復(fù) 2# cokeboL

你的意思是，連接池+消息隊(duì)列才是正解咯

cokeboL

回復(fù) 5# ruifengzhangyi


多數(shù)語言是這樣的，需要注意的問題就是需求對(duì)數(shù)據(jù)庫操作是否有時(shí)序要求，如果有就需要把數(shù)據(jù)庫操作和連接池中item的對(duì)應(yīng)方式做統(tǒng)一映射，如果沒有時(shí)序要求，就無所謂了
golang這種，就不需要加隊(duì)列，很舒坦。

shang2010

回復(fù) 3# ruifengzhangyi

臥龍鳳雛得一，可安天下。不知道兩個(gè)在一起，會(huì)不會(huì)內(nèi)掐

sxcong

一般是緩存和數(shù)據(jù)搭配
根據(jù)自己的情況，把查詢出的結(jié)果放在緩存里，程序先從緩存里取，沒有再讀庫。用好的話，數(shù)據(jù)庫的訪問能降低數(shù)量級(jí)的請(qǐng)求。數(shù)據(jù)庫的壓力和語言沒什么直接關(guān)系，就算是神語言去訪問數(shù)據(jù)庫一樣對(duì)數(shù)據(jù)庫有壓力。

wlmqgzm

我覺得這種辦法挺好的， 唯一的缺陷是：
引入消息隊(duì)列后，消息隊(duì)列本身帶來了可靠性問題，
簡(jiǎn)單的消息隊(duì)列都會(huì)有消息丟失的問題，有的還存在重復(fù)發(fā)送的問題，
復(fù)雜的消息隊(duì)列可以解決可靠性的問題，但是需要落地存盤， 性能不高。

ruifengzhangyi

數(shù)據(jù)庫本身帶有緩存的功能，為啥不能加強(qiáng)，還得人為搞個(gè)消息隊(duì)列。oracle，postgresql沒有？