十问一答，助你理解Redis高可用架构和Redis运维语言API。如今，互联网业务的数据增长速度越来越快，数据类型越来越丰富，这对数据处理的速度和能力提出了更高的要求。Redis是一种开源的内存中非关系数据库，可提供颠覆性的开发人员体验。Redis从一开始就以高性能为设计理念，是当今可用的最快的NoSQL数据库。在考虑高性能的同时，高可用性也是一个重要的考虑因素。互联网7x24不间断服务，故障期间以最快的速度Failover，能给企业带来最小的损失。那么，在实际应用中有哪些高可用架构呢？这些架构的优点和缺点是什么？我们应该如何选择？最佳做法是什么？以下四个方面十个典型常见问题的解答，可以作为理解Redis高可用和Redis运维的参考。一、高可用相关1：Redis常用的高可用架构有哪些？Redis的高可用架构如下：RedisSentinel集群+内网DNS+自定义脚本RedisSentinel集群+VIP+自定义脚本封装客户端直连RedisSentinel端口JedisSentinelPool，适用于JavaPHP基于phpredis自封装RedisSentinel集群+Keepalived/HaproxyRedisM/S+KeepalivedRedisClusterTwemproxyCodis2：Redis高可用架构对比？—RedisSentinelCluster+内网DNS+CustomScript优势：秒级切换脚本定制，架构可控，对应用透明缺点：维护成本略高依赖DNS，存在解析延迟Sentinel模式存在短期服务不可用—RedisSentinel集群+VIP+自定义脚本优点：秒级切换脚本定制，架构可控，对应用透明缺点：维护成本略高Sentinel模式存在短期服务不可用-封装客户端直连RedisSentinel端口优点：服务检测故障及时DBA维护成本低缺点：依赖客户端支持SentinelSentinel服务端需要开放访问权限对应用的侵入性—RedisSentinel集群+Keepalived/Haproxy优点：二级切换对应用透明缺点：维护成本高，脑裂小号entinel模式存在短期服务不可用—RedisM/S+Keepalived优点：秒级切换对应用透明，部署方便，维护成本低缺点：需要脚本实现切换功能，有拆分-brain（redisCluster、Twemproxy、Codis优劣比较见下题）3：常见的Redis集群方案有哪些优缺点？双代理：多个同构的Twemproxy（配置相同）同时工作，接受客户端的请求，根据哈希算法转发给对应的Redis优点：开发简单，对历史悠久的应用几乎透明，解决方案成熟缺点：Proxy影响性能LVS和Twemproxy会有Node性能瓶颈Redis扩展很麻烦。Twitter已经放弃在内部使用这个解决方案。新架构不是开源的。Codis：ZooKeeper存储路由表和代理节点元数据。分发Codis-Config命令。Proxy无状态代理，兼容Redis协议，对业务透明Codis-Redis基于2.8版本，二次开发增加了slot支持和迁移命令。优点：开发简单，对应用程序几乎透明。性能优于Twemproxy。图形化界面，易扩展，运维方便缺点：Proxy还是影响了太多组件的性能，需要大量的机器资源去修改Redis代码，导致无法和官方同步，跟进慢新功能。开发组计划推广基于Redis改造的reborndbRedisCluster：P2P模式，无中心化。将key分成16384个slot，每个instance负责一部分slot。如果客户端请求不在连接的实例中，则该实例将其转发给相应的实例。通过Gossip协议同步节点信息。优点：组件一体化，易于部署，节省机器资源，性能优于代理模式，自动故障转移，Slot迁移中的数据可以使用官方原生集群方案，保证更新和支持缺点：相对较新的架构，betterpractice对fewandmanykey操作的有限支持（driver可以曲线救国）为了提升性能，client需要缓存路由表信息节点发现，reshard操作不够自动化。？观点一：Redis主要用于缓存。它具有持久性，但只是为了缓存的可靠性。优点是数据完全存储在内存中，速度快。缺点是数据大小不能超过内存大小。两者应用于不同的业务场景，Redis无法替代传统的关系型数据库。观点二：Redis首先是内存数据库，最大的优势在于效率高。尤其是在一些特定的情况下，比如热点数据量非常大，内存和磁盘之间的数据进出交换成本比较高，Redis就会体现出它的价值。传统的关系数据库在于其对数据一致性的保证。它的数据模型范式是遵循严格交易规则的结构化数据。由于其数据的高度抽象，其分派到内存的数据一般不会占用大量的内存空间。总的来说，这两种数据库都有自己的优点和缺点。不同的商务场合都有特定的追求目标。Redis优先考虑效率，适用于一些不能用简单的二维结构化数据表达的数据模型，而关系数据库处理的是二维数据，可以用范式模型表达。重要的是数据的高度一致性。随着信息技术的发展，每一种类型的数据库都会在其特定的场合中发挥其无可比拟的优势。最后的趋势是大家趋于平衡。没有绝对，只有最适合。观点三：记住一句话：任何数据库都有自己的应用场景，要注意数据的流动和数据的属性。从个人经验来看，Redis无法替代MySQL或PG。2：Redis有哪些应用场景？你能举例说明哪个公司使用它吗？Redis是一个高性能的缓存，一般用于Session缓存、队列、排行榜、计数器、近期热文、近期热评、发布订阅等，更多应用场景可以参考这里。可以说Redis适用于对数据实时性要求高，数据存储有过期和淘汰特性，不需要持久化或者只需要弱一致性，逻辑简单的场景。国内的互联网公司，据我所知基本都在用，而新浪对Redis在国内的普及起到了重要作用。另外，Redis官网有一个链接“谁在用Redis？”。3：新接手了一个复杂的Redis集群（Sentinel模式），如何理解刚刚接手了一套Redis集群，想了解这一套集群的相关配置。如何开始。是不是只能通过info命令查看各种配置？这是作者的建议：通读Sentinel官方文档：https://redis.io/topics/sentinel谷歌搜索RedisSentinel，找几篇中英文文章看看进入Sentinel集群后，使用info查看集群信息并查看Sentinel配置文件。配合文档了解各个参数的含义。使用几个虚拟机模拟线上环境，然后做测试。在实践中，大家可以深刻体会和思考现在的Sentinel集群是不是不合理。如果有，提出并改进。三、Redis故障处理1：Redis实例中，出现大量FIN_WAIT2连接ClientTCP状态转换：CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSEDServerTCP状态转换：CLOSED->LISTEN->SYNreceived->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED该状态存在于主动发起断开请求的一端。如果服务器有大量的这种状态，那么服务器就会充当客户端，比如网络爬虫。之所以这样，是因为客户端发起FIN请求结束连接后，收到服务器的响应后进入FIN_WAIT2，之后收不到服务器发送的FIN信号。PS：在线网页客户端使用什么语言？这个问题的评论值得一读：http://www.aixchina.net/Question/231035-14065752：如何知道当前Redis实例处于阻塞状态？请问各位高手，如何知道当前某个Redis实例被阻塞了呢？可以通过某个命令查询吗？解决方案，谢谢！答案1：随便拿一把钥匙，然后一直卡着就行，简单粗暴。比较优雅的一点是看latency的延迟，blocked_clients的数量，rejected_connections的数量等等。答二：方法一：登录Redis，执行info，查看blocked_clients方法二：执行redis-cli--latency-h-p查看延迟3：Redis运维有哪些故障？答1：常见的运维故障，用*号键挡库。建议使用别名来重命名此命令。超过内存使用量后，部分数据将被删除。这个有删除策略，你可以选择适合自己的。持久化，但是实例重??启，数据全部丢失——记住持久化需要开启非缓存信息RDB持久化需要vm.overcommit_memory=1，否则持久化失败。在没有持久化的情况下，master-slave，master重启太快，如果你不认为master挂了，slave会清空自己的数据——手动重启master节点前，关闭slave的同步节点。回答二：简单说一下Redis故障的排查方法。了解业务数据流如何结合Redis监控，查看QPS、缓存利用率、内存使用率等信息，确认机器层面的资源是否出现异常故障。当你及时登录机器后，使用redis-climonitor打印出操作日志。然后分析（后面分析这篇文章的失败）和R&D沟通确认是否有bigkeyblocking（bigkey也可以在日常巡检中获取）和群里的同事交流看有没有误操作和运维同事，R&D检查流量是否正常，有没有一起刷的情况。更多的调查需要对在线系统进行分析。四、Redis性能优化一：提高Redis内存数据库性能的措施有哪些？这个问题有点跑题了，来回答一下吧。整理工作中积累的经验：根据不同业务选择数据类型，必要时回顾数据结构，减少数据冗余，简化键名和键值，控制键值大小，使用前缀管理键，使用扫描而不是按键。将遍历RedisDB中所有key的操作放在客户端，避免使用O(N)复杂的命令配置。使用ziplist优化列表。合理配置maxmemory。在数据量大的情况下，做好key和value的压缩使用pipeline，batch处理命令根据不同的业务选择短链接或者长链接定期使用redis-cli--big-keys检测bigkey
