同事的QCON會議記錄分享

新浪微博Redis應用實踐

 

Redis（http://redis.io/）是一個key-value儲存系統、類似於Memcached、但相比前者有一定的優勢（如支援更多的Value、效能更好等）

新浪大量使用Redis、其中一個重要使用情境是計數器、微博有大量需要即時計數的情境、如：微博數，粉絲數和關注數等等、

在新浪微博如此海量的資料和高並發情境（如一條微博在短時間內會被迅速轉寄N次）去count和Update DB顯然不靠譜。

Offer這邊也有很多使用數位情境：如重發的400限制條數、普及版會員的優先展示Offer數等、

當前是採用MC（memcached）+Mysql的方式、但MC的穿透問題、高並發導致和DB資料不一致的問題、以往也引起過不少投訴。

而使用Redis可以很好的解決這些問題。當然新浪的經驗也告訴我們Redis不是說用了肯定就合適、需要看具體的業務和使用情境。

 

eBay技術平台

 

同為B2B網站、發現Ebay的技術架構和我們有不少的共同點、技術上面臨的挑戰也跟我們有很大的相似

 

eBay的一些資料

 

1、資料總儲存量達到9P

2、10000台應用伺服器

3、4400萬行代碼

4、20億張圖片

5、可用性99.94%

 

架構特點：

 

1、資料庫、應用程式層、搜尋引擎等都進行了拆分、保證可擴充性

2、應用間的Session無狀態化（類似於Session服務化）、應用伺服器的無狀態化

3、在容錯和監控方面：有Logging中心、Mark downs（自動探索哪些應用不可用、一旦發現就不再請求到該應用）

4、服務化大規模使用（但主要採用Webservice的方式、和amazon類似）

 

面臨的挑戰和一些解決方案：

 

1、代碼商務邏輯太複雜（4400萬行代碼、4000多個Jar包）、應用間依賴太多、耦合很高、開發效率很低

  

   OSGi模組化、封裝內部邏輯、約定好模組之間的邊界和耦合方式

 

2、服務的資料格式很多、服務（Webservice）大量使用帶來的延遲問題

 

   將各種資料格式統一轉換成JAXB、採用二進位格式（Google的protocol buf）替代XML和JSON等

 

3、服務調用中的N+1問題、服務返回資料利用率問題（有時只是擷取服務返回對象的某一個欄位、其他都浪費掉了）、服務串列調用延遲太高（如何能夠實現並行調用）

 

  自主開發了ql.io（即將開源）、能夠像寫SQL那樣調用服務、可以有類似於SQL那樣的Where、Filter、Join、Order By等條件、只取出想要的資料、也可以並行調用服務。

 

福士點評網的技術變遷之路

 

總體講的都是通用的技術、Memcached的使用經驗方面講的比較細緻：

 

1、緩衝對象粒度的控制、便於緩衝的更新刪除

 

有時需要緩衝一個列表、通用的方式是把整個列表對象全部放到緩衝裡面、但是這樣List裡的對象只要有一個發生變更整個列表就需要更新或者刪除

改進的方式是：比如原來是緩衝List<Shop>、現在首先緩衝一個List<ShopIndexId>、裡面的Key只是一個Shop的Id、然後分別緩衝每個Shop對象、這樣的

好處是每個Shop對象本身可以直接通過緩衝讀取、當單個Shop對象變更時不需要清除整個List、List裡只有Id、而這一般都不會改變、通過Memcached的

Mget()可以一次性擷取整個列表

 

2、大批量緩衝的清除

 

如果緩衝的資料格式變化較大時、為了防止緩衝的髒資料問題；一般可以採用建立Region讓原來的緩衝自動到期而不是手動清除（Lazy Delete）

如果緩衝的資料大體跟原來相同、只是某個欄位變化的話可以採用給Key加版本號碼的方式來控制、福士點評網寫了一個通用的Cache Provider組件來

自動管理Key的版本號碼、避免了開發自己去維護版本號碼

 

3、緩衝序列化和還原序列化對CPU和網路的開銷

 

可以採用一些相對高效的資料交換格式如Google Protocol Buffer（空間利用率和序列化效能比XML、Json、Java對象序列等好很多）

 

4、多Memcached伺服器下的分布式演算法

 

採用業界通用的一致性雜湊演算法（我們還用模取餘的方式、說是為了相容老代碼）

 

5、在資料訪問層DAO實現自動緩衝

 

通過AOP來實現、確實很多時候只是緩衝DAO層返回的對象、實現方式一般都差不多的、通過AOP來自動處理可以減少很多重複代碼

 

6、緩衝雪崩問題

 

指的是緩衝大量失效導致DB負載瞬間上升的問題（這個我們以前也碰到過）、福士點評網原來是採用雙緩衝的策略、但是這樣維護起來比較麻煩、且容易造成緩衝錯亂的情況

後面準備採用Redis來替代Memcached也解決這個問題（其他方面：複製分發、對象的部分讀取、高並發下的效能更好）。