四步构建异地多活（3）

同步和访问结合方案的设计关键点如下：

• 接口访问通道和数据库同步通道不能采用相同的网络连接，不能让数据库同步和接口访问都走同一条网络通道，可以采用接口访问走公网连接，数据库同步走内网连接这种方式。
  
• 数据有路由规则，可以根据数据来推断应该访问哪个机房的接口来读取数据。例如，有3个机房A、B、C，B机房拿到一个不属于B机房的数据后，需要根据路由规则判断是访问A机房接口，还是访问C机房接口。
  
• 由于有同步通道，优先读取本地数据，本地数据无法读取到再通过接口去访问，这样可以大大降低跨机房的异地接口访问数量，适合于实时性要求非常高的数据。
  

（3）日志记录。

日志记录主要用于故障恢复后对数据进行恢复，通过在每个关键操作前后都记录相关日志，然后将日志保存在一个独立的地方，当故障恢复后，拿出日志跟数据进行对比，对数据进行修复。

为了应对不同级别的故障，日志保存的要求也不一样，常见的日志保存方式有如下几种：

• 服务器上保存日志，数据库中保存数据，这种方式可以应对单台数据库服务器故障或宕机的情况。
  
• 本地独立系统保存日志，这种方式可以应对某业务服务器和数据库同时宕机的情况。例如，服务器和数据库部署在同一个机架，或者同一个电源线路上，就会出现服务器和数据库同时宕机的情况。
  
• 日志异地保存，这种方式可以应对机房宕机的情况。
  

以上不同方式，应对的故障越严重，方案本身的复杂度和成本就会越高，实际选择时需要综合考虑成本和收益情况。

（4）用户补偿。

无论采用什么样的异常处理措施，都只能最大限度地降低受到影响的范围和程度，无法完全做到没有任何影响。例如，双同步通道有可能同时出现故障，日志记录方案本身日志也可能丢失。因此，无论多么完美的方案，故障的场景下总是可能有一小部分用户业务上出问题，系统无法弥补这部分用户的损失。但我们可以采用人工的方式对用户进行补偿，弥补用户损失，培养用户的忠诚度。简单来说，系统的方案是为了保证99.99%的用户在故障的场景下业务不受影响，人工的补偿是为了弥补0.01%的用户的损失。

常见的补偿措施有送用户代金券、礼包、礼品、红包等，有时为了赢得用户口碑，付出的成本可能还会比较大，但综合最终的收益来看还是很值得的。例如，暴雪《炉石传说》2017年回档故障，暴雪给每个用户大约价值人民币200元的补偿，结果玩家都求暴雪再来一次回档，形象地说明了玩家对暴雪补偿的充分认可。

 

接口级的故障应对方案

异地多活架构主要应对系统级的故障。例如，机器宕机、机房故障、网络故障等问题。这些系统级的故障虽然影响很大，但发生概率较小。实际业务运行过程中，还有另外一种故障影响可能没有系统级那么大，但发生的概率较高，这就是接口级的故障。

接口级故障的典型表现就是系统并没有宕机，网络也没有中断，但业务却出现问题了。例如，业务响应缓慢，大量访问超时，大量访问出现异常（给用户弹出提示“无法连接数据库”），这类问题的主要原因在于系统压力太大，负载太高，导致无法快速处理业务请求，由此引发更多的后续问题。例如，最常见数据库慢查询将数据库的服务器资源耗尽，导致读写超时，业务读写数据库时要么无法连接数据库，要么超时，最终用户看到的现象就是访问很慢，一会访问抛出异常，一会访问又是正常结果。

导致接口级故障的原因一般有如下几种：

• 内部原因
  

程序bug导致死循环，某个接口导致数据库慢查询，程序逻辑不完善导致耗尽内存，等等。

• 外部原因
  

黑客攻击、促销或抢购引入了超出平时几倍甚至几十倍的用户，第三方系统大量请求，第三方系统响应缓慢，等等。

