※ 引述《lancer7 (158)》之銘言：
: 假設一個訂票系統有一個table：座位
: 欄位有日期、座位號碼、是否available、訂位人的ID
: 現在有兩個user: A, B進入了訂票系統
: 接著發生了以下事件
: 1. A select此table發現有五個空位
: 2. B select此table發現有五個空位
: 3. A 訂了四個位子，並且把這四個位子的狀態update為unavailable
: 4. A結束transaction
: 5. 現在B以為有五個空位，於是訂了兩個位子 => 發生重複訂位的問題
: 請問一下，有什麼辦法解決這個同步的問題?
: 我想到的方法是在事件1發生時讓A對table作lock，然後B要等到A結束transaction才能select
: 不過這方法效率似乎不好，有更好的方法嗎?
老實說這要處理的不應該是技術上的問題，而是規劃上的問題，
如果只以程式來說，
lock 層越往外，lock 的時間越長，空位的浮動率會越大，
lock 層越往內，lock 的時間越短，使用者會越晚被攔阻（較高的達成期望）
兩個方向上都各有利弊，
所以重點是要怎麼規劃這個訂購的流程，要在哪個步驟設下斷點，
當使用者在哪個步驟失敗（拿不到座位）時要怎麼說明 / 安撫。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.45.240.59
※ 編輯: gpmm 來自: 114.45.240.59 (10/06 00:23)
推
10/06 02:04, , 1F
10/06 02:04, 1F
推
10/06 09:13, , 2F
10/06 09:13, 2F
→
10/06 09:15, , 3F
10/06 09:15, 3F
→
10/06 18:35, , 4F
10/06 18:35, 4F
→
10/06 18:36, , 5F
10/06 18:36, 5F
討論串 (同標題文章)