支付宝架构师的总结：为什么他们能抗住万亿级流量的高并发？（下篇）

集群

对于用户访问集中的业务独立部署服务器，应用服务器，数据库，nosql数据库。核心业务基本上需要搭建集群，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务， 服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可, 另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性

应用服务器集群
nginx 反向代理
slb
… …
(关系/nosql)数据库集群
主从分离，从库集群

通过反向代理均衡负载-图2来自网络

异步

在高并发业务中如果涉及到数据库操作，主要压力都是在数据库服务器上面，虽然使用主从分离，但是数据库操作都是在主库上操作，单台数据库服务器连接池允许的最大连接数量是有限的

当连接数量达到最大值的时候，其他需要连接数据操作的请求就需要等待有空闲的连接，这样高并发的时候很多请求就会出现connection time out 的情况

那么像这种高并发业务我们要如何设计开发方案可以降低数据库服务器的压力呢？

如：
自动弹窗签到，双11跨0点的时候并发请求签到接口
双11抢红包活动
双11订单入库
等

设计考虑：
逆向思维，压力在数据库，那业务接口就不进行数据库操作不就没压力了
数据持久化是否允许延迟？
如何让业务接口不直接操作DB，又可以让数据持久化？

方案设计：
像这种涉及数据库操作的高并发的业务，就要考虑使用异步