服务雪崩简单的介绍

定义

服务雪崩效应是一种因“服务提供者的不可用”（原因）导致“服务调用者不可用”（结果），并将不可用逐渐放大的现象。如下图所示：

上图中, A为服务提供者, B为A的服务调用者, C和D是B的服务调用者. 当A的不可用,引起B的不可用,并将不可用逐渐放大C和D时, 服务雪崩就形成了。
形成原因
服务雪崩的过程可以分为三个阶段：

1. 服务提供者不可用；
2. 重试加大请求流量；
3. 服务调用者不可用；
   服务雪崩的每个阶段都可能由不同的原因造成，总结如下：
   
   应对策略
   一开始你的服务能考虑抗住高并发吗？
   成本的增加： 开发成本 硬件成本 - 我要抗住高并发 - 10W - 500，即使是淘宝这种 平时的流量和双11的流量差异就很大我们现在考虑到我今年可能出现一次高并发 1W - 我全年的服务都部署成可以抗住1W并发 - 500 - 1k某个时候出现了流量的猛增 - 2k

限流 - 2k 但是我的服务能力只有1k，所以这个时候多出来的流量怎么办： 1. 拒绝 2. 排队等待
用户体验不太好： 当前访问用户过多，请稍后重试 和 你的服务直接挂了
用户体验降级了 - 原本是访问流畅，下单流畅 -> 当前访问用户过多，请稍后重试
熔断 - 比如A服务访问B服务，这个时候B服务很慢 - B服务压力过大，导致了出现了不少请求错误，调用方很容易出现一个问题： 每次调用都超时 2k，结果这个时候数据库出现了问题，
超时重试 - 网络 2k的流量突然变成了3k这让原本就满负荷的b服务雪上加霜，如果这个时候调用方有一种机制：比如说 1. 发现了大部分请求很慢- 50%请求都很慢， 2. 发现我的请求有50%都错误了 3. 粗我数量很多，比如1s出现了20个错误
熔断 - 1. 保险丝 2. 股市熔断

超时
timeout是为了保护服务，避免consumer(消费者)服务因为provider (提供者)响应慢而也变得响应很慢，这样consumer可以尽量保持原有的性能。
重试—>保证正确性
如果provider只是偶尔抖动，那么超时后直接放弃，不做后续处理，就会导致当前请求错误，也会带来业务方面的损失。对于这种偶尔抖动，可以在超时后重试一下，重试如果正常返回了，那么这次请求就被挽救了，能够正常给前端返回数据，只不过比原来响应慢一点。重试可以考虑切换一台机器来进行调用，因为原来机器可能由于临时负载高而性能下降，重试会更加剧其性能问题，而换一台机器，得到更快返回的概率也更大一些。
幂等–>同样的数据提交两次，因为重试机制调用了多次，数据库中只有一份数据
如果允许consumer重试，那么provider就要能够做到幂等。同一个请求被consumer多次调用，对provider产生的影响是一致的。而且这个幂等应该是服务级别的，而不是某台机器层面的，重试调用任何一台机器，都应该做到幂等。

哪些情况下需要考虑幂等性 - 同样的请求发送多次：

1. http请求的类型：
   1. get
      1. 获取商品信息， 这个会引起商品的数据的变化吗？
   2. post
      1. 比较常见，这种接口需要考虑到幂等性–>比如创建商品
   3. put
      1. 不一定要实现幂等性
         1. put 把1号商品的价格改为200，网络返回的时候抖动了，重试
         2. 第二次接口还是会把1号商品的价格改为200 - 这种情况下没有幂等的问题
      2. 出现幂等性问题的情况：
         1. 购物车中的商品，调用一次 这个商品的数量加一
            1. 第一次调用 原本的值 10 之后价格变为11 - 但是返回的时候出现了网络抖动
            2. 第二次发送 原本的值 11 之后价格变为12 - 但是返回的时候出现了网络抖动
            3. 第三次发送 原本的值 12 之后价格变为13- 但是返回的时候出现了网络抖动
   4. delete
      1. 一般不具备幂等性的要求
      2. 第一次调用 删除数据
      3. 第二次调用 还是删除当前的数据

现在假设，你自己开发了一个支付宝，然后别人在二维码支付页面，先支付了，结果由于网络问题，当前页面一直没有刷新，就让人以为我没有支付，然后我就再次扫码支付，这下完蛋了：你扣了两次款。

一、背景
**我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。 **
get请求一般没有幂等性需求、delete请求一般也没有幂等性需求，post、update视情况而定****例如：

1. 前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果。
2. 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱；
3. 发送消息，也应该只发一次，同样的短信发给用户，用户会哭的；
4. 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题。 等等很多重要的情况，这些逻辑都需要幂等的特性来支持。

二、幂等性概念
幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()和setTrue()”函数就是一个幂等函数.

更复杂的操作幂等保证是利用唯一交易号(流水号)实现. 我的理解：幂等就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的

三、技术方案

1. 查询操作
   查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select是天然的幂等操作

2. 删除操作
   删除操作也是幂等的，删除一次和多次删除都是把数据删除。(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个)
   1.唯一索引，防止新增脏数据
   比如：新建用户的时候将手机号码设置为唯一索引，那么即使你重试，也只会新建一个用户，不会因为重试导致当前用户注册了两个用户
   要点：
   唯一索引或唯一组合索引来防止新增数据存在脏数据
   （当表存在唯一索引，并发时新增报错时，再查询一次就可以了，数据应该已经存在了，返回结果即可）
   2. token机制，防止页面重复提交
   业务要求：
   页面的数据只能被点击提交一次
   发生原因：
   由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交
   解决办法：
   集群环境：采用token加redis（redis单线程的，处理需要排队）

   1. 数据提交前要向服务的申请token，token放到redis或内存，token有效时间
   2. 提交后后台校验token，同时删除token，生成新的token返回
      token特点：
      要申请，一次有效性，可以限流
      注意：redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用

   3.悲观锁
   获取数据的时候加锁获取
   select * from table_xxx where id=‘xxx’ for update;
   注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的
   悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用
   4. 乐观锁
   乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。
   乐观锁的实现方式多种多样可以通过version或者其他状态条件：

   1. 通过版本号实现
      update table_xxx set name=#name#,version=version+1 where version=#version#如下图(来自网上)：
      
      2. 通过条件限制
      update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount#>= 0
      要求：quality-#subQuality# >= ，这个情景适合不用版本号，只更新是做数据安全校验，适合库存模型，扣份额和回滚份额，性能更高
      注意：乐观锁的更新操作，最好用主键或者唯一索引来更新,这样是行锁，否则更新时会锁表，上面两个sql改成下面的两个更好

update table_xxx set name=#name#,version=version+1 where id=#id# and
version=#version# update table_xxx set
avai_amount=avai_amount-#subAmount# where id=#id# and
avai_amount-#subAmount# >= 0

5. 分布式锁
还是拿插入数据的例子，如果是分布是系统，构建全局唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统(redis或zookeeper)，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。
要点：某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁(分布式锁要第三方系统提供)

6. select + insert
并发不高的后台系统，或者一些任务JOB，为了支持幂等，支持重复执行，简单的处理方法是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了
注意：核心高并发流程不要用这种方法
7. 对外提供接口的api如何保证幂等
如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号source+seq在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)
重点：
对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。注意，为了幂等友好，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统，会报错，但实际已经处理了。