相對于memcache,redis擁有的持久化和多數據類型,非常適合應用于互聯網社交、電商等業務較為復雜的系統中.

新浪微博是國內最早(2010年)大規模線上Redis的實踐者,到目前已經趨于極致.

可以看這篇干貨《用最少的機器支撐萬億級拜訪,微博6年Redis優化歷程》,我們能借鑒到如何避免大規模應用redis時,會碰到的問題,如：

1、持久化內存消耗導致服務崩潰.

2、主從同步全量加載問題

3、版本升級的問題

當然,文中還提到了特定業務場景下的定制化應用.

微博是從 2010 年開始引入 Redis ,現在 Redis 已經廣泛應用于微博的多個業務場景,如關系、計數、通知提醒等,目前 Redis 集群存儲超過百億記錄,每天上萬億的讀取拜訪.

持久化問題

在我們大多數業務場景中 Redis 是當做存儲來使用,會開啟持久化機制.線上采用單機多實例的部署結構,服務器的內存使用率也會比較高.

由于官方版本觸發 bgsave 和 bgrewriteaof 操作的時間點是不可控的,依賴于相關的配置項和業務的寫入模型,因此可能會出現單機部署的多個 Redis 實例同時觸發 bgsave 或 bgrewriteaof 操作,這兩個操作都是通過 fork 出一個子進程來完成的,由于 copy-on-write 機制,可能會導致服務器內存很快耗盡, Redis 服務崩潰.

此外在磁盤壓力較大時(生成 rdb、aof 重寫),對 aof 的寫入及 fsync 操作可能會出現阻塞,雖然從 2.4 版本開始 fsync 操作調整到 bio 線程來做,主線程 aof 的寫入阻塞仍會導致服務阻塞.

主從同步問題

官方版本的主從同步機制,在網絡出現問題時(如瞬斷),會導致主從重新進行一次全量復制.

當然官方 2.8 版本支持了 psync 增量復制的機制,一定程度上解決了主從連接斷開會引發全量復制的問題

版本升級及管理問題

官方版本在執行升級操作時,需要服務重啟,我們大多數線上業務都開啟了持久化機制,重啟操作耗時較長,加上使用 Redis 業務線比較多,版本升級操作的復雜度很高.

1. 對于持久化機制,采用 rdb + aof 的持久化方式.

aof 文件按固定大小滾動,生成 rdb 文件時記錄當前 aof 的 position,全量的數據包含在 rdb 和所記錄位置點之后的 aof 文件,廢棄 aof 重寫機制,生成 rdb 后刪除無效的 aof 文件；增加了定時持久化操作的配置項 cronsave,將單機部署的多個 Redis 實例的持久化操作分散在不同的時間點進行,并且錯開業務高峰；將對 aof 的寫入操作也放到 bio 線程來做,解決磁盤壓力較大時 Redis 阻塞的問題.

2. 對于主從同步機制,借鑒 MySQL 的復制機制并做了簡化.使用 rdb + aof 的方式,支持基于 aofpositon 的增量復制

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

老楊有話說：

1、真的是業務需求推動技術變革,技術只有持續優化、改進,才能滿足業務發展需要,才能體現其價值.

2、即使是再優秀的開源產品,要拿來適配公司業務,還是要深度探究和改進才行.

3、官方提供的redis解決方案,足夠滿足中小型企業的技術要求,但是如何用到極致,還是需要優秀的人才來打磨.

4、要持久話的數據,能放到mysql就不要扔到redis,當然,除非你對redis的持久化可以像上面他們做的一樣靠譜才行.

5、個人還是更傾向于redis的緩存模式和它的多數據結構.

封面人物介紹：

拉斯姆斯·勒多夫(Rasmus Lerdorf,1968年11月22日－)是一個丹麥程序員,他擁有加拿大國籍.他就是PHP他爹,PHP的創始人,其中PHP的頭兩個版本是由他編寫的,后來他也參與PHP后續版本的開發.

誰會想到一個原本只是用來網頁拜訪跟蹤的工具,會發展成為世界上最好的語言,所以,沒事干了多寫寫代碼,萬一被成功了呢?