Redis架构+实用辅助工具，逐一攻破DBA痛难点
和大家介绍常见的Redis架构、以往我在陌陌、去哪儿网做Redis时的一些经验，主要包括DBA日常维护MySQL或Redis时需要做的工作、如何根据日常工作和业务的需求来制定Redis架构，最后是分享一些好用的辅助工具，与大家共勉。
业务需求
面对业务需求（如一个业务要上Redis）时，DBA首先需要了解这个业务是干什么的。
去哪儿网有一个良好的习惯，就是DBA会深入业务线。以前我是负责机票系统的，几乎常年在机票的业务线待着，会去深入了解机票每个Redis是怎么用的，分清Redis使用时究竟是用在缓存还是存储上。
如果是用在缓存上，最大容量、报警、配置怎么配；如果是用在存储上，功能又该怎么管理。在使用缓存时是不是需要和业务沟通，每个Key有没有设置过期时间，如果没有设置，我则认为你是用来存储而不是用来缓存。
前期我们可以做一些规定，对后期管理做得比较严格，如果业务是用于存储的话，有可能导致无法写入等问题，所以一定要跟业务沟通，搞清楚业务需求的真正用途。
还有的业务需求过来，说需要600G甚至1T的容量，这时面对大容量的业务需求，我们要怎么搭建集群，并做好往后的扩容和维护。
还有的情况是业务需求容量很低，可能只需要1G，但是QPS达到了一百万，这时我们部署的多个实例，将包括这个实例怎么扩容、怎么管理，以及多个实例进来以后怎么用，这都需要有一个良好的架构。
如何解决？首先我们要了解业务，建立一些元数据。因为业务非常多，每个业务有可能对应多个集群，通过建立元数据管理，就可以在问题出现时快速联系到业务方，这需要我们配合业务去共同解决。
若是基于以前的人工运维，用自己的一些笔记或Wiki记录就足够了，但如果元数据记录到自动化管理平台，则可以把这些元数据收集起来，包括日常操作、上下实例、关闭实例、调整主从状态、清理数据等操作，这些都DBA需要去考虑。
此外，Redis后期的维护的操作能否在不影响上层业务使用的基础上简单地去做；监控报警、存储监控如何设置；高可用使用过程中机器非常多，有可能每天都会面临机器需要下线维护的情况，这时如何做在线切换；当机器宕机甚至整个机房都不可用时，如何在另一个机房快速重启……
做运维DBA是非常累的，7x24小时，光靠人来盯是不足够的，需要有良好的架构和运维平台相结合来实现快速响应。
- 存储&缓存集群设计
- 扩容
- 高可用
- 运维平台
