年夜流量读体系的设计手腕，当这些手腕全体穷尽今后，仍然发生年夜流量又该若何处置呢?所以秒杀体系还要解决以下症结问题。

1.Java处置年夜并动员态要求优化的问题

Java和通用的Web办事器( Nginx或 Apache)比拟，在处置年夜并发的HTP要求时要弱一点，所以一般我们都邑对年夜流量的Web体系做静态化改革，让年夜部门要求和数据直接在 Nginx I办事器或者Web署理办事器( Varnish、 squid等)上直接返回(可以削减数据的序列化与反序列化)，Java层只处置少量数据的动态要求。针对这些要求可以应用以下优化手腕:

直接应用 Servlet处置要求。避免应用传统的MVC框架，如许可以绕过一年夜堆庞杂且用途不年夜的处置逻辑，节俭1毫秒的时光一取决于对MVC框架的依附水平；

直接输出流数据。应用 resp. getoutputstreamo而不是 resp. get Writer)可以免却一些不变字符数据的编码，晋升机能；数据输出时，推举应用JSON而不是模板引擎(一般都是说明履行)来输出页面。

2.统一商品被年夜并发读的问题

也许有读者会认为这个问题很轻易解决，无非就是将热门数据放到Tair缓存里。集中式Tair缓存为了包管射中率一般都邑采取一致性Hash，所以统一个key会落到同台机械上。固然单台Tair缓存机械也能支持1秒30万次的要求，但照样远不足以敷衍年夜秒级其余热门商品，该若何彻底解决单点的瓶颈呢?谜底是采取运用层的Localcache，即在秒杀体系的单机上缓存商品相干的数据。那么若何 Cache数据?谜底是划分成动态数据和静态数据分离处置。

像商品的题目和描写这此机械上、并一向缓存到秒杀停止像库存这类动态数据会采取被动掉效的方法缓存必定时光(一般是数秒)，掉效后再去Tai缓存拉取最新的数据。

读者可能还会有疑问，像库存这种频仍更新的数据一旦数据纷歧致会不会导致超卖?这就要用到前面介绍的读数据的分层校验原则了，读的场景可以许可必定的脏数据，因为这里的误判只会导致少量本来无库存的下单要求被误以为有库存，可以比及真正写数据时再包管最终的一致性，经由过程在数据的高可用性和一致性之间的均衡来解决高并发的数据读取问题。

3.统一数据年夜并发更新问题

采取 Localcache和数据的分层校验可以必定水平上解决年夜并发读问题，然则无论若何照样避免不了减库存这类的年夜并发写问题，这也是秒杀场景中最焦点的技巧难题。

统一数据在数据库里确定是一行存储( MYSQL)，所以会有年夜量的线程来竞争INNODB行锁，并发度越高时期待的线程也会越多，TPS会降低而RT会上升，数据库的吞吐量会严重受到影响。这里会涌现一个问题，即单个热门商品会影响全部数据库的机能，涌现我们不肯意看到的0.01%商品影响9999的商品的情形。此处的解决思绪也是要遵守前面介绍的第一个原则“隔离” 把热门商品放到零丁的热门库中尽管这会带来保护的麻烦(要做热门数据的动态迁徙以及零丁的数据库等)把热门商品分别到零丁的数据库并没有解决并发锁的问题，要解决并发锁问题有以下两种方法。

第一种是在运用层做列队。依照商品维度设置队列次序履行，如许能削减统一台机械对数据库统一行记载操作的并发度，也能掌握单个商品占用数据库衔接的数目防止热门商品占用太多的数据库衔接。

第二种是在数据库层做列队。运用层只能做到单机的列队，然则运用层机械数目许多，用这种列队方法掌握并发仍然是很有限的，假如能在数据库层做全局列队是最幻想的。数据库团队开辟了 MYSQL的 INNODB层上的 patch，可以做到在数据库层上对单行记载并发列队。

你可能会有疑问:列队和锁竞争不都是要等得吗，有何差别?假如熟习 MYSQL的话，应当知道 INNODB内部的逝世锁检测以及 MYSQL Server和 INNODB的切换会比拟耗机能， MYSQL焦点团队还做了许多其他方面的网站制造优化，如 COMMIT_ON_ SUCCESS和 ROLLBACK ON FAIL的 patch，合营在SQL里面加hint，在事务里不须要期待运用层提交 COMMIT而在数据履行完最后一条SQL后，依据 TARGET AFFECT ROW成果就直接提交或回滚，如许可以削减收集的期待时光(平均约0.7毫秒)。