三、会员Redis缓存方案
一直以来，会员系统是不做缓存的，原因主要有两个：第一个，前面讲的ES集群性能很好，秒并发3万多，99线耗时5毫秒左右，已经足够应付各种棘手的场景。第二个，有的业务对会员的绑定关系要求实时一致，而会员是一个发展了10多年的老系统，是一个由好多接口、好多系统组成的分布式系统。所以，只要有一个接口没有考虑到位，没有及时去更新缓存，就会导致脏数据，进而引发一系列的问题，例如：用户在APP上看不到微信订单、APP和微信的会员等级、里程等没合并、微信和APP无法交叉营销等等。那后来为什么又要做缓存呢？是因为今年机票的盲盒活动，它带来的瞬时并发太高了。虽然会员系统安然无恙，但还是有点心有余悸，稳妥起见，最终还是决定实施缓存方案。
1. ES近一秒延时导致的Redis缓存数据不一致问题的解决方案
在做会员缓存方案的过程中，遇到一个ES引发的问题，该问题会导致缓存数据的不一致。我们知道，ES操作数据是近实时的，往ES新增一个Document，此时立即去查，是查不到的，需要等待1秒后才能查询到。如下图所示：
ES的近实时机制为什么会导致redis缓存数据不一致呢？具体来讲，假设一个用户注销了自己的APP账号，此时需要更新ES，删除APP账号和微信账号的绑定关系。而ES的数据更新是近实时的，也就是说，1秒后你才能查询到更新后的数据。而就在这1秒内，有个请求来查询该用户的会员绑定关系，它先到redis缓存中查，发现没有，然后到ES查，查到了，但查到的是更新前的旧数据。最后，该请求把查询到的旧数据更新到redis缓存并返回。就这样，1秒后，ES中该用户的会员数据更新了，但redis缓存的数据还是旧数据，导致了redis缓存跟ES的数据不一致。如下图所示：
面对该问题，如何解决呢？我们的思路是，在更新ES数据时，加一个2秒的redis分布式并发锁，为了保证缓存数据的一致性，接着再删除redis中该会员的缓存数据。如果此时有请求来查询数据，先获取分布式锁，发现该会员ID已经上锁了，说明ES刚刚更新的数据尚未生效，那么此时查询完数据后就不更新redis缓存了，直接返回，这样就避免了缓存数据的不一致问题。如下图所示：
上述方案，乍一看似乎没什么问题了，但仔细分析，还是有可能导致缓存数据的不一致。例如，在更新请求加分布式锁之前，恰好有一个查询请求获取分布式锁，而此时是没有锁的，所以它可以继续更新缓存。但就在他更新缓存之前，线程block了，此时更新请求来了，加了分布式锁，并删除了缓存。当更新请求完成操作后，查询请求的线程活过来了，此时它再执行更新缓存，就把脏数据写到缓存中了。发现没有？主要的问题症结就在于“删除缓存”和“更新缓存”发生了并发冲突，只要将它们互斥，就能解决问题。如下图所示：
实施了缓存方案后，经统计，缓存命中率90%+，极大缓解了ES的压力，会员系统整体性能得到了很大提升。
2. Redis双中心多集群架构
接下来，我们看一下如何保障Redis集群的高可用。如下图所示：
关于Redis集群的高可用，我们采用了双中心多集群的模式。在机房A和机房B各部署一套Redis集群。更新缓存数据时，双写，只有两个机房的redis集群都写成功了，才返回成功。查询缓存数据时，机房内就近查询，降低延时。这样，即使机房A整体故障，机房B还能提供完整的会员服务。
四、高可用会员主库方案
上述讲到，全平台会员的绑定关系数据存在ES，而会员的注册明细数据存在关系型数据库。最早，会员使用的数据库是SqlServer，直到有一天，DBA找到我们说，单台SqlServer数据库已经存储了十多亿的会员数据，服务器已达到物理极限，不能再扩展了。按照现在的增长趋势，过不了多久，整个SqlServer数据库就崩了。你想想，那是一种什么样的灾难场景：会员数据库崩了，会员系统就崩了；会员系统崩了，全公司所有业务线就崩了。想想就不寒而栗，酸爽无比，为此我们立刻开启了迁移DB的工作。
1. MySql双中心Partition集群方案
经过调研，我们选择了双中心分库分表的MySql集群方案，如下图所示：
会员一共有十多亿的数据，我们把会员主库分了1000多个分片，平分到每个分片大概百万的量级，足够使用了。MySql集群采用1主3从的架构，主库放在机房A，从库放在机房B，两个机房之间通过专线同步数据，延迟在1毫秒内。会员系统通过DBRoute读写数据，写数据都路由到master节点所在的机房A，读数据都路由到本地机房，就近访问，减少网络延迟。这样，采用双中心的MySql集群架构，极大提高了可用性，即使机房A整体都崩了，还可以将机房B的Slave升级为Master，继续提供服务。
双中心MySql集群搭建好后，我们进行了压测，测试下来，秒并发能达到2万多，平均耗时在10毫秒内，性能达标。
2. 会员主库平滑迁移方案
接下来的工作，就是把会员系统的底层存储从SqlServer切到MySql上，这是个风险极高的工作，主要有以下几个难点：
- 会员系统是一刻都不能停机的，要在不停机的情况下完成SqlServer到MySql的切换，就像是在给高速行驶的汽车换轮子。
- 会员系统是由很多个系统和接口组成的，毕竟发展了10多年，由于历史原因，遗留了大量老接口，逻辑错综复杂。这么多系统，必须一个不落的全部梳理清楚，DAL层代码必须重写，而且不能出任何问题，否则将是灾难性的。
- 数据的迁移要做到无缝迁移，不仅是存量10多亿数据的迁移，实时产生的数据也要无缝同步到mysql。另外，除了要保障数据同步的实时性，还要保证数据的正确性，以及SqlServer和MySql数据的一致性。
基于以上痛点，我们设计了“全量同步、增量同步、实时流量灰度切换”的技术方案。
首先，为了保证数据的无缝切换，采用实时双写的方案。因为业务逻辑的复杂，以及SqlServer和MySql的技术差异性，在双写mysql的过程中，不一定会写成功，而一旦写失败，就会导致SqlServer和MySql的数据不一致，这是绝不允许的。所以，我们采取的策略是，在试运行期间，主写SqlServer，然后通过线程池异步写MySql，如果写失败了，重试三次，如果依然失败，则记日志，然后人工排查原因，解决后，继续双写，直到运行一段时间，没有双写失败的情况。通过上述策略，可以确保在绝大部分情况下，双写操作的正确性和稳定性，即使在试运行期间出现了SqlServer和MySql的数据不一致的情况，也可以基于SqlServer再次全量构建出MySql的数据，因为我们在设计双写策略时，会确保SqlServer一定能写成功，也就是说，SqlServer中的数据是全量最完整、最正确的。如下图所示：
讲完了双写，接下来我们看一下“读数据”如何灰度。整体思路是，通过A/B平台逐步灰度流量，刚开始100%的流量读取SqlServer数据库，然后逐步切流量读取MySql数据库，先1%，如果没有问题，再逐步放流量，最终100%的流量都走MySql数据库。在逐步灰度流量的过程中，需要有验证机制，只有验证没问题了，才能进一步放大流量。那么这个验证机制如何实施呢？方案是，在一次查询请求里，通过异步线程，比较SqlServer和 MySql的查询结果是否一致，如果不一致，记日志，再人工检查不一致的原因，直到彻底解决不一致的问题后，再逐步灰度流量。如下图所示：
所以，整体的实施流程如下：
首先，在一个夜黑风高的深夜，流量最小的时候，完成SqlServer到MySql数据库的全量数据同步。接着，开启双写，此时，如果有用户注册，就会实时双写到两个数据库。那么，在全量同步和实时双写开启之间，两个数据库还相差这段时间的数据，所以需要再次增量同步，把数据补充完整，以防数据的不一致。剩下的时间，就是各种日志监控，看双写是否有问题，看数据比对是否一致等等。这段时间是耗时最长的，也是最容易发生问题的，如果有的问题比较严重，导致数据不一致了，就需要从头再来，再次基于SqlServer全量构建MySql数据库，然后重新灰度流量，直到最后，100%的流量全部灰度到MySql，此时就大功告成了，下线灰度逻辑，所有读写都切到MySql集群。
3. MySql和ES主备集群方案
做到这一步，感觉会员主库应该没问题了，可dal组件的一次严重故障改变了我们的想法。那次故障很恐怖，公司很多应用连接不上数据库了，创单量直线往下掉，这让我们意识到，即使数据库是好的，但dal组件异常，依然能让会员系统挂掉。所以，我们再次异构了会员主库的数据源，双写数据到ES，如下所示：
如果dal组件故障或MySql数据库挂了，可以把读写切到ES，等MySql恢复了，再把数据同步到MySql，最后把读写再切回到MySql数据库。如下图所示：
五、异常会员关系治理
会员系统不仅仅要保证系统的稳定和高可用，数据的精准和正确也同样重要。举个例子，一个分布式并发故障，导致一名用户的APP账户绑定了别人的微信小程序账户，这将会带来非常恶劣的影响。首先，一旦这两个账号绑定了，那么这两个用户下的酒店、机票、火车票订单是互相可以看到的。你想想，别人能看到你订的酒店订单，你火不火，会不会投诉？除了能看到别人的订单，你还能操作订单。例如，一个用户在APP的订单中心，看到了别人订的机票订单，他觉得不是自己的订单，就把订单取消了。这将会带来非常严重的客诉，大家知道，机票退订费用是挺高的，这不仅影响了该用户的正常出行，还导致了比较大的经济损失，非常糟糕。
针对这些异常会员账号，我们进行了详细的梳理，通过非常复杂烧脑的逻辑识别出这些账号，并对会员接口进行了深度优化治理，在代码逻辑层堵住了相关漏洞，完成了异常会员的治理工作。如下图所示：
六、展望：更精细化的流控和降级策略
任何一个系统，都不能保证百分之一百不出问题，所以我们要有面向失败的设计，那就是更精细化的流控和降级策略。
1. 更精细化的流控策略
热点控制。针对黑产刷单的场景，同一个会员id会有大量重复的请求，形成热点账号，当这些账号的访问超过设定阈值时，实施限流策略。
基于调用账号的流控规则。这个策略主要是防止调用方的代码bug导致的大流量。例如，调用方在一次用户请求中，循环很多次来调用会员接口，导致会员系统流量暴增很多倍。所以，要针对每个调用账号设置流控规则，当超过阈值时，实施限流策略。
全局流控规则。我们会员系统能抗下tps 3万多的秒并发请求量，如果此时，有个很恐怖的流量打过来，tps高达10万，与其让这波流量把会员数据库、es全部打死，还不如把超过会员系统承受范围之外的流量快速失败，至少tps 3万内的会员请求能正常响应，不会让整个会员系统全部崩溃。
2. 更精细化的降级策略
基于平均响应时间的降级。会员接口也有依赖其他接口，当调用其他接口的平均响应时间超过阈值，进入准降级状态。如果接下来 1s 内进入的请求，它们的平均响应时间都持续超过阈值，那么在接下的时间窗口内，自动地熔断。
基于异常数和异常比例的降级。当会员接口依赖的其他接口发生异常，如果1分钟内的异常数超过阈值，或者每秒异常总数占通过量的比值超过阈值，进入降级状态，在接下的时间窗口之内，自动熔断。
目前，我们最大的痛点是会员调用账号的治理。公司内，想要调用会员接口，必须申请一个调用账号，我们会记录该账号的使用场景，并设置流控、降级策略的规则。但在实际使用的过程中，申请了该账号的同事，可能异动到其他部门了，此时他可能也会调用会员系统，为了省事，他不会再次申请会员账号，而是直接沿用以前的账号过来调用，这导致我们无法判断一个会员账号的具体使用场景是什么，也就无法实施更精细的流控和降级策略。所以，接下来，我们将会对所有调用账号进行一个个的梳理，这是个非常庞大且繁琐的工作，但无路如何，硬着头皮也要做好。
