前言
要说最近一段时间最火的话题是什么,那必定是《羊了个羊》,频频冲上微博热搜第一。因访问量骤增,大量玩家涌入进来,高并发流量导致游戏服务器被接连击穿。《羊了个羊》服务器几天内就出现了多次异常,无法登录游戏。
问题思考
我想这其中多次崩溃的原因可能很多:可能是高并发流量导致服务器负载打满,引发宕机;可能是数据库查询量较大,出现性能瓶颈;也可能是高并发访问将缓存击穿;还有可能是受到ddos攻击…
曾经我面试的时候就有面试官问道:“现在让你设计一个业务场景,客户端访问我们的业务服务端,从最初的业务规模很小,到后面业务规模业务很大,你应该如何设计并改进?”
现在具有一定规模的业务场景必定都采用了高并发的架构。
本文将以业务刚开始搭建到业务规模壮大为引子,详细讲一讲高并发架构是如何一步一步实现的,也很好的回答了上面的那道面试题。
高并发架构演进
1. 单机架构提供服务
业务初期,用户量很少,百来十个请求,一台服务器就可以部署应用和数据库。
使用后端编程语言(python、go、php、java)开发一个应用程序,然后使用一个数据库(mysql、sqlserver)再存储业务数据。应用和数据库运行在同一台机器上面,开始对外提供服务。
2. 应用服务和数据库分离
用户开始增多,应用服务和数据库产生资源争抢,一台服务器使用起来够呛,于是将应用服务和数据库进行拆分,一台服务器专门跑应用程序,一台服务器专门跑数据库。
3. 增加缓存数据库
随着用户量进一步增多,每次访问都和数据库交互,会十分影响系统的响应速度,所以可以使用缓存技术。针对热点数据,直接从内存中取出来返回,加快响应速度。
4. 引入负载均衡
用户量还在进一步增多,单一应用服务器性能不足以支撑业务,系统开始变得卡顿。为了防止宕机导致业务不可用,这时需要增加多台应用服务器,形成集群,使用负载均衡进行负载(软件负载均衡nginx、haproxy),提高并发访问量。
5.数据库读写分离
用户数量的增长,数据量激增,数据库的读写压力就增大了。数据库开始出现瓶颈,读写变慢。但对于数据库来说,无法简单的应用集群来解决压力问题,因为数据会不一致,所以需要采用读写分离,写走主库,读走从库(事务中的读也要走主库)。
6.数据库拆表分库
业务数据量越来越大时,所有的业务都存储在单一的数据库中,即使单一的数据库已经做了读写分离,但是因为数据量庞大,依然无法满足系统性能的要求,这时就需要拆表分库。同一张表的数据拆分到多个数据库中(水平拆分),把单个数据库中的不同业务拆分到不同的数据库服务器中(垂直拆分)。
7. 使用硬件负载均衡
业务越来越火爆,用户量还在激增,最终软件负载均衡也扛不住了。那就采用硬件负载均衡(F5),将流量分发到不同的软件负载均衡上面,提高访问性能。
8. DNS轮询负载
当用户还在数几十万几百万的增长时,硬件防火墙也扛不住了。这时咱们再采用DNS轮询的方式,将访问域名解析到多个机房的IP上面,不同地区的用户访问到不同的IP上面。千万级到亿级的并发量都可以通过增加机房来解决。
9. 引入高防系统
随着业务的知名度越来越高,可能会受到外部的ddos攻击,导致正常的请求流量无法进入系统,用户访问失败。这时就需要引入高防系统,清洗异常流量。
10. 引入WAF应用防火墙
后来,业务系统经常受到SQL注入、XSS跨站、Webshell上传、CC攻击。这时需要引入WAF应用防火墙,有效识别Web业务流量的恶意特征,在对流量清洗和过滤后,将正常、安全的流量返回给服务器,从而保障系统的业务安全和数据安全。
上面讲解了高并发架构的演进之路,当然,根据实际业务情况,我们可能还需要引入Nosql数据库,时序数据库,消息队列,CDN等系统,甚至需要进行微服务的拆分,进一步强大健壮我们的业务系统。
参考文档
https://mp.weixin.qq.com/s/BABN6y2mYj2Cd-p0dlb6Ug文章来源:https://www.toymoban.com/news/detail-415842.html
微信关注我,获取更多干货!
文章来源地址https://www.toymoban.com/news/detail-415842.html
到了这里,关于由《羊了个羊》想到的高并发架构之路的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!