今天就跟大家聊聊有關(guān)MVCC思想在分布式系統(tǒng)中的應用是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
創(chuàng)新互聯(lián)建站服務項目包括文圣網(wǎng)站建設(shè)、文圣網(wǎng)站制作、文圣網(wǎng)頁制作以及文圣網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，文圣網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到文圣省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
最近項目中遇到了一個分布式系統(tǒng)的并發(fā)控制問題。該問題可以抽象為：某分布式系統(tǒng)由一個數(shù)據(jù)中心D和若干業(yè)務處理中心L1，L2 ... Ln組成；D本質(zhì)上是一個key-value存儲，它對外提供基于HTTP協(xié)議的CRUD操作接口。L的業(yè)務邏輯可以抽象為下面3個步驟：
read: 根據(jù)keySet {k1, ... kn}從D獲取keyValueSet {k1:v1, ... kn:vn}
do: 根據(jù)keyValueSet進行業(yè)務處理，得到需要更新的數(shù)據(jù)集keyValueSet' {k1':v1', ... km':vm'} (注：讀取的keySet和更新的keySet'可能不同)
update: 把keyValueSet'更新到D （注：D保證在一次調(diào)用更新多個key的原子性）
在沒有事務支持的情況下，多個L進行并發(fā)處理可能會導致數(shù)據(jù)一致性問題。比如，考慮L1和L2的如下執(zhí)行順序：
L1從D讀取key:123對應的值100
L2從D讀取key:123對應的100
L1對值增加1，將key:123更新為100 + 1
L2對值增加2，將key:123更新為100 + 2
如果L1和L2串行執(zhí)行，key:123對應的值將為103，但上面并發(fā)執(zhí)行中L1的執(zhí)行效果完全被L2所覆蓋，實際key:123所對應的值變成了102。
為了讓L的處理可串行化(Serializable)，一種最直接的解決方案就是考慮為D加上基于鎖的簡單事務。讓L在進行業(yè)務處理前先鎖定D，完成以后釋放鎖。另外，為了防止持有鎖的L由于某種原因長時間未提交事務，D還需要具有超時機制，當L嘗試提交一個已超時的事務時會得到一個錯誤響應。
本方案的優(yōu)點是實現(xiàn)簡單，缺點是鎖定了整個數(shù)據(jù)集，粒度太大；時間上包含了L的整個處理時間，跨度太長。為此，可以考慮把鎖定粒度降低到數(shù)據(jù)項級別，按key進行鎖定，但這又會帶來其他的問題。由于更新的keySet'可能是事先不確定的，所以可能無法在開始事務時鎖定所有的key；如果分階段來鎖定需要的key，又可能出現(xiàn)死鎖(Deadlock)問題。另外，按key鎖定在有鎖爭用的情況下并不能解決鎖定時間太長的問題。所以，按key鎖定仍然存在重要的不足之處。
為了實現(xiàn)可串行化，同時避免鎖機制存在的各種問題，我們可以采用基于多版本并發(fā)控制（Multiversion concurrency control，MVCC）思想的無鎖并發(fā)機制。人們一般把基于鎖的并發(fā)控制機稱成為悲觀機制，而把MVCC等機制稱為樂觀機制。這是因為鎖機制是一種預防性的，讀會阻塞寫，寫也會阻塞讀，當鎖定粒度較大，時間較長是并發(fā)性能就不會太好；而MVCC是一種后驗性的，讀不阻塞寫，寫也不阻塞讀，等到提交的時候才檢驗是否有沖突，由于沒有鎖，所以讀寫不會相互阻塞，從而大大提升了并發(fā)性能。
我們可以借用源代碼版本控制來理解MVCC，每個人都可以自由地閱讀和修改本地的代碼，相互之間不會阻塞，只在提交的時候版本控制器會檢查沖突，并提示merge。目前，Oracle、PostgreSQL和MySQL都已支持基于MVCC的并發(fā)機制，但具體實現(xiàn)各有不同。
MVCC的一種簡單實現(xiàn)是基于CAS（Compare-and-swap）思想的有條件更新（Conditional Update）。普通的update參數(shù)只包含了一個keyValueSet'，Conditional Update在此基礎(chǔ)上加上了一組更新條件conditionSet { ... data[keyx]=valuex, ... }，即只有在D滿足更新條件的情況下才將數(shù)據(jù)更新為keyValueSet'；否則，返回錯誤信息。這樣，L就形成了如下圖所示的Try/Conditional Update/(Try again)的處理模式：
雖然對單個L來講不能保證每次都成功更新，但從整個系統(tǒng)來看，總是有任務能夠順利進行。這種方案利用Conditional Update避免了大粒度和長時間的鎖定，當各個業(yè)務之間資源爭用不大的情況下，并發(fā)性能很好。不過，由于Conditional Update需要更多的參數(shù)，如果condition中value的長度很長，那么每次網(wǎng)絡傳送的數(shù)據(jù)量就會比較大，從而導致性能下降。特別是當需要更新的keyValueSet'很小，而condition很大時，就顯得非常不經(jīng)濟。
為了避免condition太大所帶來的性能問題，可以為每條數(shù)據(jù)項增加一個int型的版本號字段，由D維護該版本號，每次數(shù)據(jù)有更新就增加版本號；L在進行Conditional Update時，通過版本號取代具體的值。
另一個問題是上面的解決方案假設(shè)了D是可以支持Conditional Update的；那么，如果D是一個不支持Conditional Update的第三方的key-value存儲怎么辦呢？這時，我們可以在L和D之間增加一個P作為代理，所有的CRUD操作都必須經(jīng)過P，讓P來進行條件檢查，而實際的數(shù)據(jù)操作放在D。這種方式實現(xiàn)了條件檢查和數(shù)據(jù)操作的分離，但同時降低了性能，需要在P中增加cache，提升性能。由于P是D的唯一客戶端；所以，P的cache管理是非常簡單的，不必像多客戶端情形擔心緩存的失效。不過，實際上，據(jù)我所知redis和Amazon SimpleDB都已經(jīng)有了Conditional Update的支持。
上面介紹了鎖機制和MVCC的基本原理，但是對于它們分別適用于什么場合，不同的場合下兩種機制優(yōu)劣具體表現(xiàn)在什么地方還不是很清楚。這里我就對一些典型的應用場景進行簡單的分析。需要注意的是下面的分析不針對分布式，鎖機制和MVCC兩種機制在分布式系統(tǒng)、單數(shù)據(jù)庫系統(tǒng)、甚至到內(nèi)存變量各個層次都存在。
有一類系統(tǒng)更新特別頻繁，并且對讀的響應速度要求很高，如股票交易系統(tǒng)。在鎖機制下，寫會阻塞讀，那么當有寫操作時，讀操作的響應速度就會受到影響；而MVCC不存在讀寫鎖，讀操作是不受任何阻塞的，所以讀的響應速度會更快更穩(wěn)定。
對于許多系統(tǒng)來講，讀操作的比例往往遠大于寫操作，特別是某些海量并發(fā)讀的系統(tǒng)。在鎖機制下，當有寫操作占用鎖，就會有大量的讀操作被阻塞，影響并發(fā)性能；而MVCC可以保持比較高且穩(wěn)定的讀并發(fā)能力。
如果系統(tǒng)中寫操作的比例很高，且沖突頻繁，這時就需要仔細評估。假設(shè)兩個有沖突的業(yè)務L1和L2，它們在單獨執(zhí)行是分別耗時t1，t2。在鎖機制下，它們的總時間大約等于串行執(zhí)行的時間：
T = t1 + t2
而在MVCC下，假設(shè)L1在L2之前更新，L2需要retry一次，它們的總時間大約等于L2執(zhí)行兩次的時間（這里假設(shè)L2的兩次執(zhí)行耗時相等，更好的情況是，如果第1次能緩存下部分有效結(jié)果，第二次執(zhí)行L2耗時是可能減小的）：
T’= 2 * t2
這時關(guān)鍵是要評估retry的代價，如果retry的代價很低，比如，對某個計數(shù)器遞增，又或者第二次執(zhí)行可以比第一次快很多，這時采用MVCC機制就比較適合。反之，如果retry的代價很大，比如，報表統(tǒng)計運算需要算幾小時甚至一天那就應該采用鎖機制避免retry。
從上面的分析，我們可以簡單的得出這樣的結(jié)論：對讀的響應速度和并發(fā)性要求比較高的場景適合MVCC；而retry代價越大的場景越適合鎖機制。
看完上述內(nèi)容，你們對MVCC思想在分布式系統(tǒng)中的應用是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。
重慶分公司
重慶分公司
