当前对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中间层？需要根据业务场景的特点做权衡，需要考虑性能、运维成本、开发难度等多方面因素。