阿里P8面试官:如何设计一个扛住千万级并发的架构?

大家先思考一个问题,这也是在面试过程中经常遇到的问题 。

如果你们公司现在的产品能够支持10W用户访问,你们老板突然和你说,融到钱了,会大量投放广告,预计在1个月后用户量会达到1000W,如果这个任务交给你,你应该怎么做?
1000W用户的问题分解如何支撑1000W用户其实是一个非常抽象的问题,对于技术开发来说,我们需要一个非常明确的对于执行关键业务上的性能指标数据,比如,高峰时段下对于事务的响应时间、并发用户数、QPS、成功率、以及基本指标要求等,这些都 必须要非常明确,只有这样才能够指导整个架构的改造和优化 。所以,如果大家接到这样一个问题,首先需要去定位到问题的本质,也就是首先得知道一些可量化的数据指标 。
  • 如果有过往的相似业务交易历史数据经验,你需要尽量参考,处理这些收集到的原始数据(日志),从而分析出高峰时段,以及该时段下的交易行为,交易规模等,得到你想要看清楚的需求细节
  • 另外一种情况,就是没有相关的数据指标作为参考,这个时候就需要经验来分析 。比如可以参考一些类似行业的比较成熟的业务交易模型(比如银行业的日常交易活动或交通行业售检票交易活动)或者干脆遵循“2/8”原则和“2/5/8”原则来直接下手实践 。当用户能够在2秒以内得到响应时,会感觉系统的响应很快;当用户在2-5秒之间得到响应时,会感觉系统的响应速度还可以;当用户在5-8秒以内得到响应时,会感觉系统的响应速度很慢,但是还可以接受;而当用户在超过8秒后仍然无法得到响应时,会感觉系统糟透了,或者认为系统已经失去响应,而选择离开这个Web站点,或者发起第二次请求 。
在估算响应时间、并发用户数、TPS、成功率这些关键指标的同时,你仍需要关心具体的业务功能维度上的需求,每个业务功能都有各自的特点,比如有些场景可以不需要同步返回明确执行结果,有些业务场景可以接受返回“系统忙,请等待!”这样暴力的消息,以避免过大的处理流量所导致的大规模瘫痪,因此,学会平衡这些指标之间的关系是必要的,大多数情况下最好为这些指标做一个优先级排序,并且尽量只考察几个优先级高的指标要求 。(SLA服务等级)
SLA:Service-Level Agreement的缩写,意思是服务等级协议 。服务的SLA是服务提供者对服务消费者的正式承诺,是衡量服务能力等级的关键项 。服务SLA中定义的项必须是可测量的,有明确的测量方法 。

阿里P8面试官:如何设计一个扛住千万级并发的架构?

文章插图
 
并发中相关概念的解释在分析上述问题之前,先给大家普及一下,系统相关的一些关键衡量指标 。
TPSTPS(Transaction Per Second)每秒处理的事务数 。
站在宏观角度来说,一个事务是指客户端向服务端发起一个请求,并且等到请求返回之后的整个过程 。从客户端发起请求开始计时,等到收到服务器端响应结果后结束计时,在计算这个时间段内总共完成的事务个数,我们称为TPS 。
站在微观角度来说,一个数据库的事务操作,从开始事务到事务提交完成,表示一个完整事务,这个是数据库层面的TPS 。
QPSQPS(Queries Per Second)每秒查询数,表示服务器端每秒能够响应的查询次数 。这里的查询是指用户发出请求到服务器做出响应成功的次数,可以简单认为每秒钟的Request数量 。
针对单个接口而言,TPS和QPS是相等的 。如果从宏观层面来说,用户打开一个页面到页面渲染结束代表一个TPS,那这个页面中会调用服务器很多次,比如加载静态资源、查询服务器端的渲染数据等,就会产生两个QPS,因此,一个TPS中可能会包含多个QPS 。
QPS=并发数/平均响应时间

阿里P8面试官:如何设计一个扛住千万级并发的架构?

文章插图
 
RTRT(Response Time),表示客户端发起请求到服务端返回的时间间隔,一般表示平均响应时间 。
并发数并发数是指系统同时能处理的请求数量 。
需要注意,并发数和QPS不要搞混了,QPS表示每秒的请求数量,而并发数是系统同时处理的请求数量,并发数量会大于QPS,因为服务端的一个连接需要有一个处理时长,在这个请求处理结束之前,这个连接一直占用 。
举个例子,如果QPS=1000,表示每秒钟客户端会发起1000个请求到服务端,而如果一个请求的处理耗时是3s,那么意味着总的并发=1000*3=3000,也就是服务端会同时有3000个并发 。


推荐阅读