Skip to content

Commit e561dc3

Browse files
author
文亮
committed
add .
1 parent c41a79b commit e561dc3

File tree

7 files changed

+197
-0
lines changed

7 files changed

+197
-0
lines changed

README.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -206,6 +206,10 @@
206206
- [30、你们系统每天有多大访问量?每个服务高峰QPS多少?压测过服务最大QPS吗?](/docs/distributed-system/system-qps.md)
207207
- [31、如果系统访问量比现在增加10倍,你们考虑过系统的扩容方案吗?](/docs/distributed-system/system-dilatation.md)
208208
- [32、作业:独立画出自己系统的生产部署架构图,梳理系统和服务的QPS以及扩容方案](/docs/distributed-system/work-system-dilatation.md)
209+
- [33、你们生产环境的服务是怎么配置超时和重试参数的?为什么要这样配置?](/docs/distributed-system/service-request-time-out.md)[代码下载点击这里哦!](https://github.com/shishan100/Java-Interview-Advanced/raw/master/docs/distributed-system/code/code4.zip)
210+
- [34、如果出现服务请求重试,会不会出现类似重复下单的问题?](/docs/distributed-system/request-retry.md)
211+
- [35、对于核心接口的防重幂等性,你们是怎么设计的?怎么防止重复下单问题?](/docs/distributed-system/interface-idempotence.md)
212+
- [36、作业:看看自己系统的核心接口有没有设计幂等性方案?如果没有,应该怎么设计?](/docs/distributed-system/work-interface-idempotence.md)
209213

210214

211215
### 第二季-高并发

docs/distributed-system/code/code3.zip

100755100644
-25 KB
Binary file not shown.
95.2 KB
Binary file not shown.
Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
2+
接口幂等性实现起来非常的简单,不打算带着大家手写代码
3+
4+
(1)数据库唯一索引
5+
(2)基于Redis实现一套幂等性防重框架
6+
7+
8+
9+
对于插入类的操作,一般都是建议大家要在数据库表中设计一些唯一索引
10+
11+
12+
你如果有一个订单被支付了,此时就要通知wms创建一个对应发货单,也是数据库里的一个表,仓库里的人会看到这个发货单,此时他就会根据发货单的信息从仓库里进行拣货,打包,封装,交给物流公司
13+
14+
15+
16+
发货单
17+
18+
id order_id 订单金额 发货地址 xxxx
19+
20+
对order_id就可以建立一个唯一索引,你插入发货单的时候,同一个order_id最多只能对应一个发货单,不可能说同样的一个order_id对应了多个发货单
21+
22+
23+
订单服务 -> wms服务,出现了重试,导致第二次请求再次让人家创建这个订单的发货单,create语句,order_id触发了唯一索引约束
24+
25+
26+
27+
28+
29+
扣减库存、累加积分,更新,很难通过数据库唯一索引来保证
30+
31+
32+
基于Redis实现一套接口的防重框架
33+
34+
你得做一个类似spring mvc里的拦截器这样的东西,在这个拦截器里,他会拦截所有的请求,对所有的请求都会提取请求对应的参数,GET请求、POST请求、PUT请求,有些参数是跟在URL地址里的,?xx=xx&xx=xx
35+
36+
POST、PUT,可能是请求体里的,可能是一个JSON格式
37+
38+
把参数拼接在一起,作为key去redis中判断一下,是否存在这个key,之前附加这些参数的请求是否发起过,如果没有的话,此时就可以把这些参数+接口名称,作为一个key,存储到redis中去
39+
40+
然后呢,把请求放行,去执行这个请求
41+
42+
如果说人家重试再次发起一个这个请求,此时就可以判断出来,参数组成的key在redis中已经存在了,此时就不让执行这个请求了,认为是重复调用了
43+
44+
45+
46+
47+
48+
考虑很多问题,幂等不幂等,通用框架,需要一个公司所有的接口都按照指定的参数来传递,还有很多业务语义的问题
49+
50+
第一次发起一个请求,直接把请求key放入redis,但是他执行的过程中失败了,而且还阻塞了一段时间,此时人家再次重试发起第二次请求,这个时候按照上述的框架逻辑,就会把请求拦截下来了
51+
52+
53+
到底是不是要对所有接口都开启这么一个东西呢?
54+
55+
56+
每个接口如果执行成功了之后,我可以设置一个每个接口调用的时候执行成功之后,做一个后拦截器,如果成功了,就把请求对应的参数拼接为key放入redis中
57+
58+
有没有可能是第一次请求发送过来,在执行过程中,时间长了,比如需要1.3秒才执行完毕;此时人家发现超过1s了,直接重试,第二次请求过来了,也在正常的执行
59+
60+
第一次请求1.3秒之后执行成功了,第二次请求也执行成功了
61+
62+
只要一个服务希望对自己的接口开启幂等性防重功能,就把你开发好的拦截器对应的jar包,通过maven引入一个依赖就可以了
63+
64+
65+
66+
中大型互联网公司里也没做一个统一的防重幂等框架,其实一般都是各个服务对自己核心的接口,如果要保证幂等性的话,每个服务根据自己的业务逻辑来实现,而且仅仅是对少数核心接口做幂等性保障
67+
68+
69+
核心接口,库存服务,扣减库存接口
70+
71+
定制化的去针对接口开发幂等性的机制,比如说一旦库存扣减成功之后,就立马要写一条数据到redis里去,order_id_11356_stock_deduct,写入redis中,如果写入成功,就说明之前这个订单的库存扣减,没人执行过
72+
73+
但是如果此时有一些重试的请求过来了,调用了你的库存扣减接口,他同时也进行了库存的扣减,但是他用同样的一个key,order_id_11356_stock_deduct,写入redis中,此时会发现已经有人写过key,key已经存在了
74+
75+
此时你就应该直接对刚才的库存扣减逻辑做一个反向的回滚逻辑,update product_stock set stock = stock - 100,update product_stock set stock = stock + 100,反向逻辑,回滚掉,自己避免说重复扣减库存
76+
77+
78+
79+
80+
81+
82+
核心接口,幂等性都是自己保证的,人家可能会重试调用你的接口,对于create类的操作,用唯一索引来保证;对update类的操作,建议在核心接口里基于自己的业务逻辑,配合上redis,来保证幂等性
83+
84+
Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
2+
订单服务 -> 创建订单
3+
4+
-> 库存服务 -> 扣减库存
5+
-> wms服务 -> 通知发货
6+
-> 积分服务 -> 增加积分
7+
8+
订单服务调用库存服务的时候,因为网络抖动,请求超时了,超过了秒钟,此时订单服务会重试,再次调用一下库存服务,发送一模一样的请求过去
9+
10+
11+
12+
比如说,订单服务第一次请求库存服务,库存服务其实是把扣减库存的业务逻辑执行成功了,只不过网络问题,导致响应迟迟没有返回给订单服务,可能在1.2s之后返回了响应给订单服务
13+
14+
订单服务就认为请求超时了,他就再次发送了一个一模一样的请求给库存服务,库存服务可能会再次对库存进行扣减
15+
16+
Lines changed: 76 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,76 @@
1+
2+
分布式系统,拆分为很多个服务之后,他们互相之间要进行调用,平时服务内要优化的一些参数其实不多,服务与服务之间的调用,会不会出现调用的超时,每个服务超时的时间是多长,超时之后是否要进行重试,重试几次
3+
4+
高可用,hystrix进行资源隔离、熔断、降级,zuul网关层直接进行限流
5+
6+
7+
网关 ->(卡住) 订单服务 ->(卡住) wms服务
8+
9+
网关收到的一个http响应,可能就是一个500,internal error
10+
11+
12+
13+
14+
15+
Spring Cloud生产优化,系统第一次启动的时候,人家调用你经常会出现timeout
16+
17+
每个服务第一次被请求的时候,他会去初始化一个Ribbon的组件,初始化这些组件需要耗费一定的时间,所以很容易会导致。让每个服务启动的时候就直接初始化Ribbon相关的组件,避免第一次请求的时候初始化
18+
19+
```
20+
ribbon:
21+
eager-load:
22+
enabled: true
23+
24+
25+
zuul:
26+
ribbon:
27+
eager-load:
28+
enabled: true
29+
30+
feign:
31+
hystrix:
32+
enabled: false
33+
34+
```
35+
36+
我们刚才启动了wms服务之后,其实订单服务和积分服务、wms服务、库存服务之间的请求都是没问题的,日志全部都打印出来了,不会说第一次请求因为ribbon加载过慢导致请求失败的问题
37+
38+
但是zuul网关层面去请求订单服务的时候,他还是可能会认为自己超时了,windows电脑上跑这样的一套系统,网络请求都是比较慢的,因为你有很多服务与服务之间的调用,order和另外3个服务一套交互下来,比如超过了1秒钟
39+
40+
zuul而言感觉耗时太久了,还是会认为是超时的
41+
42+
windows电脑走的都是家用网络,我家里的网络情况不是太好,网卡,网速慢,信号弱
43+
44+
45+
46+
47+
线上的服务,每个服务部署上线的时候,一般来说都需要配置相关的超时时间还有重试次数
48+
49+
订单服务 -> 积分服务、库存服务、仓促服务
50+
51+
订单服务对于其他服务的调用,一般来说限制在多长时间就必须认为是超时了,如果超时之后如何进行重试
52+
53+
积分服务部署了两台机器,机器1和机器2
54+
55+
订单服务在一次请求积分服务的机器1的时候,超过1秒钟,超时了;此时需要进行重试,对积分服务当前的这台机器1重试几次?如果说机器1不行,是否可以重试一下积分服务的机器2?
56+
57+
58+
```
59+
ribbon:
60+
ConnectTimeout: 3000
61+
ReadTimeout: 3000
62+
OkToRetryOnAllOperations: true
63+
MaxAutoRetries: 1
64+
MaxAutoRetriesNextServer: 1
65+
66+
中小型的系统,没必要直接开启hystrix,资源隔离、熔断、降级,如果你没有设计好一整套系统高可用的方案
67+
68+
zuul请求一个订单服务,超过1秒就认为超时了,此时会先重试一下订单服务这台机器,如果还是不行就重试一下订单服务的其他机器
69+
70+
<dependency>
71+
<groupId>org.springframework.retry</groupId>
72+
<artifactId>spring-retry</artifactId>
73+
</dependency>
74+
75+
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000
76+
```
Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
2+
分布式系统,考察生产实践细节,常问的面试问题
3+
4+
服务框架、注册中心、网关系统、部署架构、超时重试、幂等性
5+
6+
7+
跟你自己的业务系统有关系了,你们的系统服务之间的调用,有没有超时和重试的配置,如果没有,如何优化配置,如果有,核心接口有没有幂等性机制,重复插入数据,重复跟新数据
8+
9+
如果有问题,结合你的业务,如何基于唯一索引、redis定制化防重机制
10+
11+
12+
可以在评论区提问,我们会给大家答疑,狸猫技术窝,知识店铺,训练营页面里,有评论区,提问,答疑
13+
14+
好好的完成作业,在作业里设计自己的系统业务逻辑对应的一套幂等性机制,每天的作业,都是可以提交,你可以把作业提交到店铺里去,每天我们都会给你们提交的作业进行点评,对你们作业里的问题进行答疑
15+
16+
17+
付费微信交流群,课程目录里有一个文档,入群步骤

0 commit comments

Comments
 (0)