在公司內部項目實現過程中團隊對SubSonic增加了分布式存儲，透明對象緩存，透明查詢緩存的支持；內部使用了兩三年，并且在持續改進中。

MoSonic支持海量數據存儲，在web 2.0常見場景中其透明緩存層亦可帶來10倍以上的讀取性能提高。

這里寫blog記述一下。

改進參考/使用了：

?

• FriendFeed Schemaless Database Design
• Twitter: Cache Money
• Facebook：Thrift

?

其中Cache Money影響較大，故內部命名為MoSonic，Money-SubSonic。

=============

SubSonic是.net中一個相當流行ORM庫，號稱零代碼。與其它ORM相比，SubSonic在易用性方面相當突出。

但這也不意味著SubSonic，或者說ActiveRecord風格的ORM僅能局限于中小網站的開發使用。

ActiveRecord實際上僅是Martin Fowler在《企業應用架構模式》一書中的一個小章節提出的，兩三頁紙而已。

但在Web 2.0時代，隨著被Ruby On Rails，Django等流行框架采用，而大放異彩。

Twitter建站之初也是采用Ruby On Rails，使用的也是RoR內置的ActiveRecord風格ORM。

隨著Twitter的發展，數據庫性能這塊也必然成為瓶頸。而Twitter對此的回答是Cache-Money，一個透明的ActiveRecord緩存層。

Cache-Money能夠透明的支持兩類緩存，Object Cache 跟 Vector Cache。

（當然Cache-Money的作用不止這兩類緩存。）

=============

都是ActiveRecord，上層API風格一致，Twitter可以在RoR的ORM中做的實現，也一定可以在SubSonic上用c#做實現。

Object Cache比較好理解，它僅僅是基于對象主鍵緩存對象內容。Object.FetchById(XXX) 這類函數中做下手腳，先查詢緩存，緩存不存在時，再去查詢數據庫。這也是所謂的Read-Through直讀緩存。

而Object.Save()在數據庫保存成功之后，也隨即更新Cache。這也是所謂的Write-Through直寫緩存。

Object的直讀/寫緩存實現非常簡單，對SubSonic的FetchById添加Object Cache的話，僅需要十來行代碼就可以使用單機內存做緩存。

單機內存非常有限，Web 2.0網站一般使用memecached做分布式緩存，解決單機緩存內存有限的問題；這基本是標配了。

就.Net而言，找個靠譜的memcached client的要比實現SubSonic的Object Cache更加重要。

我使用的是BeIt出品的memcached客戶端；據說性能更好的有EnyimMemcached，但我沒有詳細測試過，不好評論。

使用了Memcached做緩存的話，對象的序列化問題就變得非常突出了。

.Net內置的BinaryFormatter性能非常差，必須另尋序列化方案。

考察過諸多序列化方案后，我最終選擇的是Facebook開源出來的Thrift；它的設計完備，跨語言/平臺支持能力非常好，性能不比Google開源出來的ProtoBuf差，也可以擴展為進程間RPC通訊方案。

為SubSonic添加對象Thrift序列化相對來說就比較麻煩些，但也不難，在SubSonic的代碼生成模板中修改即可。

Thrift本身實際上也有提供c#的對象序列化的代碼生成工具；但直接使用的話，意味著需要在Thrift對象/SubSonic對象間多增加一次轉換；修改代碼量雖然會少些，但不如直接修改SubSonic的代碼生成模板，直接將Thrift序列化的方法跟SubSonic對象做徹底的整合效率來得高。

使用Thrift做序列化跟使用.net默認的BinaryFormater性能差別是巨大的。公司兩臺Web服務器，在使用BinaryFormater時CPU近乎100%，但改用Thrift做序列化后立刻下降至20%。

（團隊倒不是在出現服務器性能問題后才做了Thrift序列化；提前一年就做了；只是因故做了次實際的性能測試。）

==========

既然修改了SubSonic的代碼生成模板，我也順便將其Object new()的API干掉了；強迫開發者必須使用FetchById風格API獲得對象。

同時也增加了FetchByIds的新函數，支持同時獲得多個對象，對應select * from tables where id in (..., ...)的查詢，以及memcached multi_get的命令。

通過添加透明的Object cache在不增加額外的業務邏輯代碼情況下，已經可以獲得顯著的性能改善，但它還不是本質性的改進。

Cache Money真正的神器是其Vector Cache，實際上，Twitter團隊在開發Cache Money時，是優先考慮了Vector Cache的實現，然后再考慮Object Cache；因為他們認為Vector Cache會性能影響更大，事實也證明他們判斷正確。

下篇會繼續講Vector Cache的實現。

?

轉載于:https://blog.51cto.com/wuvist/847729

總結

以上是生活随笔為你收集整理的MoSonic：对SubSonic的分布式存储、缓存改进方案尝试（1）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。