大话程序猿眼里的高并发

分层，分割，分布式

大型网站要很好支撑高并发，这是需要长期的规划设计 ，在初期就需要把系统进行分层，在发展过程中把核心业务进行拆分成模块单元，根据需求进行分布式部署，可以进行独立团队维护开发。

网站分层-图1来自网络

集群

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

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

异步

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

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

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

缓存

高并发业务接口多数都是进行业务数据的查询，如：商品列表，商品信息，用户信息，红包信息等，这些数据都是不会经常变化，并且持久化在数据库中高并发的情况下直接连接从库做查询操作，多台从库服务器也抗不住这么大量的连接请求数（前面说过，单台数据库服务器允许的最大连接数量是有限的）。

那么我们在这种高并发的业务接口要如何设计呢？

面向服务

使用服务化思维，将核心业务或者通用的业务功能抽离成服务独立部署，对外提供接口的方式提供功能。

最理想化的设计是可以把一个复杂的系统抽离成多个服务，共同组成系统的业务，优点：松耦合，高可用性，高伸缩性，易维护。

通过面向服务化设计，独立服务器部署，均衡负载，数据库集群，可以让服务支撑更高的并发。

由于服务需要记录用户的各种操作行为，并且可以重复上报，准备接入服务的业务又是核心业务的用户行为跟踪，所以请求量很大，高峰期会产生大量并发请求。

冗余，自动化

当高并发业务所在的服务器出现宕机的时候，需要有备用服务器进行快速的替代，在应用服务器压力大的时候可以快速添加机器到集群中，所以我们就需要有备用机器可以随时待命。 最理想的方式是可以通过自动化监控服务器资源消耗来进行报警，自动切换降级方案，自动的进行服务器替换和添加操作等，通过自动化可以减少人工的操作的成本，而且可以快速操作，避免人为操作上面的失误。

通过事件，我们应该反思，做了备份数据并不代表就万无一失了，我们需要保证高可用性，首先备份是否正常进行，备份数据是否可用，需要我们进行定期的检查，或者自动化监控， 还有包括如何避免人为上的操作失误问题。（不过事件中的开放性姿态，积极的处理方式还是值得学习的)。

总结

高并发架构是一个不断衍变的过程，冰冻三尺非一日之寒，长城筑成非一日之功

打好基础架构方便以后的拓展，这点很重要。

文章转载自SFLYQ—《大话程序猿眼里的高并发之续篇》

面对千亿级数据，快速找到问题原因所在是每个高并发网站的头等大事，使用听云APM实现性能监测，即时获取相关性能数据进行智能分析，帮助运维人员快速找到网络瓶颈，再次提升运维效率，实现最佳用户性能体验。点击“阅读原文”申请听云产品免费试用。