对于即将到来的双11，高并发简直成为了一个魔咒。尽管在大促活动前加班加点做测试，到了活动当天仍然是危机频发，高并发的关键时刻又出乱子了，紧急排查故障，一个漏洞没注意到就让竞争对手钻了个空子，平台损失严重，还有被媒体曝光的风险。
相信这个场景在双十一阶段并不少见。在超高并发量下，IT 系统如何才能挺住不崩？有没有办法可以提前预测到，并加筑好“防御堡垒”？
大多数同学被问到这个问题压根儿没什么思路去回答，不知道从什么地方说起，其实本质就是没经历过一些真正有高并发系统的锤炼罢了。
一、什么是高并发？
高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。高并发意味着大流量，需要运用技术手段抵抗流量的冲击，这些手段好比操作流量，能让流量更平稳地被系统所处理，带给用户更好的体验。
高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），每秒事务处理量TPS(Transaction Per Second)，并发用户数等。
响应时间：系统对请求做出响应的时间。
吞吐量：单位时间内处理的请求数量。
QPS：每秒响应查询请求数。
TPS：每秒响应事务请求数。
并发用户数：同时承载正常使用系统功能的用户数量。
我们常见的高并发场景有：淘宝的双 11、春运时的抢票、微博大 V 的热点新闻等。
二、多大并发才算高并发呢？
很显然，上面谈到的高并发场景，并发量各不相同，那到底多大并发才算高并发呢？
首先，不能只看数字，要看具体的业务场景。信息流场景涉及复杂的推荐模型和各种人工策略，它的业务逻辑可能比秒杀场景复杂 10 倍不止。因此，不在同一个维度，没有任何比较意义。
此外，各个高并发场景的业务特点完全不同：有读多写少的信息流场景、有读多写多的交易场景，那是否有通用的技术方案解决不同场景的高并发问题呢？
三、如何应对高并发？
由于软硬件环境、技术栈、以及产品逻辑都没法做到完全一致，这些都会导致同样的业务场景，就算用相同的技术方案也会面临不同的问题。大的思路可以借鉴，别人的方案也可以参考，但是真正落地过程中，细节上还会有无数的坑。
下面给大家两个小建议：
其一，购买服务器。当一个网站面对突发流量，不可能临时改造架构，最快的方式就是增加机器来线性提高系统的处理能力。
一支筷子容易断，一把筷子就十分坚固。既然一台服务器搞不定，我们就多上几台服务器。这里的原理就是分流，把以前集中的压力分散开来。
其二，设置负载平衡。负载平衡可以通过多种负载算法将请求转发到不同云服务器上。在后端云服务器宕机时，会自动将对应节点从负载均衡的转发列表中移出保证服务的高可用。
总之，面对高并发、大流量需要新购服务器或设置负载平衡的朋友们，云将是您的不二选择！
设置负载平衡，点击进入云：http:///cs/slb.html