对Redis的压力也很大吧？ #5
Comments
|
真实的场景中，用户都是请求一辆火车的余票。其实服务端根据车次又做了一次均衡，不同车的余票可能hash到不同的redis中去。统一减库存对redis的压力不会太大。------------------ 原始邮件 ------------------
发件人: "zhang570221322"<[email protected]>
发送时间: 2019年11月13日(星期三) 晚上6:31
收件人: "GuoZhaoran/spikeSystem"<[email protected]>;
抄送: "Subscribed"<[email protected]>;
主题: [GuoZhaoran/spikeSystem] 对Redis的压力也很大吧？ (#5)
如果分库server的库存减和总redis库存减的操作是原子操作这个是前提的话，8点放票，此时库存都是足够的，瞬间所有的分仓库都会去请求Redis。100W并发请求，就可能有绝大多数的请求同样也会去Redis。 这个问题如何解决。单单去增加redis服务器的并发能力吗？
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
感谢您的回答，我明白您的意思，但我还有一点些疑惑：
1.对于服务端根据火车车次进行均衡，这肯定没问题。
2.但对于同一辆火车，分库减票和总Redis减票相对于订单生成是原子操作（但两次减操作的顺序我不太明白），且订单的成功是以总Redis减票成功作为标志的。
我又看了一遍ReadMe，目前我是理解的是2.1的情形，不知是否正确。
对于单个分库来说:
2.1 当客户端并发请求时，会先对这个分库进行票量减逻辑，筛选出成功的请求后再请求Redis减票逻辑，总Redis减票成功后，订单成功。这样就把压力分给了单个分库。
2.2 相反的例子是，客户端并发请求时，不会先对分库的票量进行减逻辑，仅仅根据分库票量判断是否充足，然后等到Redis减票成功后，再对分库进行减票逻辑，然后生成订单。如果是这样的话，相当于进行了一个先分后总，并发会集体转移到Redis。
…------------------ Original ------------------
From: "GuoZhaoran"<[email protected]>;
Date: Wed, Nov 13, 2019 10:56 PM
To: "GuoZhaoran/spikeSystem"<[email protected]>;
Cc: "nol、煷"<[email protected]>;"Author"<[email protected]>;
Subject: Re: [GuoZhaoran/spikeSystem] 对Redis的压力也很大吧？ (#5)
真实的场景中，用户都是请求一辆火车的余票。其实服务端根据车次又做了一次均衡，不同车的余票可能hash到不同的redis中去。统一减库存对redis的压力不会太大。------------------ 原始邮件 ------------------
发件人: "zhang570221322"<[email protected]>
发送时间: 2019年11月13日(星期三) 晚上6:31
收件人: "GuoZhaoran/spikeSystem"<[email protected]>;
抄送: "Subscribed"<[email protected]>;
主题: [GuoZhaoran/spikeSystem] 对Redis的压力也很大吧？ (#5)
如果分库server的库存减和总redis库存减的操作是原子操作这个是前提的话，8点放票，此时库存都是足够的，瞬间所有的分仓库都会去请求Redis。100W并发请求，就可能有绝大多数的请求同样也会去Redis。 这个问题如何解决。单单去增加redis&#x670D;务器的并发能力吗？
&mdash;
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
redis 的单机性能是 10W 的话，这里就是假设同时抢一个车次的请求量不会超过 10W 吧，这样单台 redis 也能抗住一个车次的量。 所以重点思想还是用内存操作提高效率吧 |
作者的意思就是先分库减库存，没有库存就不去请求redis了，这样可以减少redis压力，如果按你说的2.2，那分库还有什么意义? |
|
确实没什么意义了，应该是第一种。
…------------------ Original ------------------
From: "Yeongjet Tang"<[email protected]>;
Date: Thu, Mar 26, 2020 11:42 AM
To: "GuoZhaoran/spikeSystem"<[email protected]>;
Cc: "nol、煷"<[email protected]>;"Author"<[email protected]>;
Subject: Re: [GuoZhaoran/spikeSystem] 对Redis的压力也很大吧？ (#5)
感谢您的回答，我明白您的意思，但我还有一点些疑惑： 1.对于服务端根据火车车次进行均衡，这肯定没问题。 2.但对于同一辆火车，分库减票和总Redis减票相对于订单生成是原子操作（但两次减操作的顺序我不太明白），且订单的成功是以总Redis减票成功作为标志的。 我又看了一遍ReadMe，目前我是理解的是2.1的情形，不知是否正确。 对于单个分库来说: 2.1 当客户端并发请求时，会先对这个分库进行票量减逻辑，筛选出成功的请求后再请求Redis减票逻辑，总Redis减票成功后，订单成功。这样就把压力分给了单个分库。 2.2 相反的例子是，客户端并发请求时，不会先对分库的票量进行减逻辑，仅仅根据分库票量判断是否充足，然后等到Redis减票成功后，再对分库进行减票逻辑，然后生成订单。如果是这样的话，相当于进行了一个先分后总，并发会集体转移到Redis。
…
------------------ Original ------------------ From: "GuoZhaoran"<[email protected]>; Date: Wed, Nov 13, 2019 10:56 PM To: "GuoZhaoran/spikeSystem"<[email protected]>; Cc: "nol、煷"<[email protected]>;"Author"<[email protected]>; Subject: Re: [GuoZhaoran/spikeSystem] 对Redis的压力也很大吧？ (#5) 真实的场景中，用户都是请求一辆火车的余票。其实服务端根据车次又做了一次均衡，不同车的余票可能hash到不同的redis中去。统一减库存对redis的压力不会太大。------------------ 原始邮件 ------------------ 发件人: "zhang570221322"<[email protected]> 发送时间: 2019年11月13日(星期三) 晚上6:31 收件人: "GuoZhaoran/spikeSystem"<[email protected]>; 抄送: "Subscribed"<[email protected]>; 主题: [GuoZhaoran/spikeSystem] 对Redis的压力也很大吧？ (#5) 如果分库server的库存减和总redis库存减的操作是原子操作这个是前提的话，8点放票，此时库存都是足够的，瞬间所有的分仓库都会去请求Redis。100W并发请求，就可能有绝大多数的请求同样也会去Redis。 这个问题如何解决。单单去增加redis&#x670D;务器的并发能力吗？ &mdash; You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
作者的意思就是先分库减库存，没有库存就不去请求redis了，这样可以减少redis压力，如果按你说的2.2，那分库还有什么意义?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
既然每次扣库存都要扣本地库存和redis库存，那本地库存的意义在哪里 |
我感觉这样就可以把一些请求都截流在本地机器上，这样远端服务器就不必承担这部分流量。 |
如果分库server的库存减和总redis库存减的操作是原子操作这个是前提的话，8点放票，此时库存都是足够的，瞬间所有的分仓库都会去请求Redis。100W并发请求，就可能有绝大多数的请求同样也会去Redis。 这个问题如何解决。单单去增加redis服务器的并发能力吗？
The text was updated successfully, but these errors were encountered: