關(guān)于數(shù)據(jù)庫(kù)設(shè)計(jì)種遇到的分布式事務(wù)的設(shè)計(jì)經(jīng)驗(yàn)

linux_c_py_php

設(shè)計(jì)一個(gè)分布式數(shù)據(jù)庫(kù)總是會(huì)遇到這種問(wèn)題，也就是進(jìn)行了分表設(shè)計(jì)，同時(shí)希望保證多維度的一致性。

例如做一個(gè)訂單系統(tǒng)，包含2個(gè)維度：

1，用戶(hù)維度：用戶(hù)向特定商家下單，查看自己的所有訂單。（uid分表）
2，商家維度：查看自己收到的訂單，確認(rèn)用戶(hù)的訂單。（bid分表）

典型操作1：用戶(hù)下單。
      流程：生成order id(oid)，根據(jù)uid寫(xiě)入用戶(hù)訂單表，根據(jù)bid寫(xiě)入商家訂單表。  
      初衷：向2個(gè)維度都寫(xiě)入同樣的數(shù)據(jù)，在分布式數(shù)據(jù)庫(kù)設(shè)計(jì)下保證用戶(hù)維度和商家維度都可以高效的完成訂單的查詢(xún)。
      問(wèn)題：寫(xiě)用戶(hù)訂單表成功，寫(xiě)商家訂單表失敗，導(dǎo)致商家無(wú)法看到訂單，用戶(hù)空等訂單。
      折衷：在用戶(hù)查看訂單的流程中，對(duì)商家訂單表進(jìn)行重查，如果記錄不存在則重試插入。

典型操作2：商家接單。
      流程：根據(jù)bid篩選該商家訂單表，選中一個(gè)訂單(包含uid，oid信息)，根據(jù)uid更新用戶(hù)訂單表的oid訂單狀態(tài)為已接單，接單商家為bid，最終更新商家訂單表中該oid的狀態(tài)為已接單。
      問(wèn)題：更新用戶(hù)訂單表成功，更新商家訂單表失敗，導(dǎo)致用戶(hù)認(rèn)為預(yù)定成功，而商家查看訂單狀態(tài)沒(méi)有改變。
      折衷：在商家查看訂單的流程中，對(duì)用戶(hù)訂單表進(jìn)行重查，如果訂單已被該商家接單，那么更新商家訂單表狀態(tài)。


上面就是舉一個(gè)典型的場(chǎng)景，對(duì)于分布式數(shù)據(jù)庫(kù)，沒(méi)法通過(guò)單機(jī)事務(wù)保障多表修改的一致性，準(zhǔn)確的說(shuō)是沒(méi)法保障不同維度間的一致性，同一個(gè)維度是可以通過(guò)相同的分表算法保證可以做到單機(jī)事務(wù)。在業(yè)務(wù)場(chǎng)景上，業(yè)務(wù)可以容忍不一致，有的場(chǎng)景業(yè)務(wù)沒(méi)法忍受。

各位大神們對(duì)這種問(wèn)題是否有什么經(jīng)驗(yàn)可以分享一下，謝謝。

hellioncu

分布式事務(wù)可以做，但效率低，所以一般避免這種設(shè)計(jì)

windoze

這實(shí)際上是個(gè)master/detail表結(jié)構(gòu)，master表是訂單，買(mǎi)家賣(mài)家是detail表或者說(shuō)輔助表。一個(gè)類(lèi)似的場(chǎng)景是銀行轉(zhuǎn)賬，交易流水是master表，帳戶(hù)表是detail表。
這種結(jié)構(gòu)的分解有很多種做法，一個(gè)典型方案是：
1、在訂單表里維護(hù)所有核心狀態(tài)，比如訂單狀態(tài)、金額、付款狀態(tài)等。訂單表本身不要顯示的join其它表，而且訂單之間沒(méi)有關(guān)聯(lián)，所以可以簡(jiǎn)單分區(qū)。
2、在生成訂單時(shí)維護(hù)一組“回退”的數(shù)據(jù)，即撤銷(xiāo)這一定單所需的操作和數(shù)據(jù)，這組數(shù)據(jù)隨著訂單狀態(tài)變化需要更新。這組數(shù)據(jù)可以保存在訂單表里，如果業(yè)務(wù)規(guī)則夠簡(jiǎn)單也可以直接從訂單數(shù)據(jù)里臨時(shí)生成
有了上面兩組數(shù)據(jù)，你就可以放心的更新訂單了，反向的關(guān)聯(lián)不是關(guān)鍵事務(wù)數(shù)據(jù)，可以獨(dú)立更新，比如用戶(hù)查詢(xún)自己所有的訂單，這一類(lèi)操作可以通過(guò)更新訂單狀態(tài)時(shí)附加更新獨(dú)立的“用戶(hù)訂單”數(shù)據(jù)來(lái)完成，這組數(shù)據(jù)可以定期重建，以免偶發(fā)的數(shù)據(jù)不一致。
商戶(hù)端數(shù)據(jù)可以通過(guò)消息隊(duì)列之類(lèi)的東西更新，使用持久化的消息隊(duì)列外加一個(gè)超時(shí)撤銷(xiāo)或重試就可以避免丟失訂單，加點(diǎn)dedup邏輯就可以避免重復(fù)訂單。

總之，你只要降低你的SLA就幾乎可以避免所有問(wèn)題，話(huà)說(shuō)即使你用TPC一樣不能保證百分百可靠。

linux_c_py_php

回復(fù) 3# windoze


的確, 我理解類(lèi)似問(wèn)題是無(wú)法避免的, 我認(rèn)為設(shè)計(jì)時(shí)可以抱著幾個(gè)核心原則：

1，接口冪等性：簡(jiǎn)單說(shuō)一筆錢(qián)從一個(gè)賬戶(hù)里扣過(guò)一次，不能再扣。
2，業(yè)務(wù)容忍性：技術(shù)故障，對(duì)業(yè)務(wù)方不造成或者盡量減少利益損失。
3，自動(dòng)化回滾：在接口冪等前提下，一些業(yè)務(wù)可以通過(guò)消息隊(duì)列實(shí)現(xiàn)自動(dòng)回滾。

windoze

回復(fù) 4# linux_c_py_php

接口不一定總能做到冪等，只要能回滾就行，問(wèn)題不大。
就算銀行也是發(fā)現(xiàn)問(wèn)題就回沖賬目的。