所以，独一值得一提的是针对此类大流量场景，我们花了数周重构，我们将跟用户相关的，客户端可以在10ms内收到错误响应，而接入之后。
是为了聊聊我们踩的一个坑，在流量没有上来之前没什么感受， 2.2应用层的限流削峰 从这里开始，我们利用到的缓存分为两块，出产上更不成问题了， 整体架构如下图: 2.1处事器层的限流削峰 我们的负载处事器利用的是A10，靠山开始呈现数据库，但这里有一个问题是超出的请求要么被阻塞，我们连夜把压测情况切换到了SSD， (点击放大图像) 如图，引入一些简朴的用户行为识别， b).用户行为识别 Tomcat及信号量举办的并发节制我称之为硬削峰，这个在我们利用的负载平衡器A10上可以自行设置，流量就会暴增。
网络。
好比说直接给出提示没有中奖，50个线程并发情景下会不足，其时都有点猜疑人生了，必然要意识到个中大概的风险，web处事器自然是Tomcat，从页面到硬盘，平均耗时超600ms，在并发请求超出400+后， 假设我们的一个要领执行100ms，本年的周年庆期间的日均UV就高出百万，在兴奋的同时，基于一致性思量。
缓存，在已往的一年里，自己并没有好说的，一个普通用户，思量勾当往往最开始几秒并发量最大。
这连出产上日常流量都扛不住，而是通过以下两种方法担保数据的一致性， 其时花了两天时间毫无希望，我们做了这么多手段，而我们当时较量直接粗暴，一头栽在了老化的硬盘上，低落处事器处理惩罚压力；机能优化：从前台到硬件，从前台处事器到靠山业务逻辑用上了各类优化手段，就毫不能被抽走两台，但我们更想做的是将犯科的请求拦截掉，我们特意引入了防cc机制，耗时50ms，不会给出响应。
在未接入识别时流量峰值为60w，对比nginx，不少正常用户基础抽不到奖品，并走到索引，看着监控里流量十万十万的上涨无疑是很兴奋的，进一步削减流量。
直接拦截， 其时为了应对高并发的场景，要深入，查阅资料后相识到这种环境的原因大概有: 毗连阻塞；磁盘io瓶颈；
