酒店預(yù)定系統(tǒng)本身設(shè)計(jì)過程中會遇到售賣系統(tǒng)兩個(gè)常見問題，第一個(gè)同一個(gè)房間同一日期被多個(gè)訂單預(yù)定，或者預(yù)定和庫存數(shù)據(jù)不一致，這些都會涉及到金錢，需要在系統(tǒng)涉及是被重點(diǎn)考慮。

問題1:同一個(gè)房間同一個(gè)日期被多個(gè)訂單預(yù)定

酒店商家考慮有顧客會取消訂單，可以超賣10%的商品，但是需要保證同一個(gè)房間不能被預(yù)定多次。有兩種場景可以導(dǎo)致同一個(gè)房間被預(yù)定多余多次，第一種是用戶同一訂單點(diǎn)擊了多次，另外一種是多個(gè)用戶同時(shí)預(yù)定了同一個(gè)房間。

對于第一種場景解決辦法：當(dāng)用戶進(jìn)入到下單詳情頁面是，服務(wù)端（客戶端產(chǎn)生不可靠）產(chǎn)生一個(gè)唯一id作為冪等鍵跟隨詳情頁信息返回。

對于第二種場景解決辦法：

第一種是使用被關(guān)鎖，在準(zhǔn)備下單減庫存時(shí)，使用select …for update 將這個(gè)庫存表先鎖起來，優(yōu)點(diǎn)實(shí)現(xiàn)起來簡單，確定，當(dāng)需要鎖定資源過多是，需要考慮各種資源的鎖定順序和關(guān)系，容易引起死鎖。

第二種是使用樂觀鎖，在數(shù)據(jù)庫里面增加一個(gè)version字段，當(dāng)更新數(shù)據(jù)時(shí)，對于要更新記錄加1，只有準(zhǔn)備寫入版本大于數(shù)據(jù)庫版本才更新成功，否則重新從數(shù)據(jù)庫獲取，重復(fù)更新，存在一個(gè)自旋的過程，當(dāng)競爭很激烈時(shí)整個(gè)服務(wù)性能會變差。

第三種使用數(shù)據(jù)庫底層限制，CONSTRAINT check_room_count CHECK((total_inventory - total_reserved >= 0))，優(yōu)點(diǎn)實(shí)現(xiàn)簡單，缺點(diǎn)不是所有數(shù)據(jù)庫都支持，并且當(dāng)用戶頁面看到有庫存，但可能下單不成功，引起用戶不好體驗(yàn)，競爭激勵(lì)時(shí)性能也會變差，整體來說不好的一面和樂觀鎖相似。

問題2:房間庫存和訂單數(shù)量不一致

在微服務(wù)設(shè)計(jì)中，有些公司庫存和訂單數(shù)據(jù)不在同一個(gè)數(shù)據(jù)庫，如何保證庫存和訂單數(shù)量一致性將變成一個(gè)需靠考慮的問題：

第一種辦法是使用分布式事務(wù)，兩階段提交2PC，可以保證強(qiáng)一致性，但是性能不好，真實(shí)中采取的很少。

第二種是采用最終一致性，下單的之前先鎖庫存（給庫存設(shè)定一個(gè)鎖定時(shí)間，過期自動釋放鎖定），然后再下單，如果下單失敗或者沒有沒有支付，釋放庫存。
第三種：直接把庫存和訂單設(shè)計(jì)到同一個(gè)數(shù)據(jù)庫里面，使用數(shù)據(jù)庫的事物保證強(qiáng)一致性。

補(bǔ)充知識點(diǎn)

兩階段提交（Two-Phase Commit， 2PC），是分布式事務(wù)執(zhí)行的一個(gè)過程，分布式事務(wù)執(zhí)行分為三步驟，一個(gè)階段協(xié)調(diào)者向所有參與者發(fā)送事物內(nèi)容，詢問是否可以提交事物，等所有參與者回復(fù)，所有參與者回復(fù)可以，才可以進(jìn)入到第二階段。第二階段是協(xié)調(diào)者通知所有參與者執(zhí)行分布式事務(wù)一些事準(zhǔn)備，將undo和redo日志寫入到事物日志中，只有所有參與者回復(fù)執(zhí)行成功才會進(jìn)入到第三階段，否則撤銷執(zhí)行；第三階段是協(xié)調(diào)者通知所有參與者提交事物，一個(gè)分布式事務(wù)才會執(zhí)行成功，通常將前兩個(gè)步驟成為第一個(gè)階段，成為確認(rèn)階段。