之前说了几个高并发的优化点，以及通过一个插件完成session的分布式共享。这次主要说说关于秒杀下单需要注意哪些。
秒杀下单需要注意点（一）
- 是否登录session是否存在。
- 收货地址是否填写
- 商品是否存在
- 库存是否够
- 有效期判断
- 库存的数据修改修改redis，一定要使用redis的原子性操作，不要使用set，使用decr。让并发变成线性化操作，变成队列来进行操作。
分布式事务（二）
首先先说分布式事务是个很复杂的问题，但是解决方案也很多，能不用分布式尽量不用，如果并发量不是那么大的情况下。
1.分布式的由来
例如dubbo服务调用，多个dubbo服务，都不在一个JVM或不在一台机器上，这就是分布式事务。
2.比较稳妥的方式
通过表行锁，或者消息中间件的补偿机制来完成。多个服务读同一个表，多一同统一口径这样完成分布式事务。
消息中间件只有一个JVM消费，这样一个口径消费。
3.二阶段提交
支付宝，淘宝这种公司专门有自己的中间件，开发过程中压根搬砖的程序员压根就不用考虑分布式事务的问题，分布式事务交给了中间价团队，原理就是2阶段提交，分布式事务的中间件作为协调者，比方有2个系统。A系统，B系统，A系统的方法调用了B系统的方法，A系统有个事务TXA，B系统也有自己的事务TXB，A系统方法比较长，它在中间位置需要调用B的方法，B系统方法内容比较短。A方法调用完成B方法完成后在去自己剩余的方法。B结束后是不是把自己的方法提交了，但是B结束事务发给事务的中间件协调者，但是B结束的这部提交没有真正的提交到数据库，它只是提交了一个级别，并没有真正的在数据库那个级别提交（2阶段事务提交），如果没有分布式中间件也就是B结束，B的事务就提交了，但是A的方法还没执行完毕。等待A的方法执行也进行了2阶段的提交，但是A也不是真正提交给数据库。也就是A方法执行完毕，B方法执行完成，然后由分布式事务协调器统一一起提交到数据库。
虽然这2个事务开始是分开的，但是这2个事务到最后汇集到分布式中间件了，分布式中间件把2个事务变成了一个事务。这个其实非常之复杂，我也是只知道原理。
PS：真实的秒杀需要不断的优化，最早的12306没有验证码的时候，很多人都是通过jmeter的方式来不断的提交订单来购票。了解了秒杀的原理，下次说说如何针对秒杀大流量进行控制。