Redis使用经验

当前对Redis的使用中，几个原则：

1、数据量大时（如大于100G）Redis当做缓存来使用；

2、不使用Redis做CPU高的运算，如集合运算；

3、Redis中对Hash启动压缩时，能够节约30%左右的内存，但响应时间将会延长；

4、Redis服务器的重启成本太高；

5、产生内存碎片后，性能严重下降；

 

实践中有两种解决方案比较常用，一是修改Redis源码，针对以上问题做出相应的解决方案；二是从客户端入手，由客户端来解决。前者直接有效，但对Redis本身的侵入非常严重，可能需要单独维护一个Redis分支，并有脱离官方版本的风险；后者多了一层处理，性能可能受到影响，而且需要针对不同语言分别实现。

 

这里重点讨论一下客户端的方案，如集合运算时先从Redis中取出两个集合，然后在Java应用中做运算；如在Java应用中将数据压缩后存储到Redis中，获取是解压缩；如先自动将某部分数据从缓存模式迁移到持久化模式；

客户端方案丰富后，可以将客户端增加网络层（Redis协议的代理），从而客户端发展为代理中间层。

 

另外，当前对应对Redis本身单线程特点，经常是一台机器开启多个Redis端口。

是否真的需要一个Redis中间层？需要根据业务场景的特点做权衡，需要考虑性能、运维成本、开发难度等多方面因素。

对于key的管理，最好在程序中使用全局配置来实现，直接在代码里写前缀的做法要严格避免，这样可维护性实在太差；设计好你的Sharding机制；注意数据的持久化；

Redis实际应用案例

　　目前全球最大的Redis用户是新浪微博，在新浪有200多台物理机，400多个端口正在运行着Redis, 有+4G的数据跑在Redis上来为微博用户提供服务。

　　在新浪微博Redis的部署场景很多，大概分为如下的2种:

　　第一种是应用程序直接访问Redis数据库：

　　第二种是应用程序直接访问Redis，只有当Redis访问失败时才访问MySQL：

　　同时，Digg的一项新功能，添加了对文章浏览数的显示，这一功能的一大卖点是其实时性。而支持此实时浏览量计数的，正是Redis。