为何要使用redis高版本的一封说服邮件

最近公司内和OP同学针对在生产环境中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数据,4min导入。吞吐量15w/s。
 
 
v2.2导入使用plain command逐个将命令传递给redis,那么其每次发起远程调用的消耗非常大。
 
具体命令如下:
 
echo `date` > importlog2 && cat cmd.plain | redis-cli -h 10.81.31.95 -p 16379 >> importlog2 && echo `date` >> importlog2
 
耗时:3600w数据,510min导入。吞吐量1k/s。
 
 
结论:pipeline特性可以快速导入大数据,以最短最经济的方式完成任务,同时简化上线步骤,日后维护、数据迁移等工作也可以变得容易。
 
 
 
2. 其他原因
RDB文件持久化提速。
改用jemalloc的内存分配模式 是的内存碎片少,从而更节省内存。
详见链接
 
 
 
其他concern
 
Q:OP担心XX项目会带来YY数据的膨胀?
 
A:该项目目前正在kickoff阶段,倘若未来YY在业务数据量上骤增,可以启用迁移方案将redis集群迁移到内存更大的机器(会提前做好预算),迁移工作由于使用了2.4版本的pipeline特性,加之rdb持久化,可以平滑的完成,不存在复杂的迁移过程。
 
 
 
Q:为什么不用memcache?
 
A:
 
– 这个应用场景是需要满足100%命中率,因此将所有数据放入内存,实际上是将redis当做了一个K-V的DB来用,而不单纯看做一个cache。
 
– 启用持久化特性,当down机恢复,会迅速加载dump并预热。
 
– 项目组计划是将APP+DB的架构改成成为APP+CACHE+DB,因此需要将DB上的修改操作sync到NoSQL中,供业务模块快速获取数据,解决北斗“慢”的问题。
 
– Redis可以作为集中式的队列,或者一些业务不重要的数据存储介质,对于做分布式调用非常有帮助。系统一切可以用生产者消费模型替换的场景,均可以改造为使用redis,从而去除单点问题。分布式锁,pub/sub等功能更是日后可以利用的极佳功能。
 
 
另外,由于2.4是2.2版本的一个branch,是向下兼容的。
 

Leave a Comment.