🌈🌈🌈🌈🌈🌈🌈🌈
欢迎关注公众号（通过文章导读关注：【11来了】），及时收到AI 前沿项目工具及新技术的推送
发送资料可领取深入理解 Redis 系列文章结合电商场景讲解 Redis 使用场景、中间件系列笔记和编程高频电子书！文章导读地址：点击查看文章导读！
感谢你的关注！
🍁🍁🍁🍁🍁🍁🍁🍁 
生产部署面试实战
接下来说一下，对于 生产部署 方面会从哪些方面来问？
服务如何部署？
比如，你们生产环境中，各个服务是如何进行部署的呢？
其实也就是问：
网关、注册中心以及各个服务是如何部署的？- 部署的
机器配置是怎样的？ - 每天
访问量是多少？ 高峰期接口访问量是多少？
回答的话，也不用回答细节，将整个流程给回答一下：
网关部署 的话，就根据系统的访问量，如果不大，部署 2-3 个网关系统即可
注册中心 一般都是集群部署，比如 zk 集群部署（1 主 2 从）
服务 部署一般看每个服务的负载情况了，负载高的服务，就多部署几个，分散一下请求
而对于 系统访问量 来说，可能很多人都没有什么概念，并且对于机器可以抗多少数量的并发请求也都不太清楚
这些都是属于更细节一些的东西了，属于 进阶部分，可以了解一下，但是深入学习这些内容之前，一定要先将基础把握住，不要本末倒置了
其实想要看系统访问量的话，很简单的一个方式就是，在代码中加入一些统计的接口，比如统计每个接口请求数量、接口请求延时、系统访问量，可以直接在代码中记录，再向外暴露出一个接口，可以查询到这些 统计值
就比如说，一个接口请求一次之后，在代码中，对这个接口请求次数加 1，用 AtomicLong 来统计每天的接口请求数量，接口平均请求延时的话，将接口请求延时加起来除以接口请求次数也能算出来
这里还要了解一下 性能监控 中的一些指标，T99、T95
如 T99 = 50ms，表示 99% 的请求耗费时长都在 50ms 以内
T95 = 50ms，表示 95% 的请求耗费时长都在 50ms 以内
怎么看系统可以承载的最大负荷呢？
使用开源的 压测工具，例如 Jmeter，去模拟用户向系统发送请求
通过控制发送请求数量，查看系统的负载情况，以及系统最多可以处理的并发请求数量
比如发送 1000 个请求，系统只可以处理 800 个，那么就说明系统最大处理并发请求数量为 800
数据库如何部署
对于数据库来说的话，一般也会使用 比较好的机器配置 来部署，16C32G 的机器比较适合，32C64G 的机器可以根据数据库的负载来选择，负载较高的话，可以升级一下机器的配置
那么一般来说 16C32G 的机器，每秒抗 小几千的并发请求 还是问题不大的，只要 不存在一个 SQL 执行 2-3 秒的情况 就可以！
但是对于数据库来说，如果平均每秒都是三四千请求，此时 MySQL 机器虽然不会崩掉，但是它的负载是很高的，包括 CPU 使用率、磁盘 IO、网络负载都是处于比较高的水平
大部分的系统，其实每秒钟也就几十个请求，高峰期几百个请求，系统都是可以抗住的
如果访问量扩大 10 倍，如何应对？
访问量扩大 10 倍的话
-
对于
网关系统来说，部署 10 倍的网关机器即可，再通过 nginx 将请求分发到不同的网关中去，就可以分散大量请求压力
-
对于
服务实例来说，也是比较简单，通过增加服务实例的数量，并且注册到注册中心去，这样通过负载均衡将一个服务的压力也给分散到多个服务实例中去了 -
对于
数据库来说，如果原本高峰期每秒三四百请求，扩大 10 倍后，每秒三四千的访问量，如果对数据库横向扩容比较麻烦，因此可以考虑给部署数据库的服务器提升配置，比如从 16C32G 提升到 32C64G 的配置，抗 3-4000 的请求还是没有问题的
在生产部署面试方面，主要就是问一些系统 QPS 、部署以及应对并发量上来之后的措施，这其实就考察有没有生产经验，或者说你有没有对系统进行过 压测 并进行性能优化
压测方面的内容，可以关注我，发送
"压测"领取一份压测视频教程！
