• Feeds

  • Archive for January, 2011


    Redis新的存储模式diskstore

    Redis作者antirez是一个非常勤奋的开发者,在Redis性能已经非常惊人的情况下持续不断开发新的特性,比如从新的cluster源代码看到,作者已经把Dynamo及Paxos一些核心的思想考虑进去并进行了一些简洁的实现。相比其它产品如Memcached则几年没什么大变化,在Web 2.0时代,Memcached已经非常不够用,技术人员需要考虑做很多额外工作才能让Memcached适应新的变化和需求。

    antirez在1月5日Google Groups发表了一篇Redis diskstore文章,对Redis VM方式进行了反省,思考是否有更好的方式来大数据的Redis访问。

    a few months after VM started to work my feeling about it started to be not very good… that VM was not the way to go for the future of Redis

    适合Web 2.0数据访问最佳的方式就是完全基于内存,比如用Memcached或者Redis snapshot方式。但是更多的业务场景是数据规模会超过RAM容量,因此有几种不同的设计模式。

    1. VM方式。将数据分页存放,由应用(如Redis)或者操作系统(如Varnish)将访问量较少的页即冷数据swap到磁盘上,访问多的页面由磁盘自动换出到内存中。应用实现VM缺点是代码逻辑复杂,如果业务上冷热数据边界并不分明,则换入换出代价太高,系统整体性能低。不少抢鲜的网友在微博上也反馈过使用VM种种不稳定情况。操作系统实现VM的缺点前文Redis几个认识误区已经有介绍。

    2. 磁盘方式,所有的数据读写访问都是基于磁盘,由操作系统来只能的缓存访问的数据。由于现代操作系统都非常聪明,会将频繁访问的数据加入到内存中,因此应用并不需要过多特殊逻辑。MongoDB就是这种设计方式。这种方式也有一些已知的缺点,比如操作MMap写入磁盘由操作系统控制,操作系统先写哪里后写哪里应用并不知情,如果写入过程中发生了crash则数据一致性会存在问题。这个也是MongoDB饱受争议的单机Durability问题,

    MongoDB is not designed around single-server durability, but rather multi-server durability.

    不过MongoDB自己并不觉得这是一个问题,他们的意见是,在目前时代有必要考虑单机完全可靠吗?有必要吗?

    3. 硬盘存储 + cache方式。实际原理和mysql+memcache方式类似,只不过将两者功能合二为一到一个底层服务中,简化了调用。

    在上面几种方式中,除去VM,antirez觉得MongoDB方式也不太适合,因此选择了disktore方式来实现新的磁盘存储,具体细节是

    1) 读操作,使用read through以及LRU方式。内存中不存在的数据从磁盘拉取并放入内存,内存中放不下的数据采用LRU淘汰。

    2) 写操作,采用另外spawn一个线程单独处理,写线程通常是异步的,当然也可以把cache-flush-delay配置设成0,Redis尽量保证即时写入。但是在很多场合延迟写会有更好的性能,比如一些计数器用Redis存储,在短时间如果某个计数反复被修改,Redis只需要将最终的结果写入磁盘。这种做法作者叫per key persistence。由于写入会按key合并,因此和snapshot还是有差异,disk store并不能保证时间一致性。

    由于写操作是单线程,即使cache-flush-delay设成0,多个client同时写则需要排队等待,如果队列容量超过cache-max-memory Redis设计会进入等待状态,造成调用方卡住。

    Google Group上有热心网友迅速完成了压力测试,当内存用完之后,set每秒处理速度从25k下降到10k再到后来几乎卡住。 虽然通过增加cache-flush-delay可以提高相同key重复写入性能;通过增加cache-max-memory可以应对临时峰值写入。但是diskstore写入瓶颈最终还是在IO。

    3) rdb 和新 diskstore 格式关系
    rdb是传统Redis内存方式的存储格式,diskstore是另外一种格式,那两者关系如何?

    • 通过BGSAVE可以随时将diskstore格式另存为rdb格式,而且rdb格式还用于Redis复制以及不同存储方式之间的中间格式。
    • 通过工具可以将rdb格式转换成diskstore格式。

    当然,diskstore原理很美好,但是目前还处于alpha版本,也只是一个简单demo,diskstore.c加上注释只有300行,实现的方法就是将每个value作为一个独立文件保存,文件名是key的hash值。因此diskstore需要将来有一个更高效稳定的实现才能用于生产环境。但由于有清晰的接口设计,diskstore.c也很容易换成一种B-Tree的实现。很多开发者也在积极探讨使用bdb或者innodb来替换默认diskstore.c的可行性。

    在Redis几个认识误区中也介绍过,Redis优势是丰富的内存数据结构,这个特性和数据持久保存天生是矛盾的,如用diskstore保存大list/set(如排行榜)性能会很差,每修改一个list元素则需要将整个大list重新保存,开销比使用传统RDBMS高很多。

    用MongoDB的一句设计哲学结尾

    Databases are specializing – the “one size fits all” approach no longer applies.

    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中,“分库分表”应当如何实现?有什么好的设计模式?