spikeSystem
spikeSystem copied to clipboard
GuoZhaoran
对Redis的压力也很大吧？
如果分库server的库存减和总redis库存减的操作是原子操作这个是前提的话，8点放票，此时库存都是足够的，瞬间所有的分仓库都会去请求Redis。100W并发请求，就可能有绝大多数的请求同样也会去Redis。 这个问题如何解决。单单去增加redis服务器的并发能力吗？
真实的场景中，用户都是请求一辆火车的余票。其实服务端根据车次又做了一次均衡，不同车的余票可能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服务器的并发能力吗？
— 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 也能抗住一个车次的量。 如果这个车次很热门能超过每秒 10W 的请求量，那可能也可以根据车厢再分流？一个 redis 只负责一个车厢的，这样也能抗住。
所以重点思想还是用内存操作提高效率吧
感谢您的回答，我明白您的意思，但我还有一点些疑惑： 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服务器的并发能力吗？ — 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，那分库还有什么意义?
确实没什么意义了，应该是第一种。
------------------ 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服务器的并发能力吗？ — 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库存，那本地库存的意义在哪里
我感觉这样就可以把一些请求都截流在本地机器上，这样远端服务器就不必承担这部分流量。
