為何要使用redis高版本的一封說服郵件

最近公司內和OP同學針對在生產(chǎn)環(huán)境中redis的版本存在分歧，寫了一封郵件來說服OP。文中提及了為何要使用redis2.4版本而不是2.2，以及解決他人的concern，先闡述過人的feature，再娓娓道來他人的concern并提出解決方法，最終OP還是compromise了，算是勝仗，這

最近公司內和OP同學針對在生產(chǎn)環(huán)境中redis的版本存在分歧，寫了一封郵件來說服OP。文中提及了為何要使用redis2.4版本而不是2.2，以及解決他人的concern，先闡述過人的feature，再娓娓道來他人的concern并提出解決方法，最終OP還是compromise了，算是勝仗，這里記錄下。

?

Dear Operation System同學,

?

先感謝OP同學提供給RD使用Redis的支持工作。對于Redis使用2.4.14還是2.2版本，詳設評審時存在分歧。RD在多方面權衡下還是堅持使用2.4版本，其帶來的好處一一道來。

?

1. 快速的導入

v2.4導入可以使用pipeline模式，在命令行即可以將raw command通過管道直接傳遞給redis-cli客戶端批量導入。

?

具體命令如下：

?

echo `date` > importlog && ?cat cmd.raw | redis-cli -h 10.81.31.95 -p 16379 –pipe >> importlog && echo `date` >> importlog

?

耗時：3600w數(shù)據(jù)，4min導入。吞吐量15w/s。

?

?

v2.2導入使用plain command逐個將命令傳遞給redis，那么其每次發(fā)起遠程調用的消耗非常大。

?

具體命令如下：

?

echo `date` > importlog2 && cat cmd.plain | redis-cli -h 10.81.31.95 -p 16379 >> importlog2 && echo `date` >> importlog2

?

耗時：3600w數(shù)據(jù)，510min導入。吞吐量1k/s。

?

?

結論：pipeline特性可以快速導入大數(shù)據(jù)，以最短最經(jīng)濟的方式完成任務，同時簡化上線步驟，日后維護、數(shù)據(jù)遷移等工作也可以變得容易。

?

?

?

2. 其他原因

RDB文件持久化提速。

改用jemalloc的內存分配模式 是的內存碎片少，從而更節(jié)省內存。

…

詳見鏈接

?

?

?

其他concern

?

Q：OP擔心XX項目會帶來YY數(shù)據(jù)的膨脹？

?

A：該項目目前正在kickoff階段，倘若未來YY在業(yè)務數(shù)據(jù)量上驟增，可以啟用遷移方案將redis集群遷移到內存更大的機器(會提前做好預算)，遷移工作由于使用了2.4版本的pipeline特性，加之rdb持久化，可以平滑的完成，不存在復雜的遷移過程。

?

?

?

Q：為什么不用memcache？

?

A：

?

- 這個應用場景是需要滿足100%命中率，因此將所有數(shù)據(jù)放入內存，實際上是將redis當做了一個K-V的DB來用，而不單純看做一個cache。

?

- 啟用持久化特性，當down機恢復，會迅速加載dump并預熱。

?

- 項目組計劃是將APP+DB的架構改成成為APP+CACHE+DB，因此需要將DB上的修改操作sync到NoSQL中，供業(yè)務模塊快速獲取數(shù)據(jù)，解決北斗“慢”的問題。

?

- Redis可以作為集中式的隊列，或者一些業(yè)務不重要的數(shù)據(jù)存儲介質，對于做分布式調用非常有幫助。系統(tǒng)一切可以用生產(chǎn)者消費模型替換的場景，均可以改造為使用redis，從而去除單點問題。分布式鎖，pub/sub等功能更是日后可以利用的極佳功能。

?

?

另外，由于2.4是2.2版本的一個branch，是向下兼容的。

?

原文地址：為何要使用redis高版本的一封說服郵件, 感謝原作者分享。

聲明：本網(wǎng)頁內容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com