避免误用Redis

　　Redis是目前NoSQL领域的当红炸子鸡，它象一把瑞士军刀，小巧、锋利、实用，特别适合解决一些使用传统关系数据库难以解决的问题。但是Redis不是银弹，有很多适合它解决的问题，但是也有很多并不适合它解决的问题。另外，Redis作为内存数据库，如果用在不适合的场合，对内存的消耗是很可观的，甚至会让系统难以承受。

　　我们可以对系统存储使用的数据以两种角度分类，一种是按数据的大小划分，分成大数据和小数据，另一种是按数据的冷热程度划分，分成冷数据和热数据，热数据是指读或写比较频繁的数据，反之则是冷数据。

　　可以举一些具体的例子来说明数据的大小和冷热属性。比如网站总的注册用户数，这明显是一个小而热的数据，小是因为这个数据只有一个值，热是因为注册用户数随时间变化很频繁。再比如，用户最新访问时间数据，这是一个量比较大，冷热不均的数据，大是数据的粒度是用户级别，每一个用户都有数据，如果有一千万用户，就意味着有一千万的数据，冷热不均是因为活跃用户的最新访问时间变化很频繁，但是可能有很大一部非活跃用户访问时间长时间不会发生变化。

　　大体而言，Redis最适合处理的是小而热，而且是写频繁，或者读写都比较频繁的热数据。对于大而热的数据，如果其它方式很难解决问题，也可以考虑使用Redis解决，但是一定要非常谨慎，防止数据无限膨胀。原因如下：

　　首先，对于冷数据，无论大小，都不建议放在Redis中。Redis数据要全部放在内存中，资源宝贵，把冷数据放在其中实在是一种浪费，冷数据放在普通的存储比如关系数据库中就好了。

　　其次，对于热数据，尤其是写频繁的热数据，如果量比较小，是最适合放到Redis中的。比如上面提到的网站总的注册用户数，就是典型的Redis用做计数器的例子。再比如论坛最新发表列表，最新报名列表，可以控制数量在几百到一千的规模，也是典型的redis做最新列表的使用方式。

　　另外，对于量比较大的热数据（或者冷热不均数据），使用Redis时一定要比较谨慎。这种类型数据很容易引起数据膨胀，导致Redis消耗内存巨大，让系统难以承受。薄荷的一个惨痛教训是把用户关注（以及被关注）数据放在Redis中，这是一种数据量极大，冷热很不均衡的数据，在几百万的用户级别就占用了近10GB左右内存，让Redis变得难以应付。应对这种类型的数据，可以用普通存储+缓存的方式。

　　如果用对了地方，比如在小而热的数据情形，Redis表现很棒，如果用错了地方，Redis也会带来昂贵的代价，所以使用时务必谨慎。

　　当然，大家也可以参考一下七个原则：

　　1：Redis是一个操作数据结构的DSL工具,它提供基于TCP的协议以操作丰富的数据结构

　　2：Redis是一个内存数据库,正是由于内存的快速访问特性,才使得Redis能够有如此高的性能

　　3：使用基础的API操作基础的数据结构,Redis的API与数据结构一样,都是一些最基础的元素,你几乎可以将任何信息交互使用此API格式表示

　　4：有着优雅的代码,经常有一些不太了解Redis有的人会建议Redis采用一些其它人的代码,以实现一些Redis未实现的功能，是不可取的

　　5：我们反对复杂化，我们认为设计一个系统的本质，是与复杂化作战。我们不会为了一个小功能而往源码里添加上千行代码

　　6：支持两个标准的API,第一套标准只包含部分操作API,但支持分布式环境下的Redis。第二套标准的API支持更复杂的multi-key操作

　　7：我们以优化代码为乐,我们相信编码是一件辛苦的工作,唯一对得起这辛苦的就是去享受它

　　小编结语：

　　更多内容尽在课课家教育！