上几次主要说了高并发大流量项目所涉及到的技术点和技术方案，调优需要注意的一些参数，秒杀订单接口缓存的概念，通过redis的方式，redis需要进行原子性。
秒杀优化
使用缓存可以大大的提高我们系统的性能，但是需要考虑到周全，可能带来数据的不一致性，所以要根据业务的场景和业务的逻辑，良好的维护它，如果漏了就会产生服务的不一致。产生线上的bug。
- 地址信息
正常的下秒杀单子的时候，需要先维护好地址信息，下单的时候需要提供对应的地址信息。也可以将这些地址信息添加到redis中，当用户登录的时候的默认从redis中获取地址信息，这样就可以增加性能，但是还有个问题，用户的地址会登录后发生变化，也就是在用户针对地址发生变化的时候，维护当前用户redis的地址。
- 下单校验
如果库存有50个，请求过来5050个，最后下单成功了50个，但是其他5000个都要走一遍查询流程是不是不应该，应该让他走一半就结束，不应该走到最后的库存查询就才结束，应该在库存查询之前要走各种session校验，地址校验，信息校验各种。应该在前面有个jvm内存的校验直接就先告诉他库存已经少于等于0了就不要在往下面请求了，这样服务压力不会很大。也就是在内存中jvm中有个变量来进行判断通过hash的方式。
- 下单异步化
下单后，可以进行消息处理中，让消息消费端慢慢消费消息中间件内的消息。使用异步化下单后不能直接跳转到支付页面，可能订单还没生成，还在排队，肯定不能直接返回待支付页面，跟他返回排队中。异步队列效果最佳就是底层库存比较大的情况下。这样吞吐量比较大。
（二）前端控制
原来的时候下单完毕后，直接跳转到支付页面。如果是做成异步下单，就不能直接跳转到支付页面了，而是需要在等待页面，等待页面有个js方法定时循环的调用获取这个用户是否在数据库存在单子，如果存在就直接跳转支付页面，如果不存在就一直等待，在等待的过程中如果库存为0，说明已经抢完了，失败了，没有最后落单，就直接通过客户下单失败，秒杀结束。千万没查数据库了，查redis就可以了。
PS：BAT这种大公司里面的秒杀系统，一般涉及到7,8个中心，每个中心之前可能有2个开发人员，一个秒杀系统大概15,16个人员，在加上单元测试人员，功能测试人员。分布式并发问题就是很复杂，复杂就是在细节里面，用数据库是可以查询出来实时的。