Redis容量及使用规划 – Tim[后端技术]

Posted on

Redis容量及使用规划 – Tim[后端技术]

Tim[后端技术]

Tim's blog, 关于后端架构、互联网技术、分布式、大型网络应用、NoSQL、技术感悟等

Home | About | English version | 留言(Guestbook) | 订阅RSS Add to Google

Redis容量及使用规划

Wednesday, Jan 5th, 2011 by Tim | Tags: memcache, memcached, mysql, redis

在使用Redis过程中，我们发现了不少Redis不同于Memcached，也不同于MySQL的特征。 (本文主要讨论Redis未启用VM支持情况)

1. Schema

MySQL: 需事先设计 Memcached: 无需设计 Redis: 小型系统可以不用，但是如果要合理的规划及使用Redis，需要事先进行类似如下一些规划

  • 数据项: value保存的内容是什么，如用户资料
  • Redis数据类型: 如String, List
  • 数据大小: 如100字节
  • 记录数: 如100万条(决定是否需要拆分)
  • ⋯⋯

上面的规划就是一种schema，为什么Redis在大型项目需要事先设计schema？因为Redis服务器有容量限制，数据容量不能超出物理内存大小，同时考虑到业务数据的可扩充性，记录数会持续增多、单条记录的内容也都会增长，因此需要提前规划好容量，数据架构师就是通过schema来判断当前业务的Redis是否需要“分库分表”以满足可扩展需求。

2. 容量及带宽规划

容量规划 MySQL: < 硬盘大小 Memcached: < RAM Redis: < RAM

带宽规划 由于Redis比MySQL快10倍以上，因此带宽也是需要事先规划，避免带宽跑满而出现瓶颈。

3. 性能规划(QPS)

当系统读写出现瓶颈，通常如何解决？ MySQL 写: 拆分到多服务器 读: (1) 拆分 (2) 写少也可以通过增加Slave来解决

Memcached 读写: 都通过hash拆分到更多节点。

Redis: 写：拆分 读: (1) 拆分 (2) 写少也可以通过增加Slave来解决

4. 可扩展性

MySQL: 分库分表 Memcached: hash分布 Redis：也可以分库，也可以hash分布

小结

通过以上分析，Redis在很多方面同时具备MySQL及Memcached使用特征，在某些方面则更像MySQL。 由于Redis数据不能超过内存大小，一方面需要进行事先容量规划，保证容量足够；另外一方面设计上需要防止数据规模无限制增加，进而导致Redis不可扩展。 Redis需要象MySQL一样预先设计好拆分方案。

小问题

在MySQL中，通过预先建立多表或者库可以在业务增长时候将这些表或库一分为二部署到更多服务器上。 在Redis中，“分库分表”应当如何实现？有什么好的设计模式？

16 Comments »

  1. ciel says:

Jan 5th 2011 at 03:41

因为自己的项目可能会用到redis, 有个小问题想问问blog主. java+redis这样的组合有没有问题, jedis适合用到生产环境去了么?

  1. gyf19 says:

Jan 5th 2011 at 09:27

目前看来 redis VM 还不靠谱。

  1. 孙立 says:

Jan 5th 2011 at 09:31

由于redis使用内存，不方便事先建立，我觉得可以才行采用虚拟node的模式来实现拆分。

  1. empyreaner says:

Jan 5th 2011 at 10:06

redis的发展非常快，现在的这些问题可能等到几个月后就都不是问题了。 redis最近几天又加了个diskstorage分支，正在测试完全使用硬盘存储全部数据，内存只作为缓存。VM也许将在未来的版本中废弃。（作者的效率太高了） redis cluster也快要出来了，可以减少人工分库分hash的麻烦。

  1. 王道中强流 says:

Jan 5th 2011 at 10:10

我喜欢MongoDB多一点

  1. 神仙 says:

Jan 5th 2011 at 10:34

redis 2.0 已经可以只把部分数据放内存了，不知道效果怎样

  1. Zoom.Quiet says:

Jan 5th 2011 at 11:17

嗯嗯嗯,我们在大规模使用 Redis时,没有深入,直接在超过1kw 时就放棄了,

  • 内存不足
  • 速度成比例下降 直接使用自定义的内存结构体,速度提高30倍… 但凡是通用的 DB类服务,都内置了N多稳定性保证的机制, 整体上就无法满足极限状态中的响应… 只要业务稳定不变,及时替换成专用内存结构很靠谱;
  • 但是,无法兼顾所有意外情况,内存泄漏问题将逐步爆发
  • 慢慢追加各种保守措施后就发觉,其实又在实现另外一个 Redis 而已…
  1. yuping322 says:

Jan 5th 2011 at 13:24

在MySQL中，通过预先建立多表或者库可以在业务增长时候将这些表或库一分为二部署到更多服务器上。 在Redis中，“分库分表”应当如何实现？有什么好的设计模式？

个人看法. redis+zookeeper。 维持一致性在zookeeper里。

  1. tony says:

Jan 6th 2011 at 11:27

redis 消耗内存很严重，用不起。

  1. KnightE says:

Jan 6th 2011 at 17:50

用HASH把绝大部分GET/SET替换后，内存节约了很多。 性能上目前还没有遇到什么问题，目前有30多个节点在线上跑。 不过通过分片（节点）存储后，sort就无法很好的使用了，这是一个目前还需要从DB走的问题，不知道Tim有什么建议。

  1. redcreen says:

Feb 27th 2011 at 17:07

@KnightE: 数据分片后无法通过规则将需要sort的数据分布到同一个节点上么?

  1. eyu says:

May 26th 2011 at 10:50

把redis原型改造成了一个消息队列服务器，但是在释放大数据量的时候出现了速度严重下滑，替换成tcmalloc后恢复正常。另外貌似存在内存泄漏的问题。。。

  1. rjgcs123 says:

May 27th 2011 at 17:13

云集国内redis大佬的QQ群正在招募各路redis朋友，不管你是正在使用redis，还是在研究redis，或者是对redis感兴趣，你都可以加入到我们的阵营。大家一起讨论redis各类用法，key-value、list、set、map使用，redis优化、内存监控、主从配置等等问题，这里都会有高手给你解决。

注意啦，国内顶尖级别的redisQQ群是 43016055

  1. Sean says:

Jun 30th 2011 at 00:24

请问现在有没有人考虑用MemBase,貌似也支持持久化缓存的.

  1. Leric says:

Nov 30th 2011 at 10:41

Redis本来就不是设计作为通用数据库用的，想把所有数据都放在redis里的企图从一开始就是错误的。个人觉得Redis用纵向扩展就行了，空间不够加内存，性能不够换机器（估计性能问题会出现在网络IO上），能遇到更庞大的数据访问问题的地方，也就得人工shard数据了。Redis的主从的主要作用在高可用性上，性能上感觉意义不大。

RSS feed for comments on this post, TrackBack URI Cancel Reply

Leave a Comment

Name (required)

E-mail (required, never displayed)

URI

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution 3.0 License

希望本站内容对您有点用处,有什么疑问或建议请在后面留言评论
转载请注明作者(RobinChia)和出处 It so life ，请勿用于任何商业用途
本文链接: Redis容量及使用规划 – Tim[后端技术]