如果你的業(yè)務暴漲10倍or100倍，你怎么設計你的數(shù)據(jù)庫？

stay_sun

回復 10# cjfeii


我覺得你進入了誤區(qū)   我們的數(shù)據(jù)庫是為了業(yè)務服務的   根據(jù)你的想法 a 給b 轉賬 1000 我干嘛要 回滾  
我只要保證 a 減去1000 b 加上1000 即可   

   

cjfeii

是存在這種情況的，這是兩個數(shù)據(jù)庫操作，如果第一個操作成功（A-1000），第二個操作失�。˙+1000），不就需要回滾了嗎？

回復 20# stay_sun


   

cjfeii

如何保證（a-1000,b+1000）都成功
回復 20# stay_sun


   

yehuafeilang

我想關系型數(shù)據(jù)庫在以后很長一段時間還是中小數(shù)據(jù)量需求的主流吧，特別是針對頻繁讀寫的。

yehuafeilang

我想關系型數(shù)據(jù)庫在以后很長一段時間還是中小數(shù)據(jù)量需求的主流吧，特別是針對頻繁讀寫的。

lyhabc

不結合業(yè)務的架構，就是耍流氓。

stay_sun

回復 22# cjfeii


   隊列啊

cjfeii

例子說：A賬戶-1000，B賬戶+1000
我認為會存在一種情況是：前一個操作成功（A+1000），后一種操作（B+1000）永遠不會成功
比如，在A+1000執(zhí)行的同時B賬戶銷戶了，這種情況怎么辦？難道這種情況已經(jīng)執(zhí)行成功的A+1000的操作不需要回滾嗎？

隊列如何解決這個問題，將第二個操作一直保存著隊列中，等待用戶重新創(chuàng)建B賬戶（重新創(chuàng)建的B賬戶就是之前的B賬戶）？

你可能說在執(zhí)行這個事務之前，做了事務準備工作：鎖定A、B賬戶不允許銷戶、不允許等等操作
這里先不說這種做法是否合理（怎么可能不允許我銷戶...因為可能有人給你打錢...so...等著吧...我的天哪...萬一有人準備從我賬號偷錢咋辦...不讓我銷戶損失誰負責...）
如果說在事務之前，鎖定了A、B賬戶，難道就不存在B+1000失敗的情況了嗎？程序員誤操作永久刪除B賬戶、貪污賬號凍結B賬戶、bug、地震導致B賬戶出問題。。。

綜上，我覺得事務是需要回滾的，一定成功的事務（最終一致）可能不是我常規(guī)理解的事務。

回復 27# stay_sun


   

睡羅

這個就不好說了。

linuxforlive

留個  先從硬件方面改良  然后再從數(shù)據(jù)庫方面設計