hypnos是神話中的睡神，字面意思也是希望我們工程師無需在休息時間處理任何故障。:-)
其工作原理示意如下：
Talk is cheap, show me your code! 稍后將單獨寫篇博客細致講下Hypnos的實現(xiàn)。
4.In Memory or not?
發(fā)現(xiàn)一種情況，開發(fā)在溝通后端資源設(shè)計的時候，常常因為習慣使用和錯誤了解產(chǎn)品定位等原因，而忽視了對真實使用用戶的評估。也許這是一份歷史數(shù)據(jù)，只有最近一天的數(shù)據(jù)才有人進行訪問，而把歷史數(shù)據(jù)的容量和最近一天請求量都拋給內(nèi)存類的存儲現(xiàn)實是非常不合理的。
所以當你在究竟使用什么樣的數(shù)據(jù)結(jié)構(gòu)存儲的時候，請務(wù)必先進行成本衡量，有多少數(shù)據(jù)是需要存儲在內(nèi)存中的？有多少數(shù)據(jù)是對用戶真正有意義的。因為這其實對后端資源的設(shè)計是至關(guān)重要的，1G的數(shù)據(jù)容量和1T的數(shù)據(jù)容量對于設(shè)計思路是完全不一樣的
Plans in future?
1.slave sync改造
全部改造線上master-slave數(shù)據(jù)同步機制，這一點我們借鑒了MySQL Replication的思路，使用rdb+aof+pos作為數(shù)據(jù)同步的依據(jù)，這里簡要說明為什么官方提供的psync沒有很好的滿足我們的需求：
假設(shè)A有兩個從庫B及C，及 A `— B&C，這時我們發(fā)現(xiàn)master A服務(wù)器有宕機隱患需要重啟或者A節(jié)點直接宕機，需要切換B為新的主庫，如果A、B、C不共享rdb及aof信息，C在作為B的從庫時，仍會清除自身數(shù) 據(jù)，因為C節(jié)點只記錄了和A節(jié)點的同步狀況。
故我們需要有一種將A`–B&C 結(jié)構(gòu)切換切換為A`–B`–C結(jié)構(gòu)的同步機制，psync雖然支持斷點續(xù)傳，但仍無法支持master故障的平滑切換。
實際上我們已經(jīng)在我們定制的Redis計數(shù)服務(wù)上使用了如上功能的同步，效果非常好，解決了運維負擔，但仍需向所有Redis服務(wù)推廣，如果可能我們也會向官方Redis提出相關(guān)sync slave的改進。
2.更適合redis的name-system Or proxy
細心的同學發(fā)現(xiàn)我們除了使用DNS作為命名系統(tǒng)，也在zookeeper中有一份記錄，為什么不讓用戶直接訪問一個系統(tǒng)，zk或者DNS選擇其一呢？
其實還是很簡單，命名系統(tǒng)是個非常重要的組件，而dns是一套比較完善的命名系統(tǒng)，我們?yōu)榇俗隽撕芏喔倪M和試錯，zk的實現(xiàn)還是相對復雜，我們還沒有較強的把控粒度。我們也在思考用什么做命名系統(tǒng)更符合我們需求。
3.后端數(shù)據(jù)存儲
大內(nèi)存的使用肯定是一個重要的成本優(yōu)化方向，flash盤及分布式的存儲也在我們未來計劃之中。（原文鏈接： Largest Redis Clusters Ever）
Pinterest：Reids維護上百億的相關(guān)性
Pinterest已經(jīng)成為硅谷最瘋故事之一，在2012年，他們基于PC的業(yè)務(wù)增加1047%，移動端采用增加1698%， 該年3月其獨立訪問數(shù)量更飆升至533億。在Pinterest，人們關(guān)注的事物以百億記——每個用戶界面都會查詢某個board或者是用戶是否關(guān)注的行為促成了異常復雜的工程問題。這也讓Redis獲得了用武之地。經(jīng)過數(shù)年的發(fā)展，Pinterest已經(jīng)成為媒體、社交等多個領(lǐng)域的佼佼者，其輝煌戰(zhàn)績?nèi)缦拢?/span>