001 微服务、分布式系统的5个经典问题说明

•订单与库存场景 

•同步调用超时 

•异步调用超时 

•掉单场景

•缓存与数据库不一致问题

面向高并发、高可用、依赖治理、持续SRE

       这些概念性专业术语，在真正工作中，或者面试的过程中，经常会有被面试官问道，你们之前的系统如何处理和解决高并发的？你们之前的服务如何保障高可用性？你说你们使用的RPC框架（如Dubbo、Thrift、ZeroCICE），那么你们的服务肯定是微服务了，你们如何解决服务之间的引用关系的，怎么去进行依赖治理的？嗯，这些都是一些比较高端的话题了，我们只能稍后根据具体场景和业务去详细讲解说明咯，针对于这几点我们先简单介绍下，在高并发、高可用环境下必要的事情；

•首先，高并发，意味着QPS达到每秒几千甚至上万或者更高，这个时候非常考验我们业务代码的性能以及逻辑。在高并发服务下我们应该怎么去做，避免什么？需要几个方面点去综合考量。

•高可用的服务，就意味着服务不存在单点问题，并且核心链路必须有对应的降级点，降级策略和手段，我们在传统行业中串行化的业务相对简单，不需要有这些特性。（核心链路：重要的核心模块整体的调用链即核心链路，例如，电商平台用户从下订单到支付完成即为核心链路；）【高可用服务重要是要考虑降级策略，保障核心业务能够最终完成；例如，A调用B，在B服务超时及无法完成的情况下提供兜底策略，降级策略，B调用不了，调用C，C也可以委婉的完成核心服务，这才是高可用】

•对于服务的依赖治理，我们必须梳理出业务核心的相互依赖关系、依赖点，这些地方是否可以进行强弱划分，强依赖需要怎么去做，弱依赖需要怎么去做，都是我们面对高并发场景下需要考虑的问题。（强依赖调用失败，可以采用快速失败的手段或异步发送消息然后补偿手段；弱依赖调用失败，可以采用降级、兜底策略）

•SRE是什么？就是针对服务的稳定、可靠、可用性的持续运维和优化工作。

分布式系统的一致性问题

        一致性是一个抽象的、具有多重含义的概念，在不同的应用场景有不同的定义和含义。在传统IT行业我们所熟知的一致性通常指的是强一致性，而在互联网行业一致性的含义远远超过了强一致性的难度和复杂度。

        首先我们要了解互联网行业的特点，往往是信息量巨大，需要非常强大的计算能力，不但要求对用户的响应足够快，还要求吞吐量指标，比如TP99（百次中99成功） TP999（千次中999成功）等等，要求都是非常的高。互联网行业的系统架构往往都是分布式的，整个业务非常复杂。我们做为架构这么复杂的系统，往往对一致性这个问题要考虑的问题非常的多，且大多数互联网公司都是采取弱一致性的设计理念。

 •一致性方案重要性：

•第一点，最主要是经常会面临一些分布式的场景，如何确保其状态、和数据的一致性。

•第二点，面对一致性的问题，如何去对具体的场景进行架构设计才能更优雅，更可靠，更稳妥。

 

•Q1：关于下订单和扣库存

        电商系统中有一个很经典的案例，就是下订单和扣库存如何保持一致。如果先下订单，扣库存失败，则将会导致超卖；如果下订单不成功，扣库存成功，则会导致少卖。无论哪种情况都会导致运营成本增加或者导致赔付。 

下订单和扣库存是由两个服务完成，那么如何保证两个服务的一致性？

•Q2：同步调用超时问题

        服务化的系统间调用常常因为网络原因导致系统调用超时，即时网络状况很好的机房，在亿级别的流量冲击下，同步调用超时也是家常便饭，系统A同步调用系统B时，系统A可用明确得到超时反馈，但是无法确定系统B是否已经完成了预设的功能和逻辑（两个相同调用过程中，A有超时时间限制，做超时限制都不会对下游做，而是对自己本身做，目的在于不能因为下游问题而影响上游系统，普适化技术实现逻辑），或者是持久化操作。于是系统A不知道应该继续做什么，如何反馈给使用方。

R读请求：

        入口端请求A服务，AM1方法调用B服务R读请求，成功后顺序执行AM2和AM3方法，所以要设置每个方法的超时策略和熔断策略，否则会阻塞在调用过程中；AM1方法设置熔断方案（可重试3次，每次超时50MS），方案一，快速失败，如果超时B服务快速发送消息给AM1方法，然后AM1方法向入口端返回失败；方案二，调用B超时失败后，AM1启动降级策略，调用降级服务保障程序继续执行下去。

W写请求：

        入口端请求A服务，AM1方法调用B服务W写请求，那么就会出现问题，系统无法获取到返回值，不知是该快速失败还是启动降级策略（实际场景具体分析）。

•Q3：异步回调超时问题

        这种场景是一个受理模式的场景，使用了异步回调返回处理的结果，系统A同步调用系统B发起指令，系统B采用受理模式，受理后则返回成功信息，然后系统B处理后异步通知系统A处理结果。在这个过程中，如果系统A由于某种原因迟迟 没有收到回调结果，那么两个系统间的状态就不一致了，相互认知的状态不同会导致系统间发生错误，在严重情况下会影响核心链路上的交易的状态准确性，甚至导致资金损失、赔付。

•Q4：关于掉单问题

        在分布式系统中，两个系统协作处理一个流程，分别为对方的上下游，如果一个系统中存在一个请求，另外一个系统不存在，则会导致掉单，掉单后果很严重，一般都会导致资金损失。

•Q5：缓存和数据库不一致

        我们在互联网行业通常由于高并发和大数据的场景，往往通过缓存来解决一些比较棘手的问题，比如用户的快速响应问题，比如对读要求极高的场景，一般服务于这些场景的数据库是难以抗住如此高的读流量的，通常都会在前面加一层缓存，那么缓存和数据库之间的数据如何保持一致性？