在上一章節，我們一起瀏覽了如何進行單機事務操作。下面我們來看一下分布式場景中我們碰到的問題吧。
需要說明的一點是，這裡涉及到的權衡點非常的多。就我短短的工作經驗裡面，也只是能夠簡單的涉獵一部分，因為在事務這個領域，目前大家都在嘗試提出各種各樣的不同的方法，而在taobao，我們目前也沒有完美的解決這個問題，更多的是在權衡，在金錢和開發成本之間，做出選擇。
那麼，我們就先從問題開始，來看一下原來的事務出了什麼問題。
在事務中，有acid四種屬性。（見上篇文章）
在分布式場景中，我們看引入了什麼因素，導致了什麼樣的新問題：
延遲因素:光是我們所知最快的資訊載體了，各位可能都會從潛意識裡面認為光傳輸資訊不就是一眨眼的事情而已。那我們做個簡單的計算吧（感謝@**叔度，第一次在分享中讓我對這個問題有了個數值化的印象。）：
北京到杭州，往返距離2600km ，光在真空中的傳輸速度是30wkm/s。在玻璃中的速度是真空的2/3。算下來，最小的請求和響應，之間的延遲就有13ms。並且，因為光在管子裡走的不是直線，又有訊號干擾等問題，一般來說要乘以2~3倍的因子值。
所以一次最小的請求和響應，時間就差不多有30ms左右了。
再想想tcp的時間視窗的移動策略，相信大家都能意識到，實際上延遲是不可忽略的，尤其在傳輸較多資料的時候，延遲是個重要的因素，不能不加以考慮。
並且，延遲 不是 頻寬，頻寬可以隨便增加，千兆網絡卡換成萬兆，但延遲卻很難降低。而我們最需要的，是頻寬，更是延遲的降低。因為他直接決定了我們的可用性。
災備因素：單機的情況下，人們一般不會去追求說乙個機器物理上被水沖走了的時候，我的資料要保證不丟（因為沒辦法的嘛。。）。但在分布式場景下，這種追求就成為了可能，而網際網路行業，對這類需求更是非常看重，恨不能所有的機器都必須是冗餘的，可隨意替換的。這樣才能保證7*24小時的正常服務。這無疑增加了複雜度的因素。
scale out的問題： 單機總是有瓶頸的，於是，人們的追求就一定是：不管任何一種角色的機器，都應該可以通過簡單的增加新機器的方式來提公升整個集群中任何乙個角色的效能，容量等指標。這也是網際網路行業的不懈追求。
效能：更快的響應速度，更低的延遲，就是更好的使用者體驗。（所以google用了個「可憐」到家的簡單input框來提公升使用者體驗，笑）。
說道這裡，大概大家都應該對在分布式場景下的廣大人民群眾的目標有了乙個粗略的認識了。
那麼我們來看一下原有acid的問題吧。
在上次的章節中，我們也提到了acid中，a和d相對的，比較容易達到。但c和i都涉及到鎖實現，也就和效能緊密的相關了。
然後，人們就開始了糾結，發掘這個c和i，似乎不是那麼容易了。
上次，我們談到，目前主流的實現一次更新大量資料的時候，不同人（或機器）修改資料相互之間不會打架的方法有以下幾種：
排他鎖讀寫鎖
copy-on-write
佇列記憶體事務
排他鎖和讀寫鎖，本身都是鎖的實現，單機的鎖實現，相對而言是非常簡單的事情，但如果涉及到分布式鎖，那麼消耗就很高了，原因是，鎖要在兩邊都達到一致，需要多次機器之間的互動過程，這個互動的過程，再考慮到延遲的因素，基本上一次加鎖請求就要100~200+毫秒的時間了，那麼去鎖又要這樣的時間。而要知道，我們在單機做記憶體鎖操作，最慢也不過10毫秒。。
於是，有一批人就說了，既然這麼難，我們不做了！~來個理論證明他很難就行了~。於是就有了cap和base.
所謂cap，我個人的理解是描述了一種： 在資料存了多份的前提下，一致性和響應時間，讀寫可用性不可兼得的「現象」而已。
在我這裡來看cap的證明過程就是個扯淡的玩意兒，他只是描述了一種現象而已。原因還是網路延遲，因為延遲，所以如果要做到資料同時出現或消失，那麼按照鎖的方式原來可能只需要10ms以內完成的操作，現在要200~400ms才能完成，那自然不能接受了。所謂cap就是這個現象的英文簡稱，笑。
base呢，這個理論似乎更老，其實也是個現象，就是基本可用，軟狀態，最終一致的簡稱，也沒個證明，其實就是告訴咱：要權衡一下，原來的acid不太容易實現啦，我們得適當放棄一些啦。但請各位注意，acid實際上是能夠指導我們在什麼情況下做什麼樣的事情能夠獲取什麼樣的結果的。而base則不行，這也說明base不是個經典的理論。
好啦。廢話了這麼多，其實就是想說，分布式場景沒有銀彈啦，你們自己權衡去吧。我們大牛們救不了你們啦的意思。。
既然大牛救不了咱，咱就只能自救了。。。
本文**於"阿里中介軟體團隊播客",原文發表時間"
2011-12-15"
海量儲存系列之十三
在上一章中，我們主要介紹了規則引擎中最重要的乙個部分，自動擴容，在今天的章節，我們主要還是介紹一下我們在 tddl中的工程實踐吧。首先從原理開始吧。規則引擎是什麼呢？對應在上述例子裡面，其實就是dbnum pk 3 這個規則。他的變化可能很多，比如對於一致性hash則變為乙個if else 的表示式...
海量儲存系列之六
上次我們講到，單機事務個我們面臨的問題，下面我們來說一些我所知的解決的方法。在我開始做 資料層的時候，被問得最多的無非也就是 如何做事務，如何做join.至今仍然如此，我一般都會簡單而明確的跟對方說 沒有高效的實現方法。雖然沒有高效的實現，但實現還是有的。作為引子，我們先來介紹一下這種實現的方式。我...
海量儲存系列之十二
目前，團隊blog和sina輕部落格的發布進度已經完全相同，後續會全部 時間隔了比較久了，因為最近在過年臨近，所以都在準備這方面的事情。這裡提前祝大家新年快樂。然後還是回到我們的正題兒吧 本章，我們主要來討論資料的管理和擴容中最重要的乙個部分，資料遷移。資料遷移是資料運維中最為重要的乙個部分，在前面...