转载：https://www.cnblogs.com/imyalost/p/15422896.html

上周四（10月14日）晚，受邀参加了由数列科技主办的线上技术直播——PGUG系列-大促保障之旅，其中我分享的Topic是《大型业务活动，如何保障系统的稳定性》。

分享过程中，参与直播的同学们提了很多问题，碍于很多问题无法一两句概括，因此写了这篇文章，对这些同学提出的问题做一个解答。当然，回答仅限于我个人的角度，仅供参考。

Question

编号	提问用户微信名	提问的问题
1	Armo	流量模型具体指得是什么？
2		怎么根据入口流量和内部流量的成份比例关系进行计算？
3		流量的预估上是怎么做的呢？
4		容量水位是怎么定义的？当前QPS/按照压测的QPS？
5	王雷	K8S是不是自动扩容？
6	空	在压测时，请求参数一般都是重复的吗？
7	空	在压测过程的时候，怎么确定多少连接数比较合适？比如，Redis连接数，数据库连接数，线程数，Tomcat连接数？
8	Macan	容量水位如何评估是否扩展讲细一点？还有自动扩缩容调度决策如何制定？
9	多的	应用服务可以通过这些方式达到高性能高可用，但是相对应的，数据库DB也会有大量的数据读写操作，这也可能导致DB挂掉，请问这种情况怎么办？

Answer

PS：很多问题归类下来都很类似，我归纳汇总下来，主要有如下几点：

流量模型

关于流量模型，大家先看下面这幅图：

1、流量模型具体指得是什么？

分布式服务架构下，服务间调用关系是及其复杂的。如上图所示，一个用户请求，要经过层层调用，才能到达数据库。

且调用过程中，对Redis、MQ或其他下游服务的调用可能要多次。这就导致了一种现象：用户请求一次，对下游的其他服务或者中间件可能请求了多次，这样就形成了一个漏斗状的模型。

到这里，流量模型是什么的答案，其实已经出来了。非要做一个定义的话，我认为应该这样定义：

流量模型：系统处理用户请求过程中，请求对系统内部服务及中间件的调用形成的关系集合；

如何理解：所谓的流量模型这种关系集合，一般来说都是都是漏斗形状，即上窄下宽；

2、流量的预估上是怎么做的呢？

流量预估，一般的步骤如下：

确定业务目标（技术最终要为业务目标达成负责）；
转化为核心链路技术指标（电商行业核心链路一般为订单量）；
依赖流量模型，由核心链路进行转化计算（一般都是选取峰值的请求流量）；

3、怎么根据入口流量和内部流量的比例关系进行计算？

以第二个问题的预估步骤为例，参考如下计算方式：

业务目标：今年双十一，业务目标是DAU1000W，支付单量100W；
假设创建订单接口和发起支付接口比例为3:1，那么支付接口QPS=100W；

假设往年大促80%的支付请求分布在双十一0点前一个小时，前一个小时请求中，前十分钟占比60%；
由上可得：支付接口QPS=100W*80%*60%=48W，创建订单接口QPS=3*100W*80%*60%=144W；

平均到秒级别，支付接口QPS=800，创建订单接口QPS=2400；
以核心链路的QPS为基准，按照流量模型调用关系进行放大或者缩小计算，即可得出每个应用大促峰值需要承接的QPS；

PS：QPS如何得到？依赖监控系统！

容量评估

4、K8S是不是自动扩容？

k8s是为容器服务而生的一个可移植容器的编排管理工具，从架构设计层面我们关注的可用性、伸缩性都可以结合k8s得到很好的解决。

从服务部署运维、服务监控、应用扩容和故障处理，k8s都提供了很好的解决方案。具体来说，主要包括以下几点：

服务发现与调度；
负载均衡；
服务自愈；
服务弹性扩容；
横向扩容；
存储卷挂载；

PS：综上所述，服务弹性扩容只是K8S的功能之一，且弹性扩缩容，除了K8S还有其他的实现方式和工具。

5、容量水位是怎么定义的？当前QPS/按照压测的QPS？

如何理解容量？举个例子：一台4C8G的虚拟机，在CPU使用率达到最大值时，它的处理能力(TPS)是500。

但线上正常的服务负载，一般不会让超过40%，这也是所谓的安全水位。在安全水位下，可能这台虚拟机的处理能力只有200。这就是所谓的容量水位，安全水位。

容量水位定义：系统处于X并发情况下，保证安全水位时候的处理能力。

参照上述第三个问题的回答：如果某个核心接口的预估峰值QPS=2400，那这个接口所在的服务集群，最少的机器数量应该为12+（需要留一定的buffer，保证冗余空间）。

PS：需要注意的是：一个服务对应多个接口，需要保证被测接口的请求在该服务占据绝大部分。

6、容量水位如何评估是否扩展讲细一点？还有自动扩缩容调度决策如何制定？

容量水位评估，参照上述第五个问题。

自动扩缩容调度决策，实现的逻辑无非就是单机设定一个阈值，超过该阈值自动扩容服务。需要注意的是，负载均衡有时候不是完美的，还需要一个集群的阈值，配合服务健康检查。

PS：扩容一般都需要有热备的机器，容器相对扩容速度更快一些，如果是ECS等虚拟机，需要考虑机器热备。

压测配置

7、在压测时，请求参数一般都是重复的吗？

压测请求用到的数据，一般有3种：

基础数据：数据库表中用于铺底的基础数据，比如商品信息，库存数之类的；
幂等数据：常见的只读接口，如果不涉及逻辑校验，可以用重复的数据；
热点数据：即参数化数据，比如用户的userid，手机号等，部分业务逻辑涉及到唯一性校验；

参数配置

8、在压测过程中，怎么确定多少连接数比较合适？比如，Redis连接数、数据库连接数、线程数、Tomcat连接数？

一般常用的中间件，应用容器和DB，都会有默认的参数配置和官方推荐的配置。但考虑到不同的业务场景和技术实现方式，都是采用配置测试的方式来调整验证配置。

比如Tomcat的线程数，之前我做过类似的验证：1台16C32G的机器，性能和负载最均衡的线程配置数是256。

官方推荐的好像也是16N（这里的N指的是服务器的物理核数）。当然，配置为512，性能更好一些，但机器负载相对会更高一些。

PS：以Tomcat为例，线程配置也分为最小连接数和最大连接数，活跃线程数和最大等待线程数以及timeout。这几个配置参数之间，也是有关系的，建议看看官方文档了解下不同参数配置的含义。

DB高可用

9、应用服务可以升配扩容达到高性能，但是对应DB也会有大量读写操作，这可能导致DB挂掉，这种情况怎么办？

目前来说，数据库的性能瓶颈只能通过升配、分库分表、拆分实例来提升。当然，优化慢SQL、事务合并、技术改造直连DB为读写缓存，也是一种方式，但根本上还是治标不治本。

结语

上述问题的有些回答，我的回复只能作为参考，因为每个人面临的技术和业务挑战都不一样，还是需要灵活评估解决的。

很多问题或者遇到的疑惑，需要大家自己去探索。成长是一个闭环，需要学习-实践-试错-复盘-不断优化。上述的答疑中留了一些问题，相关同学如果感兴趣，可以尝试思考如何解决它们。

标签：服务,水位,接口,连接数,答疑,直播,流量,QPS,10.14
From： https://www.cnblogs.com/ceshi2016/p/17234025.html

10.14：线上直播问题汇总答疑