Redis是一个用ANSIC语言编写的开源日志型和Key-Value数据库，支持网络型、内存型和持久化，并提供多语言API.如今，互联网业务的数据增长速度越来越快，数据类型越来越丰富，这对数据处理的速度和能力提出了更高的要求。Redis是一种开源的内存中非关系数据库，可提供颠覆性的开发人员体验。Redis从一开始就以高性能为设计理念，是当今可用的最快的NoSQL数据库。在考虑高性能的同时，高可用性也是一个重要的考虑因素。互联网7x24不间断服务，故障期间以最快的速度Failover，能给企业带来最小的损失。那么，在实际应用中，高可用架构有哪些呢？这些架构的优点和缺点是什么？我们应该如何选择？最佳做法是什么？以下四个方面十个典型和普遍问题的解答，可以作为理解Redis高可用和Redis运维的参考。一、高可用相关1：Redis常用的高可用架构有哪些？Redis的高可用架构如下：RedisSentinel集群+内网DNS+自定义脚本RedisSentinel集群+VIP+自定义脚本封装客户端直连RedisSentinel端口JedisSentinelPool，适用于JavaPHP自封装的RedisSentinel集群基于phpredis+Keepalived/HaproxyRedisM/S+KeepalivedRedisClusterTwemproxyCodis2：Redis高可用架构优缺点对比？—RedisSentinel集群+内网DNS+自定义脚本优点：秒级切换脚本定制、架构可控，对应用透明缺点：维护成本略高依赖DNS，存在解析延迟Sentinel模式存在短期服务不可用—RedisSentinel集群+VIP+自定义脚本优点：秒级切换脚本定制，架构可控并且对应用程序透明缺点：略维护成本较高Sentinel模式存在短期服务不可用——封装客户端直连RedisSentinel端口优点：服务检测故障及时DBA维护成本低缺点：依赖客户端支持SentinelSentinelserver需要开放访问权限，是对应用的侵入性—RedisSentinel集群+Keepalived/Haproxy优点：秒级切换对应用透明缺点：维护成本高，脑裂Sentinel模式存在短期服务不可用—RedisM/S+Keepalived的优点：秒级-电平切换对应用透明，易于部署，维护成本低。缺点：需要脚本来实现切换功能。Twemproxy：多同构Twemproxy（配置相同）同时工作，接受客户端的请求，根据哈希算法转发给对应的Redis。优点：开发简单，对应用几乎透明，历史悠久，方案成熟缺点：Proxy影响性能LVS和Twemproxy会有节点性能瓶颈Redis扩展很麻烦。Twitter已经放弃在内部使用这个解决方案。新架构不是开源的。Codis：ZooKeeper存储路由表和代理节点元数据。分发Codis-Config命令。Codis-Config集成管理工具，有web界面Codis-Proxy无状态代理，兼容Redis协议，对业务透明Codis-Redis基于2.8版本，二次开发增加slot支持和迁移命令优点：开发简单，对应用几乎透明性能优于Twemproxy图形化界面，易扩展，运维方便缺点：Proxy组件还是太多影响性能，需要大量机器资源修改Redis代码，导致无法与官方同步，以及新功能跟进缓慢。开发团队准备推广基于Redis改造的reborndbRedisCluster：P2P模式，无中心化。将key分成16384个slot，每个instance负责一部分slot。如果客户端请求不在连接的实例中，则该实例将其转发给相应的实例。通过Gossip协议同步节点信息。优点：组件一体化，易于部署，节省机器资源，性能优于代理模式，自动故障转移，Slot迁移中的数据可以使用官方原生集群方案，保证更新和支持缺点：相对较新的架构，更好的做法有限支持少和多的关键操作（驱动可以曲线救国）为了提高性能，客户端需要缓存路由表信息节点发现，reshard操作不够自动化2.Redis综合1：与MySQL、PostgreSQL相比，Redis的优缺点是什么？观点1：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集群是不是不合理。有的话建议改进的地方3.Redis故障排除1：Redis实例中，有大量的FIN_WAIT2连接客户端TCP状态转换：CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED服务器TCP状态迁移：CLOSED->LISTEN->SYNreceived->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED该状态存在于主动发起断开请求的一端。如果服务器上有大量的这个状态，那么这个服务器就会充当客户端的角色，比如网络爬虫，出现是因为客户端发起FIN请求结束连接后，收到后进入FIN_WAIT2服务器的响应，然后没有收到服务器发送的FIN信号。PS：在线网页客户端使用什么语言？这个问题的评论值得一看：http://www.aixchina.net/Question/231035-14065752：如何知道当前Redis实例处于阻塞状态？请问各位高手，通过什么方法可以知道某个Redis实例当前被阻塞了呢？是不是可以通过某个命令查出来呢？解决了，谢谢！答案1：随便拿一个key，然后直接卡住，简单粗暴。比较优雅的一点是看latency的延迟，blocked_clients的数量，rejected_connections的数量等等。答二：方法一：登录Redis，执行info，查看blocked_clients方法二：执行redis-cli--latency-h-p查看延迟3：Redis运维有哪些故障？答1：运维常见故障用*号键挡库。建议使用别名来重命名此命令。超过内存使用量后，部分数据将被删除。这有一个删除策略。选择一个适合你的。您不能启用持久??性，而是重新启动实例。所有数据丢失——记住持久化RDB持久化需要开启非缓存信息，持久化需要vm.overcommit_memory=1，否则持久化失败这种情况下，slave会清空自己的数据——再人为重启主节点，先关掉从节点的同步回答2：简单说一下Redis故障的排查方法。了解业务数据流如何结合Redis监控，查看QPS、缓存利用率、内存使用率等信息，确认机器层面的资源是否出现异常故障。当你及时登录机器后，使用redis-climonitor打印出操作日志。然后分析（事后分析这个项目失效）和研发沟通确认是否有大key被挡住（大key也可以在日常巡检中获取）和群里的同事沟通看有没有误操作，运维同事，和R&D检查流量是否正常，有没有一起刷的情况。更多的调查需要对在线系统进行分析。四、Redis性能优化一：提高Redis内存数据库性能的措施有哪些？这个问题有点跑题了，就来回答一下吧。整理工作中积累的经验：根据不同业务选择数据类型，必要时回顾数据结构，减少数据冗余，简化键名和键值，控制键值大小，使用前缀管理键，使用扫描而不是按键。将遍历RedisDB中所有key的操作放在客户端，避免使用O(N)复杂的命令配置。使用ziplist优化列表。合理配置maxmemory。在数据量大的情况下，做好key和value的压缩使用pipeline，batch处理命令根据不同的业务选择短链接或者长链接定期使用redis-cli--big-keys检测bigkey
