在需要添加約東時,例例如讓物品從用戶看到它們直到用戶購買它們都存在,要認真考慮。雖然某些特殊情況可能會令客戶失望,但是彌補客戶比起不能擴展來說容易得多。
在數(shù)學(xué)和機器學(xué)習(xí)(人工智能)領(lǐng)域,有一套約東滿足問題(CSP),其中的對象必須滿足某些約束。CSP通常復(fù)雜度很高,需要啟發(fā)式搜索和組合式搜索方法結(jié)合才能解決的。兩個經(jīng)典的CSP難題是數(shù)獨游戲和地圖著色問題。數(shù)獨游戲的目標(biāo)是填寫一個大九宮格,每行每列都有9個單元格,大九宮格可以分為小九宮格,要在每個小九宮格中填入1到9的數(shù)字,使得大九宮格每一行和每一列的數(shù)字都不重復(fù)。地圖著色問題是對地圖進行著色,使相鄰的地區(qū)具有不同的顏色。
CSP問題還會衍生出時序約束滿足問題(TCSP),其中變量表示的是事件,約束表示兩個事件之間可能的時序關(guān)系。這類問題的目標(biāo)是確保變量間的約束,決定滿足約束的各種場景。對變量強制實行本地一致性,可以確保問題中的所有節(jié)點、弧和路徑都滿足約東。機器學(xué)習(xí)領(lǐng)域和計算機科學(xué)中的很多問題都可以建模為TCSP,如機器視覺、調(diào)度、平面布局設(shè)計、SaS系統(tǒng)中的用例等,都可以看作是TCSP。
常見的SaS應(yīng)用中的時序約束的例子是用戶購買一個物品。用戶瀏覽該物品,把它放入購物車并結(jié)算,這些操作都需要一些時間。有人認為,考慮到絕對的最佳用戶體驗,無論這個物品是否存在,都要在整個過程中使它保持統(tǒng)一的狀態(tài)。要實現(xiàn)這一點,就需要在用戶關(guān)掉該頁面,或者放棄了購物車,或者結(jié)算之前,把該物品在數(shù)據(jù)庫中標(biāo)識為“扣押”的狀態(tài)。如果我們站點的用戶數(shù)不多,這種方法簡單實用。對用戶來說,在把物品加入購物車之前,瀏覽了100個或更多的物品是很常見的。我們的一個客戶聲稱,他們的用戶在把一個物品加入購物車之前,要瀏覽500多個檢索結(jié)果。對于這種情況,我們的應(yīng)用可能需要幾個數(shù)據(jù)庫的讀副本,使得更多的人能夠檢索和瀏覽物品,而不是購買物品。這樣就產(chǎn)生了問題,大多數(shù) RDBMS難以保持節(jié)點間的所有數(shù)據(jù)完全一致。即使數(shù)據(jù)庫的讀副本或者從數(shù)據(jù)庫在數(shù)據(jù)一致性上只有幾秒鐘的差別,還是會產(chǎn)生特殊情況,例如兩個用戶都想查看某個物品,而它只剩下最后一個。后面我們會來解決這個問題,但是首先讓我們看看為什么數(shù)據(jù)庫會造成這個問題。
造成RDBMS難以進行分布式擴展的屬性是一致性。CAP定理,又稱為布魯爾定理,是以計算機科學(xué)家 Eric Brewer的名字命名的,它描述了在分布式環(huán)境中設(shè)計應(yīng)用的三點核心要求,但這三點要求不可能同時滿足。這三點要求用縮寫CAP表示。
一致性(Consistency)--客戶端發(fā)現(xiàn)一組操作同時發(fā)生了
可用性(Avalability)一一在收到計劃中的響應(yīng)后,任何操作都要終止。
分區(qū)容忍性(Partition Tolerance)-即使個別組件不可用,操作也會完成。
這個問題的解決方案叫做BASE,是解決CAP的架構(gòu)的縮寫,代表基本可用(Basic Available)、軟狀態(tài)( Soft State)和最終一致性(Eventually Consisten)通過放松、一致性的ACID屬性,在擴展性方面可以得到更大的靈活性。采用BASE架構(gòu)可以使數(shù)據(jù)庫最終達到一致。這可能只需要幾分鐘,甚至幾秒鐘,但在前面的例子中我們看到了,如果應(yīng)用程序希望能夠“鎖定”數(shù)據(jù),那么即使幾毫秒的不一致也會造成問題。
放松時序約束可以重新設(shè)計我們的系統(tǒng)、從而使它能夠達到最終致性。用戶剛瀏覽過一個物品,不能確保該物品還存在。只有把該物品放入購物車,應(yīng)用才會鎖定數(shù)據(jù),鎖定操作會在主寫入副本或主數(shù)據(jù)庫中執(zhí)行。由于我們具有ACID屬性、所以可以確保如果交易完成了,就可以把該物品的記錄標(biāo)志為“鎖定的”、然后用戶就可以繼續(xù)放心購買了因為該物品已經(jīng)為他們保留了。而對其他瀏覽該物品的用戶來說,它則可能還有,也可能沒有了。
另一個常常發(fā)現(xiàn)時序約束的應(yīng)用領(lǐng)域是轉(zhuǎn)移物品(錢)或在用戶間通信。在單一數(shù)據(jù)庫中,很容易確保用戶A把錢、消息或物品轉(zhuǎn)移到了用戶B的賬戶。把數(shù)據(jù)分布到多個數(shù)據(jù)副本上,使得保持這種一致性變得很困難。解決這種問題的方法是不要希望對即時轉(zhuǎn)移操作有時序約東。讓用戶A在看到用戶B轉(zhuǎn)給他的錢之前等待幾分鐘,是完全可以接受的原因很簡單,轉(zhuǎn)移物晶的雙方通通常不會在系統(tǒng)中同步轉(zhuǎn)移物品。顯然與同步通信不同,如聊天。你很容易在網(wǎng)站設(shè)計系統(tǒng)中加人時序約束,因為看來,這能提供最好的客戶體驗。但是,在添加時序約東前,最好考慮一下這樣做產(chǎn)生的長期問題,因為這種約東有可能使得系統(tǒng)擴展變得很困難。
本文地址:http://m.hbbqcd.cn//article/3467.html