|
谈到缓存，Cache 里有一些小技巧，在做双十一备战时发现一个店铺的基础服务平时每天日常就有 100 亿的调用量，当时是几十台机器估了一下可能要成倍增长，成本是非常高的，怎么解决这个问题，当时写了个富客户端，让业务方先去查我们分布式 Cache，如果命中就直接返回来，如果不命中再走我们的服务端查。这种情况下，只要你能够保证命中率足够高，比如 98% 的命中率，就意味着只有 2% 是需要后端服务器承担剩下的请求，用非常少的服务器去承担非常大的流量，这是成本和性能间的权衡。 在缓存方面，我们很少会关心缓存的高可用是怎么部署的，它是一个偏运维的内容，我把缓存的部署简化成一个双机房的模型，因为它在高可用里是最简单的场景。 对于缓存来说有两种经典部署模式，第一种叫共享集群部署，在 IDC 里我的应用是分机房部署的，Cache 集群也是分机房部署，对于应用服务器来说，两边的 Cache 对他来说逻辑上是一个集群，会往 IDC 1 的 Cache 写一半过去，往 IDC 2 也写一半过去，这种部署的好处在于，机房间网络断掉的时候，有一半的数据是在缓存的，保证一半的数据能够命中，不会直接死掉，另外对成本上相对比较友好，没有浪费任何一个 Cache 的节点，这个 Cache 本身是复用的。 但是也正如刚才说的问题，如果中间断掉了，有一半的命中率是有损的，所以就诞生了另外的一个部署模式，就是独立部署，不管你哪个机房挂掉，命中率是基本不变的，两边同时保持了 98% 的命中率，但是它是成本不友好的，两边要同时部署，同时承担副本的作用，并且失效时，要同时失效另外一个 IDC 2，这样才保证一致性。 在缓存上，我认为一切东西都是可以被缓存的，通常我们认为缓存跟实际数据库里存在的东西可能是不一样的，有几毫秒的延迟或者怎么样，所以我们设计一个系统的时候，对一致性要求非常高的时候，会倾向于不用缓存，用数据库扛这个流量。 但以 MySQL 为例，InnoDB 里有一个很重要的缓存 Buffer Pool，对于一个数据库，在冷库的情况下用一堆 SQL 去查它，和慢慢预热完再查它的时候效果是不一样的，这个是我们当初在做异地多活时面临的一个问题。例如我已经有一个机房，希望建立一个新单元去承担这个机房的流量，当我建完这个单元，把所有的应用都部署好了后，把流量切 50% 过来会怎么样，假设这两个单元的机器数一样，这个单元会挂，开奖，因为这个数据库是冷的，缓存是空的，不能承担之前那个单元数据库所能承担的 QPS。 现在业界有很多叫 API 网关或者 CDN，他们在边缘节点也做了一层短暂的 Cache，可能只 Cache 50 或者 100 毫秒，但是当你系统受到攻击的时候可以拯救你后端的应用系统，攻击引发的命中率通常比较高，有这 50 毫秒的缓存，可能后端只有几百个 QPS 过来，那个流量你是可以承受的。 在高可用里两个非常经典的做法是限流和降级，在阿里双 11，有一位老兵说过一句话，他说当双 11 到来的时候，任何一个系统都可能出问题，你要做的是对你的上游限流，对你的下游限流。怎么理解，当上流的流量超过你的能力的时候就要限流，当下游比如 DBA 告诉你数据库压力很大了，那就对下游限流，只要保证住这个限流，你基本不会挂，每个系统都做到这个的时候，整个系统都是可用的。当流量超出你掌控的时候，这个做法可以让你成为这个暴风下的幸存者。
对限流降级的思考，第一限流降级考验的是什么问题，我认为本质上考验的是故障自恢复能力，在平时工作中会遇到机房断网或者停电，每半个月都会做断网演练，不告诉你发生什么，就把这个网切断，看你的应用 O 不 OK，一般是在晚上两三点，接到很多的机房报警，这个时候看你的架构设计的是否足够可用，如果足够可用就没问题，不会造成什么影响，继续睡觉，如果设计不好，就得爬起来立即处理。 而开关降级最大的作用，比如我们发现一些线上的问题，第一反映是赶紧回滚，但是当你的系统很大的时候，特别像 Java 这种，一个系统启动要启动几分钟，你的回滚完成，20 分钟都过去了，这个过程对用户来说都是有损的，而开关可以在一瞬间把所有的逻辑切到老的。这个是避免回滚时间导致的问题。开关有的时候能救命，如果没有这个开关的话，避免问题放大就只能回滚，所以开关是一个很大的价值所在。 容灾设计
|
