关于程序运行逻辑

[wwnnrr]

这二天均测试了，都没有成功，仔细看了一下程序运行情况，有一个问题，不知有考虑过没有。 我感觉程序想的过于周密，程序的流程是将所有前期的核对交给基础线程，并且设置了一个间隔时间，但就是这个有点问题。 因为我们主要的一个动作是去提交订单，而提交这wh订单的条件是，前面所有的基础核对全部要返回成功，但是在高峰期，能过通过的机会 少的可怜，要4-5个动作全部OK才去作基本不可能，而且还有一个最大的问题是，A好不容易过了，B没有过，A又开始第二次核对，结果拥堵失败，这样反反复复，最后一次提交订单的机会也没有。 是否可以考虑，将A，B，C，D等 基础核对工作，一旦有完成，可以保持多少时间，这样可以增加提交的机会，尤其是派送时间。

[wwnnrr]

Sorry更正一下，在CheckOrder及最后提交订单，用的是MAP是否为空，不是POST数据是否成功，所以不会因为前面基础核对不成功而不递交的，但我还是建议减少基础核对，每个步骤用二个线程，而且大量的重复，被风控太容易了。我自己修改了一下，在基础成功后子线程停止10秒看看。另外与大家交流一下，账号被风控，是不是code为200。

[hrchen]

现在你的程序下单正常了吗？

[xiaozheng3598]

风控code3000

[wwnnrr]

我理解的是，高峰期下单过程中"购物车"+"派送时间"这两个请求应该要一直刷新，这样才能保证最后Check & Submit订单的数据是准确的

我也知道这一点，但实践问题是，这二个在高峰时就会不断产生，前向拥堵,然后不停的刷新，封账号也会因为这个产生。派送时间这个绝对可以延长，目前DD，把派送时间加的很大，所以几秒内是不会有问题的。

[wwnnrr]

风控code3000

是在那个环节抓到3000这个CODE的。

[Miles0928]

我理解的是，高峰期下单过程中"购物车"+"派送时间"这两个请求应该要一直刷新，这样才能保证最后Check & Submit订单的数据是准确的

我也知道这一点，但实践问题是，这二个在高峰时就会不断产生，前向拥堵,然后不停的刷新，封账号也会因为这个产生。派送时间这个绝对可以延长，目前DD，把派送时间加的很大，所以几秒内是不会有问题的。

根据最近的情况来看，瓶颈确实不在配送这块，主要是库存不足

[wwnnrr]

我理解的是，高峰期下单过程中"购物车"+"派送时间"这两个请求应该要一直刷新，这样才能保证最后Check & Submit订单的数据是准确的

我也知道这一点，但实践问题是，这二个在高峰时就会不断产生，前向拥堵,然后不停的刷新，封账号也会因为这个产生。派送时间这个绝对可以延长，目前DD，把派送时间加的很大，所以几秒内是不会有问题的。

根据最近的情况来看，瓶颈确实不在配送这块，主要是库存不足

每个地方不一样，运力基本能坚持5分钟以上，但库存涉及到单 个商品，变数多，所以运立的检查不用怎么平凡去刷。

[Miles0928]

我理解的是，高峰期下单过程中"购物车"+"派送时间"这两个请求应该要一直刷新，这样才能保证最后Check & Submit订单的数据是准确的

我也知道这一点，但实践问题是，这二个在高峰时就会不断产生，前向拥堵,然后不停的刷新，封账号也会因为这个产生。派送时间这个绝对可以延长，目前DD，把派送时间加的很大，所以几秒内是不会有问题的。

根据最近的情况来看，瓶颈确实不在配送这块，主要是库存不足

每个地方不一样，运力基本能坚持5分钟以上，但库存涉及到单 个商品，变数多，所以运立的检查不用怎么平凡去刷。

程序运行确实存在逻辑问题。由于一直while刷新，前面获得的数据到后面可能都改变了(比如购物车商品变化)，导致最终check以及submit的数据是错误的