Scaling with IMDG（通過記憶體資料網格進行伸縮）

今天看了一篇文章覺得不錯，大體上總結如下：

 說到伸縮性，我們一般都會想到存儲的伸縮以及本身應用程式的伸縮，下面這篇文章講解了對傳統的關系資料的伸縮以及如何通過記憶體資料網格來進行應用程式的伸縮。

 首先對于傳統的RDBMS的伸縮，大家比較熟悉主要有以下兩種方式：

 Database replication:這也是經典的Master/salve模式的實作，這種方式最大的優點就是通過增加savle來進行read操作的負責均衡，是一種對read的scale out方式，但是同時這種方式也存在以下的缺點：

1 隻是适合于read 頻繁的情況，Database replication方式通過多個replica 來對read進行伸縮，但是對于write操作則不能進行scale out.

2 性能問題，因為資料庫操作是一種磁盤io操作

3 一緻性（consistence),關于這個問題，如果深入讨論可以獨立寫一篇文章來進行讨論，這裡簡短的說一下，Master/savle中，如果采用異步複制，那麼不同的節點的狀态可能是不一緻的，相反的如果采用同步方式，那麼又會造成很大的延遲。

4 容量問題，複制（replication)技術要求每個節點儲存完整的資料，這就帶來了兩個問題，第一個問題就是對于每個節點來說，資料還是會變得越來越多，這樣查詢的速度也會相應的變慢，第二個問題就是我們需要提供N+1倍的存儲空間。

5 複雜性以及非标準化問題，大多數的資料庫複制技術都是相對複雜的，同時不同的廠商所采用的方式也是不一樣的，這樣就會造成應用和存儲的依賴性。

 Datebase partitioning:這種方式也就是大家熟悉的資料庫sharding技術，這種方式使得資料庫中資料分布在多個節點上面，這樣每個節點都存儲一部分資料，這樣的好處就是可以對read和writer操作都具有一定的scale out，但是同樣這種方式也存在以下的缺點：

1 要求應用程式的資料必須是能很容易切分的。

2 性能問題，因為資料庫操作是磁盤IO。

3 要求改變資料模型，很多的資料sharding技術都要求應用程式知道資料在哪一個partition上面。

4 需要改變應用程式代碼

5 靜态性，在許多的資料庫實作中，當增加Partition的時候，都要求重新的劃分partition.相反的目前流行的key-value存儲系統通過consistent hashing解決了這個問題。

6 複雜性

7 非标準的

前面是針對傳統的資料庫對scalability的解決方案，下面作者指出了如何通過記憶體資料網格（In-memory date grids)來進行應用程式的scale out.

   在說IMDG之前,作者也指出了目前很多網際網路公司采用的方式:通過記憶體緩存來scale out應用程式，目前比較經典的做法就是在DB前端引入分布式的緩存系統（memcached,terracotta等)，這樣可以對大部分的讀取操作進行非常有效的scale out,但是此種方案還是沒有解決對write操作的scale out。

 下面就說說IMDG對scale out的解決方案。

     作者指出了Paas的說法，說白了就是将對象和資料的持久化僅僅當做是一種服務而已，以下作者以問答的方式闡述了幾個常見的問題。

1 Paas如何工作

利用Paas，IMDG将會屏蔽到資料庫，記憶體IMDG和底層資料庫的同步操作由IMDG來完成，這種記憶體和資料庫的同步可以通過異步的方式來進行。

2 Paas和RDBMS相比是如何×××能的

2.1 Paas依賴記憶體來存儲系統的狀态，而記憶體操作和磁盤IO操作來比是非常快速的，同時也支援更大的并發通路。

2.2 因為是記憶體存儲，是以資料通路通過記憶體引用或者指針，而不需要序列化的開銷。

2.3 資料操作直接針對記憶體對象

2.4 減低了競争條件，這種方式是将資料配置設定到多個記憶體節點上。

2.5 并行的聚合查詢，這種方式非常類似Map-reduce并行計算模型，它是一種将計算移動到存儲資料的節點進行并行計算的方式，這樣将會更好的利用CPU和記憶體資源

   2.6 避免了ORM，讀取操作直接從記憶體進行，避免了ORM的開銷，ORM隻是在初始化的時候進行。

3 如果要同步資料庫，那麼此種解決方案不會受到資料性能的影響嗎？

不會，原因如下：

3.1 資料以批量的方式異步的同步到資料庫。

3.2 更新操作是可以在多個Partition節點并行的進行

3.3 更新操作發生在和需要更新的資料在同一台實體機器上面，這樣避免了網絡開銷.

3.4 我們不是為了高可用性的目的來使用RDBMS的，RDBMS是一個強一緻性，低可用性的解決方案（CAP理論），   采用IMDG所有的查詢操作都是直接的記憶體操作，而隻有update和insert操作才會觸發資料庫，并且這個時候會以partition的方式，也就是說write操作也是被scale out的操作。

3.5 應用程式和資料庫現在是松耦合的，這樣更加友善進行優化

4 異步的同步IMDG和資料庫是不是意味着當失敗發生的時候，資料可能會丢失？

IMDG會進行backup，當一個節點發生失敗的時候，備份節點會接着進行，是以不會失敗。

5 如果其中一個記憶體節點失敗會發生什麼問題？

這個問題非常類似于hadoop的Namenode和datenode節點模型，熟悉hadoop的朋友應該能容易了解。

6 如果資料失敗會發生什麼問題？

   IMDG會保留一個記錄所有更新和插入的日志，當資料庫失敗的時候，更新和插入操作還會繼續，不會影響到系統終端使用者，當底層資料庫再次可用的時候，IMDG會根據日志來同步資料。

7 IMDG怎麼處理事務完整性？

 大家都知道2PC事務是一種反伸縮性的實踐，它使得所有的partition耦合在同一事務當中，目前比較好的做法就是将事務分為幾個小的事務，每個小的事務都在單獨的partition上面完成，這樣即使存在部分partition失敗，但是IMDG還是會保證整個系統處于一緻性的狀态。

下面我發發牢騷。

目前随着網際網路的的快速發展，對于一些熱門的應用會造成非常大的讀寫壓力，尤其是目前社會化網絡使得傳統的RDBMS更加受到打擊。

 說到伸縮性，我們一般都會想到應用程式本身的伸縮和存儲的伸縮，應用的伸縮要求我們對應用程式進行合理的切分，按照功能，按照層的方式進行，而存儲的伸縮，傳統方式采用複制，sharding等方式，但是這種方式是有很多限制的，限制上面也說了。是以我們如何尋找一種能對read和write都具有scale out的解決方案就成了目前一個難題。幸好，目前NOSQL運動給我們帶來了福音，通過分布式的key-value存儲系統可以更好的對read和write操作進行scale out.比如像Twitter這樣的應用，它是一個讀和寫都很頻繁的應用，采用傳統的解決方案肯定是不行，是以需要一種新的解決方案，這就要求我們吸取NOSQL運動的思想，Twitter每天的有100億條資料寫操作，是以這麼頻繁的write就需要通過consistent hashing根據使用者的ID或者名稱來進行均勻的切分，比如hash(userID)%node_number，這樣又會造成一個問題，就是讀取操作怎麼辦？因為通過切分，不同的使用者被配置設定到了不同的虛拟節點上面，那麼一個Twitter使用者想要讀取最新Tweet的時候就需要從多個節點進行讀取，這個時候就需要利用map-reduce的思想，通過移動運算到存儲資料的地方，最後在聚合所有的查詢操作（在用戶端進行reduce操作）。

原文位址：Scaling with mysql