超时重试思考-非幂等请求

Nginx代理配置详解
本文介绍了Nginx代理配置中的关键参数,如proxy_connect_timeout、proxy_read_timeout和proxy_send_timeout,并探讨了如何通过proxy_next_upstream实现非幂等请求的重试机制。

转载请注明出处 http://www.paraller.com 原文排版地址 点击获取更好阅读体验

转载请注明出处 来源:paraller's blog

``` upstream www.paraller.com { server 10.29.209.14:3810; server 10.24.225.11:3810; server 10.25.208.38*:3810; }

server { server_name www.paraller.com; listen 80 ; access_log /var/log/nginx/access.log vhost; return 301 https://$host$request_uri; }

server { server_name www.paraller.com; listen 443 ssl http2 ; access_log /var/log/nginx/access.log vhost;

    add_header Strict-Transport-Security "max-age=31536000";
    location ^~ /socket.io/ {
    return 301;
}
location / {
            proxy_pass http://www.paraller.com;
            proxy_connect_timeout 20;
            proxy_read_timeout 20;
            proxy_send_timeout 20;
            proxy_ignore_client_abort on;
    }

} ```

  • proxy_connect_timeout 后端服务器连接的超时时间_发起握手等候响应超时时间
  • proxy_read_timeout 连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理(也可以说是后端服务器处理请求的时间)
  • proxy_send_timeout :后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据

nginx在某个版本更新之后,对非幂等的请求不会进行重试处理。

如果要对幂等操作重试请求

In case of upstream returning 429, I'd like to have nginx retry next upstream server. Since nginx by default won't retry non-idempotent requests, how do I force nginx to retry when receiving 429? I imagine this should be the default behavior anyway, or does nginx not care about returning code and will never retry non-idempotent?

If you want nginx to retry non-idempotent requests, you can do so with "proxy_next_upstream non-idempotent;", see http://nginx.org/r/proxy_next_upstream.

http://nginx.2469901.n2.nabble.com/upstream-429-and-non-idempotent-request-td7600353.html

优先参考上面的回答,下面是 stackflow的示例:

``` upstream backends { server 192.2.0.1; server 192.2.0.2; ... }

server { ...

location / {
    proxy_pass http://backends;
    proxy_next_upstream error timeout http_404;
}

} ```

参考网站

https://stackoverflow.com/questions/12868683/nginx-proxy-next-upstream-doesnt-work https://stackoverflow.com/questions/40661246/nginx-tries-to-proxy-pass-to-upstream-name

关于该参数的详细解释 nginx proxy_next_upstream

Nginx学习总结:proxy与rewrite模块(三)