解决接口级故障的核心思想和异地多活基本类似：优先保证核心业务，优先保证绝大部分用户。接下来我们看看具体的措施。

降级

降级指系统将某些业务或接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。例如，论坛可以降级为只能看帖子，不能发帖子；也可以降级为只能看帖子和评论，不能发评论；而App的日志上传接口，可以完全停掉一段时间，这段时间内App都不能上传日志。

降级的核心思想就是丢车保帅，优先保证核心业务。例如，对于论坛来说，90%的流量是看帖子，那我们就优先保证看帖的功能；对于一个App来说，日志上传接口只是一个辅助的功能，故障时完全可以停掉。

常见的实现降级的方式有如下几种。

• 系统后门降级
  

简单来说，就是系统预留了后门用于降级操作。例如，系统提供一个降级URL，当访问这个URL时，就相当于执行降级指令，具体的降级指令通过URL的参数传入即可。这种方案有一定的安全隐患，所以也会在URL中加入密码这类安全措施。

系统后门降级的方式实现成本低，但主要缺点是如果服务器数量多，需要一台一台去操作，效率比较低，这在故障处理争分夺秒的场景下是比较浪费的。

• 独立降级系统
  

为了解决系统后门降级方式的缺点，我们将降级操作独立到一个单独的系统中，可以实现复杂的权限管理、批量操作等功能。其基本架构如下图所示。

熔断

熔断和降级是两个比较容易混淆的概念，因为单纯从名字上看好像都有禁止某个功能的意思，但内在含义是不同的，原因在于降级的目的是应对系统自身的故障，而熔断的目的是应对依赖的外部系统故障的情况。

假设一个这样的场景：A服务的X功能依赖B服务的某个接口，当B服务的接口响应很慢的时候，A服务的X功能响应肯定也会被拖慢，进一步导致A服务的线程都被卡在X功能处理上，此时A服务的其他功能都会被卡住或响应非常慢。这时就需要熔断机制了，即A服务不再请求B服务的这个接口，A服务内部只要发现请求B服务的这个接口就立即返回错误，从而避免A服务整个被拖慢甚至拖死。

熔断机制实现的关键是需要有一个统一的API调用层，由API调用层来进行采样或统计，如果接口调用散落在代码各处就没法进行统一处理了。

熔断机制实现的另外一个关键是阈值的设计，例如，1分钟内30%的请求响应时间超过1秒就熔断，这个策略中的“1分钟”“30%”“1秒”都对最终的熔断效果有影响。实践中一般先根据分析确定阈值，然后上线观察效果，最后进行调优。

限流

降级是从系统功能优先级的角度考虑如何应对故障，而限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。

虽然“丢弃”这个词听起来让人不太舒服，但保证一部分请求能够正常响应，总比全部请求都不能响应要好得多。

限流一般都是系统内实现的，常见的限流方式可以分为两类：基于请求限流和基于资源限流。

Ÿ  基于请求限流

基于请求限流指从外部访问的请求角度考虑限流，常见的方式有限制总量和限制时间量。

限制总量的方式是限制某个指标的累积上限，常见的是限制当前系统服务的用户总量。例如，某个直播间限制总用户数上限为100万，超过100万后新的用户无法进入；某个抢购活动的商品数量只有100个，限制参与抢购的用户上限为1万名，1万名以后的用户直接拒绝。限制时间量指限制一段时间内某个指标的上限。例如，1分钟内只允许1万个用户访问，每秒请求峰值最高为10万。

无论限制总量，还是限制时间量，共同的特点都是实现简单，但在实践中面临的主要问题是比较难以找到合适的阈值。例如，系统设定了1分钟1万个用户，但实际上6000个用户的时候系统就扛不住了；也可能达到1分钟1万用户后，其实系统压力还不大，但此时已经开始丢弃用户访问了。

