在缓存上，我认为一切东西都是可以被缓存的，通常我们认为缓存跟实际数据库里存在的东西可能是不一样的，有几毫秒的延迟或者怎么样，所以我们设计一个系统的时候，对一致性要求非常高的时候，会倾向于不用缓存，用数据库扛这个流量。

　　但以 MySQL 为例，InnoDB 里有一个很重要的缓存 Buffer Pool，对于一个数据库，在冷库的情况下用一堆 SQL 去查它，和慢慢预热完再查它的时候效果是不一样的，这个是我们当初在做异地多活时面临的一个问题。例如我已经有一个机房，希望建立一个新单元去承担这个机房的流量，当我建完这个单元，把所有的应用都部署好了后，把流量切 50% 过来会怎么样，假设这两个单元的机器数一样，这个单元会挂，因为这个数据库是冷的，缓存是空的，不能承担之前那个单元数据库所能承担的 QPS。

　　现在业界有很多叫 API 网关或者 CDN，他们在边缘节点也做了一层短暂的 Cache，可能只 Cache 50 或者 100 毫秒，但是当你系统受到攻击的时候可以拯救你后端的应用系统，攻击引发的命中率通常比较高，有这 50 毫秒的缓存，可能后端只有几百个 QPS 过来，那个流量你是可以承受的。

　　在高可用里两个非常经典的做法是限流和降级，在阿里双 11，有一位老兵说过一句话，他说当双 11 到来的时候，任何一个系统都可能出问题，你要做的是对你的上游限流，对你的下游限流。怎么理解，当上流的流量超过你的能力的时候就要限流，当下游比如 DBA 告诉你数据库压力很大了，那就对下游限流，只要保证住这个限流，你基本不会挂，每个系统都做到这个的时候，整个系统都是可用的。当流量超出你掌控的时候，这个做法可以让你成为这个暴风下的幸存者。

　　对限流降级的思考，第一限流降级考验的是什么问题，我认为本质上考验的是故障自恢复能力，在平时工作中会遇到机房断网或者停电，每半个月都会做断网演练，不告诉你发生什么，就把这个网切断，看你的应用 O 不 OK，一般是在晚上两三点，接到很多的机房报警，这个时候看你的架构设计的是否足够可用，如果足够可用就没问题，不会造成什么影响，继续睡觉，如果设计不好，就得爬起来立即处理。

　　而开关降级最大的作用，比如我们发现一些线上的问题，第一反映是赶紧回滚，但是当你的系统很大的时候，特别像 Java 这种，一个系统启动要启动几分钟，你的回滚完成，20 分钟都过去了，这个过程对用户来说都是有损的，而开关可以在一瞬间把所有的逻辑切到老的。这个是避免回滚时间导致的问题。开关有的时候能救命，如果没有这个开关的话，避免问题放大就只能回滚，所以开关是一个很大的价值所在。

　　容灾设计

　　另外一点非常重要的是，在设计一个技术方案的时候，就会把容灾的设计融入到方案里。比如在设计技术方案的时候，在最后一章单独有一个容灾设计，这个节点里任何服务挂掉的时候，你要保持什么样的方式保持这个服务是可用的。

　　在容灾设计时有几点必须考虑，比如我引了一个新 jar 包或者调了一个新的 RPC 的服务、引入了分布式的存储，以前没用过也不知道它稳不稳定，第一想法是它肯定会挂，它挂了我们怎么做，我们当时在做前台系统的异步化的时候，因为 Redis 支持 map 的数据结构，所以我们就是用 Redis 的 hmget 从这个 map 里拿出部分的 key 减少网卡的流量，但即使这个挂掉了，我们还会走老的 Cache，只不过网卡流量会大一些，但是对用户的服务是无损的，所以这里要考虑如果它挂了怎么做降级，有什么样的恢复流程。

　　另外是发布计划，在新系统上线时就会关注这些问题，比如这次有没有做数据迁移，比如以前我是 8 个库不够用了我拆到 16 个库或者 32 个库，中间一定是有数据迁移的，涉及到数据迁移一定要有一套对账系统保证这个数据是新数据和老数据是对得平的，不然一定有问题，因为我们是做交易相关的，订单、金额绝对不能出问题。

　　另外是你的发布顺序是不是有依赖，如果出了问题的时候，谁要先回滚，这里是取决于技术设计。另外是否要通过客服公告的方式告诉外部用户说有 5 分钟的不可用，如果真的有用户打电话有疑问客服同学可以向用户解释。

　　在高可用这个领域做久了会有一种直觉，这个直觉很重要，来源于你的经验转换成这种直觉，但是对于一个成熟的团队来说，需要把这种直觉转化为产品或工具。有很多牛人他们的技能都只能叫手艺，你需要把这种手艺转换成产品和工具。

　　公有云高可用设计

　　2015 年我去做云产品，这里给大家分享下我们是怎么样帮客户包括我们的系统在云上是做高可用的。

　　经典故障案例

　　首先看两个经典故障案例，第一个是 Gitlab 生产数据库删了，它恢复了很久，Snapshot 等全都没有生效，做了五六层的备份也都没有什么用。这个事情说明第一我们的故障要定期演练，比如中间件在做的线上故障演练，你说你的系统可用性好，我把这个主库断了，虚拟机挂掉几台试试，做这些演练就可以知道你这个容灾体系是不是可靠的，如果没有这个演练的话，当真正的故障发生时你才会发现这个东西是不 OK 的。

　　另外一个很典型的问题，Gitlab 对备份的原理是不够了解的。比如当时用的 PostgreSQL 的一个版本，当时是有问题的，没有验证，开发人员对这个又不是特别了解的情况下就会出现这个问题，这就是为什么要去了解你的依赖以及你依赖的依赖。

　　去年我们做压测，有个应用一边压测一边在优化做发布，发现第一批发的起不来了，就只是改了一两行代码加日志，他就去看什么原因，最后发现依赖的某个 jar 包依赖一个配置，而这个配置在压测中被降级了，一个 jar 包就把应用启动卡住了。如果在双十一当天或者在平时业务高峰期的时候发现这个问题是来不及修复的。所以这个时候，我们就要求，依赖的二方 jar 包必须看一下里面是怎么实现的，依赖哪些东西。

　　反过来说，别人依赖我的客户端就意味着他不仅依赖着我的服务还依赖着我的缓存，这个缓存出了问题对他也有影响，我们每年双十一前有一个强弱依赖梳理，不仅要梳理自己应用里面的，还有依赖的所有东西都梳理出来，中间任何一个节点挂掉了你应该怎么办，需要给一个明确答复。

转载请注明出处。