<think>我们正在处理淘宝购物车相关的测试用例设计,特别是并发测试和幂等测试。根据用户的问题,我们需要提供设计方法和示例。参考已有的引用内容:引用[1]提到测试用例设计可以使用通用思维框架,然后转化为结构化用例(标准模板)。引用[2]提到了测试用例设计方法,特别是等价类划分(有效等价类和无效等价类)。引用[3]提供了一个测试用例案例,包括测试步骤的详细描述。用户需求:淘宝购物车的并发测试用例和幂等测试用例的设计方法或示例。一、并发测试:定义:多个用户同时操作购物车,比如同时添加商品、删除商品、修改数量等,验证系统在并发情况下的数据一致性和性能。设计方法:1.确定并发操作场景:例如,多个用户同时添加同一商品到购物车,同时修改同一商品的数量,同时删除同一商品等。2.使用等价类划分:考虑正常情况(如多个用户同时添加不同商品)和边界情况(如多个用户同时操作同一个商品)。3.设计并发测试用例,需要包括:并发用户数、操作类型、预期结果(如数据一致性,不能出现超卖、少卖或数据错乱)。二、幂等测试:定义:同一个操作执行多次,结果应该相同。例如,用户多次点击“添加商品”,应该只添加一次(或者有相应的处理机制)。设计方法:1.确定需要幂等性的接口:添加商品、删除商品、修改数量等。2.设计用例:多次重复同一操作,检查结果是否符合幂等性要求。我们将根据上述思路设计测试用例示例。注意:由于淘宝购物车的具体实现细节我们不清楚,这里根据一般电商购物车的功能进行设计。测试用例设计示例:一、并发测试用例示例:1.场景:多个用户同时添加同一商品到购物车测试步骤:-准备一个商品(库存充足)-模拟多个用户(例如100个用户)同时将该商品加入购物车预期结果:-所有用户的购物车中该商品数量正确(每个用户添加一次,每个用户的购物车中该商品数量增加1)-商品库存不会因为并发添加而减少过多(注意:添加购物车一般不直接减库存,但有些设计可能预留库存,这里按一般情况,即添加购物车不减库存,只有下单才减库存。所以这里主要检查购物车中的数据一致性)2.场景:多个用户同时修改购物车中同一商品的数量(比如一个用户自己的购物车中某商品,多个终端同时修改)测试步骤:-一个用户登录多个设备(模拟并发)-同时修改购物车中同一商品的数量(例如,设备A修改为2,设备B修改为3)预期结果:-最终购物车中的商品数量应该是最后一次修改的值(但要注意,如果两个修改请求同时到达,系统需要有并发控制,比如最后修改时间覆盖,或者提示用户冲突)3.场景:多个用户同时删除购物车中同一商品测试步骤:-多个用户同时删除同一个商品(该商品在购物车中存在)预期结果:-商品被删除,且无论多少个用户同时删除,结果都是被删除(不会出现删除后又出现的情况)二、幂等测试用例示例:1.场景:重复添加同一商品到购物车测试步骤:-用户连续多次(例如5次)点击“添加商品”按钮(同一商品)-检查购物车中该商品的数量预期结果:-第一次点击,购物车中该商品数量为1-后续每次点击,如果设计为幂等(即多次点击只加一次),则数量仍为1;或者设计为每次点击都增加,则数量相应增加(但这里通常不是幂等,所以需要看需求)。但要注意,如果网络原因导致用户重复提交,系统应该通过幂等机制保证不会重复添加多次(比如使用token或去重机制)。因此,预期结果应该是:无论点击多少次,最终购物车中该商品的数量只增加一次(即幂等性要求)?但实际上,淘宝购物车中连续点击同一个商品,会合并为同一个商品,数量增加。所以这里要区分操作:如果是同一个商品,多次点击“加入购物车”,应该是每次点击数量增加1。那么这不是幂等操作。而幂等性通常针对同一请求多次提交(比如网络超时重试)的情况,此时系统应该保证只生效一次。重新思考幂等性在购物车中的应用:-对于加入购物车操作,如果用户连续点击,由于是同一个用户同一个商品,系统应该将多次点击视为多次加入,即数量累加。这并不违反幂等性,因为每次点击都是独立的操作(每次操作都增加了数量)。而幂等性是指同一个请求(同一个请求ID)多次提交,只生效一次。因此,我们需要区分操作的类型。通常,幂等性设计是针对接口的,例如下单接口,同一个订单请求提交多次,只会生成一个订单。而购物车中的加入操作,一般不需要幂等性,因为每次点击都是用户的一次新操作(用户意图是加一次)。但是,如果因为网络原因,用户点击一次后没有收到响应,又点击了一次,这时系统应该如何处理?这里就需要幂等性来避免重复添加。所以,设计幂等测试用例:-使用相同的请求参数(包括相同的请求ID,或者相同的token)多次请求“添加商品”接口。预期结果:只有第一次请求生效,后续请求返回成功但不会增加数量(或者返回已添加)。因此,我们设计如下:幂等测试用例1:相同的请求重复提交测试步骤:-用户点击添加商品,生成一个请求(带唯一token)-由于网络延迟,用户再次点击,发送相同的请求(相同的token)-系统收到两次相同的请求预期结果:-第一次请求,商品添加到购物车,数量增加1-第二次请求,系统识别token重复,不执行添加操作,返回添加成功(但实际没有增加数量)或者返回重复请求的提示幂等测试用例2:不同的请求(不同token)添加同一商品测试步骤:-用户第一次点击添加商品(token1)-用户再次点击添加商品(token2,表示新的请求)预期结果:-两次请求都执行,购物车中该商品数量增加2总结:并发测试关注多用户同时操作时系统的正确性,幂等测试关注同一请求重复提交时系统的处理。根据上述分析,我们给出测试用例模板示例(以表格形式描述,但这里用文字描述):一、并发测试用例:|用例编号|测试场景|测试步骤|预期结果||---------|---------|---------|---------||TC_CONC_001|多用户同时添加同一商品|1.准备商品A,库存1000<br>2.模拟100个用户并发执行添加商品A到各自购物车<br>3.检查每个用户购物车中商品A的数量<br>4.检查商品A的库存(如果添加购物车涉及库存预留,则检查库存;否则忽略)|1.每个用户购物车中商品A的数量为1(如果之前没有)<br>2.商品库存不变(或者预留库存增加1000,但一般添加购物车不扣减库存)||TC_CONC_002|同一用户多设备并发修改购物车商品数量|1.用户U登录设备A和设备B<br>2.设备A将购物车中商品A数量修改为2<br>3.设备B同时将商品A数量修改为3<br>4.检查购物车中商品A的数量|1.最终商品数量为2或3(取决于最后到达的请求)或者系统提示冲突,要求用户刷新(具体以需求为准)||TC_CONC_003|多用户同时删除购物车中同一商品|1.多个用户(例如100个)的购物车中都有商品A<br>2.同时执行删除商品A的操作<br>3.检查这些用户的购物车|1.所有用户的购物车中商品A都被删除|二、幂等测试用例:|用例编号|测试场景|测试步骤|预期结果||---------|---------|---------|---------||TC_IDEMP_001|重复提交相同的添加商品请求|1.用户请求添加商品A,请求中包含唯一token=T1<br>2.再次发送完全相同的请求(token=T1)<br>3.检查购物车中商品A的数量|1.第一次请求后,商品A数量加1<br>2.第二次请求后,商品A数量不变(系统识别重复token)||TC_IDEMP_002|不同请求添加同一商品|1.用户请求添加商品A,请求中包含token=T1<br>2.用户再次请求添加商品A,请求中包含token=T2<br>3.检查购物车中商品A的数量|1.两次请求后,商品A数量增加2|注意:这些测试用例需要根据实际系统设计进行调整。另外,我们可以参考引用[3]中的测试步骤详细描述方式,将测试步骤写得更清晰。相关问题:1.如何模拟淘宝购物车的并发测试环境?2.幂等性测试中,如何生成和管理唯一token?3.除了并发和幂等,淘宝购物车还需要关注哪些测试点?</think>### 淘宝购物车并发与幂等测试用例设计 #### 一、并发测试用例设计(基于等价类划分[^2]) 1. **多用户同时添加商品** **测试步骤**: - 用户A和用户B同时将同一商品加入购物车 - 重复执行10次高并发请求(如JMeter模拟100用户) **预期结果**: - 购物车商品数量 = A操作数量 + B操作数量 - 无超卖/少卖现象,库存数据一致 2. **并发修改商品数量** **测试步骤**: - 用户A增加商品数量时,用户B减少同一商品数量 - 网络延迟下触发重复提交 **预期结果**: - 最终数量符合最后一次有效操作 - 页面显示与数据库一致 3. **极限并发删除** **测试步骤**: - 100用户同时清空购物车(含相同商品) **预期结果**: - 所有商品正确移除 - 事务锁机制生效,无死锁 #### 二、幂等性测试用例设计(基于请求去重) 1. **重复添加商品** ```gherkin 场景:网络超时重试 当 用户连续3次点击"添加商品A" 且 请求ID相同 那么 购物车中商品A数量仅增加1 ``` **验证点**:服务端识别请求ID去重[^1] 2. **支付后重复提交订单** **测试步骤**: - 生成订单后多次调用结算接口 **预期结果**: - 仅创建1个订单 - 返回相同订单ID(HTTP 200 OK) 3. **库存扣减幂等** **测试步骤**: - 模拟订单创建->失败->重试流程 **预期结果**: - 库存仅扣减1次 - 日志显示"幂等拦截"记录 #### 三、测试案例示例(结合UI与API层[^3]) | 测试类型 | 测试场景 | 测试数据 | 预期结果 | |----------|---------------------------|-----------------------|---------------------------| | 并发 | 百人秒杀同一商品 | 商品ID: P123, 库存100 | 成功添加≤100件 | | 幂等 | 断网重连后重复提交购物车 | 请求Token: Txn_abc | 数据库无重复条目 | | 混合场景 | 删除商品时触发自动降价 | 降价规则生效期间 | 删除操作优先于降价规则 | --- ### 关键技术实现 1. **并发控制** - 悲观锁:`SELECT FOR UPDATE`确保库存操作原子性 - 乐观锁:版本号校验(如Redis原子计数器) 2. **幂等保障** ```java // 基于Token的幂等校验 boolean isDuplicate = redis.setnx(requestId, "1", 60s); if(isDuplicate) return cachedResult; // 返回缓存结果 ``` $$P(\text{幂等成功}) = 1 - \prod_{i=1}^{n}(1 - p_i) \quad (p_i=\text{节点可靠性})$$ 3. **测试工具链** - 并发测试:JMeter分布式集群 - 幂等验证:Postman循环请求+结果比对 - 监控:ELK日志分析请求ID重复率
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值