对于秒杀还是心存敬畏的，一直都觉得很牛逼，又没机会深入接触。
不过，确实也经历过一些对性能要求较高的场景，当然，那毕竟不是秒杀。
第一个就是微信信息流投放，少于30w的qps的公司就不要去找它投放，后来咋搞的，没咋搞，就是堆了非常多的机器，代码几乎没改。过程中要用多少硬件支撑就是它最大的问题。另一个问题是它的所有硬件，都是另起一套。这个投放简单的原因，主要就是它是在读。仅仅是读，就容易很多。
第二个场景是对码，但对码的优化非常基于业务特点，能优化出来也是有点侥幸的。是用了几个方法，第一是多线程并行来对码，第二是合并同类项，第三是热点的多重缓存，第四是搜索引擎替代数据库。回想起来也是比较通用的方式。
第三个场景是营销活动，也很容易，就是上了消息队列，避免顺时的高并发。
那后来也学了一些课程讲电商的秒杀的。多少了解了一些思路，用自己的话来总结一下。
第一是要区分好读和写。读都好办，有各种缓存，比如cdn、redis、localcache。写比较麻烦，特别是强一致性地减库存。
第二是有个请求漏斗。有一些请求可能是不合格的，比如人是要做一些验证码的校验的，如果短于1s，就是有问题的，可能是机器人，就要屏蔽掉它。
第三是Jvm层有一些极致优化的方法。比如让RPC调用变成本地调用，这有一些特殊的工具做到，这就减少了序列化的开销。还有当然也可以用一下多线程，但线程的数量其实是要计算的，要看是io密集还是运算密集，io密集就可以多点线程，最后通过压测来计算得出。还有是不用mvc框架而直接用servelt，少了一些框架自然也少了一些性能开销。
第四是借助缓存或消息队列。缓存不必说，哪能缓就都缓上。消息队列就是通过排队的方式，一点点的消化请求。这可以避免请求太多，系统直接就宕机了。于是可以让系统尽量保持在吞吐效果最高的状态。
第五是减库存强一致性的关键问题。这个逃不开必须由数据库做。那同样是通过应用层和数据库层的排队的方式来减少瞬时的并发。瞬时并发高了，整体吞吐就会差的。
第六是兜底。降级、限流、拒绝服务。依次去设置即可。
网友评论