针对最终一致的方案非常简单，增加机器就可以解决，时效性较高的可以直接使用数据库的读写分离，增加应用服务器，处理更多的并发； 实时性较高使用读写分离方案、缩短catched时间；实时性较低的可以使用较长时间catched。
强一致性的流量处理方案，总的来说就是加速，可以使用数据库的锁，也可以使用ZK，或者直接使用排队的机制，这里面数据库的锁，基本上变化在2000次每秒以下。在这个情况之下，完全可以使数据库的锁来防止并发，第一个方法就是有事务的防止并发的方法。
然后再更新共享资源，最后再查询一次共享资源，然后判断一下结果。假如说这个结果是成立的，就直接运行，假如说这个结果是不成立的，那么再做。第二个就是无事物下的方法，加一个条件去判断他们的资源成不成立，当没有更新成功的时候，就返回。
如果流量依然承受不住该怎么办？
做到这些其实已经能够承受非常大的流量，但是业务可能继续发展，还承受不住怎么办呢？
首先的一个原则就是没有任何分布式的操作，最好的方法就是单点、排队处理。
第二，单点并发过大，使用合适的方式拆分锁的粒度；比如说产品12月期的，增加一个9月期的，6月期的等等。比如说增加这个还不够，能不能按省卖他们的产品，每个省有一个自己的库存，粒度会很多。
第三，增加降级需求，不影响用户正常使用情况下可以适当降低服务质量。适当修改需求、适当增加用户等待结果时间；如果让用户等2秒，是不是能撑到4400每两秒，答案是肯定的，可以多让用户等一段时间，这个交互上让用户有更好的体验。 最后适当调整运营策略，分散用户集中活跃时间。