永远都不要为了目的而忘了初衷。就像给风命名的，不是它要去的方向，而是它来时的方向。（by 夏正正）
迷糊道人：道友，我听你刚刚介绍为什么使用Redis后觉得很有道理。
左羊：多谢道友认可（心想这货又想干啥？）
迷糊道人：我在想凡事有利必然有弊端，你能说说你在使用Redis的过程中遇到过什么问题吗？你都是如何解决的呢？
左羊：首先说下左羊遇到的第一个问题，"慧眼灵识分析系统"在当前阶段业务最高峰每秒大概会有50000左右的请求，有Redis扛着这些请求没有将压力推给Mysql。（这货果然无事不登三宝殿啊，妖道看法宝，哦 不不，看图看图~）
突然不知道什么原因单机Redis宕机了，导致原来可以从Redis中获取数据的请求直接去Mysql拿数据，Mysql当然扛不住这么大量的请求啊，所以紧随其后宕机了。此事件后左某羊终于明白前辈们说的缓存雪崩是啥意思了。
迷糊道人：道友，我听你这一说挺可怕啊！！！那应该预防这种事情发生呢？
左某羊：经历过上述我们团队内部根据当前系统状况决定采用Redis Cluster主从备份的方案去应对单节点Redis宕机后造成缓存雪崩击溃业务的严重生产漏洞。
就算有一个主节点宕机下面从节点们还可以通过选举的形式再次推举出一个主节点对外服务，一个主从全部宕机还有另外两个可以对系统提供服务，这样的话就保证了系统的可用性。
迷糊道人：那如果出现一些不可抗力，比如Redis所在机房管理员吃泡面汤洒到插线板上、板块运动正好把机房挤压了、机房被哥斯拉踩扁了造成Redis服务器宕机该怎么办呢？
左某羊：啊！这。。。。点也太背吧~
迷糊道人：快说，该咋整？
左某羊：最好的办法肯定是多数据中心异地容灾啊！但这样做，首先费用较高,维护难度大，对于"慧眼灵识分析系统"在当前费用紧张、人手不足的情况下肯定不适用啊。
所以我们谈论决定，如果在业务高峰期Redis集体宕机时，我们引入sentinel 对请求进行限流以保证系统正常运行。
迷糊道人：行吧！那Redis宕机后，恢复正常后丢失的数据怎么办？
左某羊：这个问题非常好，如果只是将数据存储在缓存中，那么Redis重启后数据必然丢失。所以我们在部署Redis时就启动了他的持久化机制，通过异步的方式慢慢将数据存入磁盘中，这样的话就算Redis故障了，我们也可以快速的从备份中恢复数据。
迷糊道人：还凑合吧~
