实践解析：大众点评账号业务高可用进阶之路

  在任何一家互联网公司，不管其主营业务是什么，都会有一套自己的账号体系。账号既是公司所有业务发展留下的最宝贵资产，它可以用来衡量业务指标，例如日活、月活、留存等，同时也给不同业务线提供了大量潜在用户，业务可以基于账号来做用户画像，制定各自的发展路径。因此，账号服务的重要性不言而喻，同时美团业务飞速发展，对账号业务的可用性要求也越来越高。本文将分享一些我们在高可用探索中的实践。

　　衡量一个系统的可用性有两个指标：

　　1. MTBF (Mean Time Between Failure)即平均多长时间不出故障;

　　2. MTTR (Mean Time To Recovery)即出故障后的平均恢复时间。

　　通过这两个指标可以计算出可用性，也就是我们大家比较熟悉的“几个9”。

　　每条监控都会根据过去的业务曲线计算出一条基线(见下图)，用来跟当前数据做对比，超出设定的阈值后就会触发告警。

　　2. 柔性可用

　　柔性可用的目的是延长不出故障的时间，当业务依赖的下游服务出故障时不影响自身的核心功能或服务。账号对上层业务提供的鉴权和查询服务即核心服务，这些服务的QPS非常高，业务方对服务的可用性要求很高，别说是服务故障，就连任何一点抖动都是不能接受的。对此我们先从整体架构上把服务拆分，其次在服务内对下游依赖做资源隔离，都尽可能的缩小故障发生时的影响范围。

　　另外对非关键路径上的服务故障做了降级。例如账号的一个查询服务依赖Redis，当Redis抖动的时候服务的可用性也随之降低，我们通过公司内部另外一套缓存中间件Tair来做Redis的备用存储，当检测到Redis已经非常不可用时就切到Tair上。

　　通过开源组件Hystrix或者我们公司自研的中间件Rhino就能非常方便地解决这类问题，其原理是根据最近一个时间窗口内的失败率来预测下一个请求需不需要快速失败，从而自动降级，这些步骤都能在毫秒级完成，相比人工干预的情况提升几个数量级，因此系统的可用性也会大幅提高。下图是优化前后的对比图，可以非常明显的看到，系统的容错能力提升了，TP999也能控制在合理范围内。

　　对于关键路径上的服务故障我们可以减少其影响的用户数。比如手机快捷登录流程里的某个关键服务挂了，我们可以在返回的失败文案上做优化，并且在登录入口挂小黄条提示，让用户主动去其他登录途径，这样对于那些设置过密码或者绑定了第三方的用户还有其他选择。

　　具体的做法是我们在每个登录入口都关联了一个计数器，一旦其中的关键节点不可用，就会在受影响的计数器上加1，如果节点恢复，则会减1，每个计数器还分别对应一个标志位，当计数器大于0时，标志位为1，否则标志位为0。我们可以根据当前标志位的值得知登录入口的可用情况，从而在登录页展示不同的提示文案，这些提示文案一共有2^5=32种。

　　3. 异地多活

　　除了柔性可用，还有一种思路可以来延长不出故障的时间，那就是做冗余，冗余的越多，系统的故障率就越低，并且是呈指数级降低。不管是机房故障，还是存储故障，甚至是网络故障，都能依赖冗余去解决，比如数据库可以通过增加从库的方式做冗余，服务层可以通过分布式架构做冗余，但是冗余也会带来新的问题，比如成本翻倍，复杂性增加，这就要衡量投入产出比。

　　目前美团的数据中心机房主要在北京上海，各个业务都直接或间接的依赖账号服务，尽管公司内已有北上专线，但因为专线故障或抖动引发的账号服务不可用，间接导致的业务损失也不容忽视，我们就开始考虑做跨城的异地冗余，即异地多活。

　　3.1 方案设计

　　首先我们调研了业界比较成熟的做法，主流思路是分set化，优点是非常利于扩展，缺点是只能按一个维度划分。比如按用户ID取模划分set，其他的像手机号和邮箱的维度就要做出妥协，尤其是这些维度还有唯一性要求，这就使得数据同步或者修改都增加了复杂度，而且极易出错，给后续维护带来困难。考虑到账号读多写少的特性(读写比是350:1)，我们采用了一主多从的数据库部署方案，优先解决读多活的问题。

　　Redis如果也用一主多从的模式可行吗?答案是不行，因为Redis主从同步机制会优先尝试增量同步，当增量同步不成功时，再去尝试全量同步，一旦专线发生抖动就会把主库拖垮，并进一步阻塞专线，形成“雪崩效应”。因此两地的Redis只能是双主模式，但是这种架构有一个问题，就是我们得自己去解决数据同步的问题，除了保证数据不丢，还要保证数据一致。

　　另外从用户进来的每一层路由都要是就近的，因此DNS需要开启智能解析，SLB要开启同城策略，RPC已默认就近访问。

　　总体上账号的异地多活遵循以下三个原则：

　　1. 北上任何一地故障，另一地都可提供完整服务。2. 北上两地同时对外提供服务，确保服务随时可用。3. 两地服务都遵循BASE原则，确保数据最终一致。

　　最终设计方案如下：

　　写并发时数据同步过程如下图：

　　我们优化的方向是在缓存加载时不同步，只有在数据库有更新时才去同步。但是数据更新这个流程里不能再使用delete操作，这样做有可能使缓存出现脏数据，比如下面这个例子：

　　从理论变为工程实现的时候还有些需要注意的地方，比如同步消息没发出去、数据收到后写失败了。因此我们还需要一个方法来检测数据不一致的数量，为了做到这点，我们新建了一个定时任务去scan两地的数据做对比统计，如果发现有不一致的还能及时修复掉。

　　项目上线后，我们也取得一些成果，首先性能提升非常明显，异地的调用平均耗时和TP99、TP999均至少下降80%，并且在一次线上专线故障期间，账号读服务对外的可用性并没有受影响，避免了更大范围的损失。

　　总结

　　服务的高可用需要持续性的投入与维护，比如我们会每月做一次容灾演练。高可用也不止体现在某一两个重点项目上，更多的体现在每个业务开发同学的日常工作里。任何一个小Bug都可能引起一次大的故障，让你前期所有的努力都付之东流，因此我们的每一行代码，每一个方案，每一次线上改动都应该是仔细推敲过的。高可用应该成为一种思维方式。最后希望我们能在服务高可用的道路上越走越远。

　　本文转载自美团技术团队微信公众号，作者: 堂堂 德鑫 杨正，转载授权请联系原创作者（meituantech）！