观点｜“互联网Redis应用场景探讨”摘录

　　Redis是一种开源的内存非关系型数据库，给开发人员带来颠覆性的体验，在自始至终的设计过程中，都充分考虑高性能，这使得Redis成为当今速度最快的数据库之一。

　　那么，如何开始Redis学习？Redis与其他类似技术有何区别？Redis可以用于哪些应用场景？运维中应该注意什么？

　　以下内容来自社区交流“互联网Redis应用场景探讨”，供您参考。

　　主要观点分享者：

　　gaos 优酷土豆集团 数据库架构师

　　杨海朝 数据库专家

　　Lucien168 优酷 软件开发工程师

1

如何开始学习Redis？如何深入学习？自学达到什么水平可以入职？

　　目前市面上有关于redis的书，另外可以考虑先把redis.io上的documents都读一遍，记得是全部看一遍，详细看完之后一定会对redis有个比较系统的了解，脱离新手。

　　如果想深入学习源码,可以看看Redis设计与实现，以及Redis In Action等等。

　　如果想用它来工作，至少要熟悉原理，replication, aof,rdb等，会配置master/slave，熟悉数据类型，以及基本的故障处理，这些仅供参考，每个公司有不同要求。

２

选型如何考虑选MongoDB还是Redis？

　　mongodb是文档型数据库, 可以支持动态的扩张列, 支持sql语句，称为文档型的关系型数据库，如果业务量不是非常大,可以考虑用mongodb。

　　redis kv缓存, 一般是用来做缓冲, 减少对db的压力。也可以做db。具体还是得结合业务来选型。

3

Redis与cache的优劣势？

　　因为redis可以做cache也可以做存储，从降低维护成本的角度上可以考优先选择redis，如果因熟悉程度不够可以选择memcached。

4

当前Redis版本如何选择和比较？

　　如果是数据容量比较小的场景，建议用redis-2.8的release版本 redis sentinel做HA，如果数据量比较大，单机存储不下的话，可以考虑用redis-3.0的集群版本搭建。redis cluster是去中心化的redis集群，它的好处是运维管理成本比较低，数据迁移、扩容、单点故障方面都有原生支持。

5

Redis 持久化方案如何选择?

　　redis的持久化方案有两种，一种是半持久化(rdb)，一种是持久化(aof)。这个根据业务的需求来选择，如果你允许数据有丢失，可以考虑半持久化rdb，如果对数据安全性要求比较高，可以考虑采用aof方案。

6

Redis如何做大规模机器HA容灾？

　　规模大，也建议按业务分组来维护，HA方面目前有三个方面考虑：1.可以使用哨兵的方案。2.尝试使用redis cluster。3.也可以自己写工具来通过结合其自身的replication来做，譬如类似github上的redis failover工具。

7

Redis集群架构过程中运维需要关注的经验有哪些？

　　观点一：主要是内存方面、HA方面、持久化方面的高可用性管理。举个例子：如果在单机多实例上开了bgsave的话，务必要确保多个实例做bgsave时是脚本主动调度而不是Redis自动触发的。因为多个实例一旦自动触发bgsave，会造成大量随机IO导致负载升高、阻塞服务。建议在从上做bgsave，主上不做。然后加Sentinel之类的HA方案。

　　观点二：从大的方面来说，和其他存储服务没有太大区别，需要关注可用性，监控报警，数据的备份恢复，以及性能和内存容量问题，以及如何更好的使用他的问题（什么样的数据适合redis来存），大规模下还需要考虑安装部署，自动扩容，以及在做bgsave和bgrewriteaof对业务的影响问题，以及跨IDC容灾问题。等等。

8

构建大型分布式平台系统，缓存管理用Redis来实现，应该注意什么？

　　观点一：稳定性尤为重要, 以及HA故障转移, 怎么样做到平滑,尽量不影响用户。以及水平扩展性, sharding分片可以动态的迁移, 以及您可能会遇到流量倾斜,数据不均等等一些列问题。还有就是一个好的管理平台,以及监控平台，更好的去管理redis集群。

　　观点二：因是准备用于cache系统，需要考虑缓存失效的穿透问题，以及批量化管理问题，带宽，以及部署和迁移等问题。

9

Redis在使用的时候，API部分应该注意什么？

　　观点一：我们目前正在尝试做一个proxy层，对多个团队提供Restful API接口，将Redis访问封装在内部，这样如果以后架构升级，或者做冷热数据分离等，都会对调用方透明。并且HTTP协议对使用方接入成本也很低，可以跨语言调用。性能方面我们支持HTTP长连接的方式。未来也在考虑提供跨语言的RPC调用方式。

　　观点二：这个是个复杂的问题，看要解决什么问题，是解决数据治理的问题，还是解决管理员的管理问题。高性能的东西，不是非常建议使用Restfull api来访问，更多应该是在上面封装一定的业务逻辑来做。如果考虑到管理问题，如果采用的是redis3.0以前的版本，可以考虑使用twitter的proxy来做，但自己需要做一个改进，proxy无外乎解决两个问题，一个router问题，一个HA问题。　　

10

Redis和现在SSD存储方案结合，有哪些好的经验？

　　目前很多都在做类似的方案，譬如: redislabs，通过把内存相对冷的数据换出到SSD里，结合levelDB, bdb，rocksdb来做一些落地的事情，做时关注业务的应用场景，是想做通用的话，还是为了解决某一个业务场景的落地，如果通过关注LRU算法，以及换出到磁盘上数据的访问速度问题，就好了。