当前位置:Gxlcms > mysql > 为何要使用redis高版本的一封说服邮件

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

时间:2021-07-01 10:21:17 帮助过:64人阅读

最近公司内和OP同学针对在生产环境中redis的版本存在分歧,写了一封邮件来说服OP。文中提及了为何要使用redis2.4版本而不是2.2,以及解决他人的concern,先阐述过人的feature,再娓娓道来他人的concern并提出解决方法,最终OP还是compromise了,算是胜仗,这

最近公司内和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,是向下兼容的。

?

人气教程排行