即使找到了合适的阈值，基于请求限流还面临硬件相关的问题。例如，一台32核的机器和64核的机器的处理能力差别很大，阈值是不同的，可能有的技术人员以为简单根据硬件指标进行数学运算就可以得出来，实际上这样是不可行的。64核的机器对比32核的机器，业务处理性能并不是2倍的关系，可能是1.5倍，甚至可能是1.1倍。

为了找到合理的阈值，通常情况下可以采用性能压测来确定阈值，但性能压测也存在覆盖场景有限的问题，可能出现某个性能压测没有覆盖的功能导致系统压力很大；另外一种方式是逐步优化，即先设定一个阈值然后上线观察运行情况，发现不合理就调整阈值。

基于上述的分析，根据阈值来限制访问量的方式更多适应于业务功能比较简单的系统，例如，负载均衡系统、网关系统、抢购系统等。

Ÿ  基于资源限流

基于请求限流是从系统外部考虑的，而基于资源限流是从系统内部考虑的，即找到系统内部影响性能的关键资源，对其使用上限进行限制。常见的内部资源有连接数、文件句柄、线程数、请求队列等。

例如，采用Netty来实现服务器，每个进来的请求都先放入一个队列，业务线程再从队列读取请求进行处理，队列长度最大值为10000，队列满了就拒绝后面的请求；也可以根据CPU的负载或占用率进行限流，当CPU的占用率超过80%的时候就开始拒绝新的请求。

基于资源限流相比基于请求限流能够更加有效地反映当前系统的压力，但实践中设计也面临两个主要的难点：如何确定关键资源和如何确定关键资源的阈值。通常情况下，这也是一个逐步调优的过程，即设计的时候先根据推断选择某个关键资源和阈值，然后测试验证，再上线观察，如果发现不合理，那么再进行优化。

排队

排队实际上是限流的一个变种，限流是直接拒绝用户，排队是让用户等待很长时间，全世界最有名的排队当属12306网站排队了。排队虽然没有直接拒绝用户，但用户等了很长时间后进入系统，体验并不一定比限流好。

由于排队需要临时缓存大量的业务请求，单个系统内部无法缓存这么多数据，一般情况下，排队需要用独立的系统去实现。例如，使用Kafka这类消息队列来缓存用户请求。

如下是1号店的“双11”秒杀排队系统架构。

其基本实现摘录如下：

 

本文小结

• 异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，多活就是指不同地理位置上的系统都能够提供业务服务。
  
• 异地多活虽然功能很强大，但也不是每个业务不管三七二十一都要上异地多。
  
• 如果业务规模很大，能够做异地多活的情况下尽量实现异地多活。
  
• 异地多活架构可以分为同城异区、跨城异地、跨国异地。
  
• 同城异区指的是将业务部署在同一个城市不同区的多个机房。
  
• 同城异区的两个机房能够实现和同一个机房内几乎一样的网络传输速度，这就意味着虽然是两个不同地理位置上的机房，但逻辑上我们可以将它们看作同一个机房。
  
• 跨城异地指的是业务部署在不同城市的多个机房，而且距离最好要远一些。
  
• 跨城异地距离较远带来的网络传输延迟问题，给业务多活架构设计带来了复杂性。
  
• 跨国异地指的是业务部署在不同国家的多个机房。
  
• 跨国异地主要适应两种场景：为不同地区的用户提供服务，为全球用户提供只读服务。
  
• 异地多活设计技巧一：保证核心业务的异地多活。
  
• 异地多活设计技巧二：保证核心数据最终一致性。
  
• 异地多活设计技巧三：采用多种手段同步数据。
  
• 异地多活设计技巧四：只保证绝大部分用户的异地多活。
  
• 接口级故障的主要应对方案：降级、熔断、限流、排队。
  
• 降级的核心思想就是丢车保帅，优先保证核心业务。
  
• 限流指只允许系统能够承受的用户量进来访问，超出系统访问能力的用户将被抛弃。
  
• 排队实际上是限流的一个变种，限流是直接拒绝用户，排队是让用户等待很长时间。