高并发通用解决方案_推荐机制 like-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_48242059/article/details/140262169

核心逻辑

找出单点，进行拆分，单点指的是在web系统中，流量必须经过的结点解决，高并发问题的过程中，我们会不断地遇到各种单点：Web Server、单个操作系统、虚拟化/容器技术、编程语言运行架构、网络、Unix 进程模型、数据库等。每遇到一个单点，我们都要见招拆招，使用架构工具拆掉它。计算机的虚拟化程度非常高，理论上每个单点都是可以继续往下拆分的。

所有的性能提升都靠架构提升，无论是Mysql优化还是硬件优化

没有银弹

在信息世界里，没有银弹是第一准则，想要获得性能收益就必须拿出东西交换，架构优化就是拿去一定的资源换取性能，根据业务需求调整架构方案，在高读的场景下如何保证服务的稳定，在写场景下如何保证，这都需要我们根据具体业务思考

动态，静态资源拆分

Apche与Nginx的性能差异，大概是1:4，如果你的应用还在使用Apche来承载流量，那只需要在前面加上一个nginx，便可以在系统配置不变的情况下，提升系统容量一倍，且nginx对图片和视频流式传输进行了优化，引入nginx反而降低了cpu占用率和内存容量，在如今流量越来越便宜的时代，静态资源反而呈指数级上升，Nginx的优势还在延续

使用CDN

如果你在用云服务的话，那么把静态资源全部交给云服务商的 CDN 来承载，还可以再获得 90% 的 CPU 节省。同时，CDN 的流量费还比云主机的流量费更便宜，时至今日中国 CDN 市场已经卷的不像样子了。

数据库

将数据库和后端代码放在同一台服务器上是一种”灾难架构“，同时Mysql单独部署的表现十分出色，实测一台1核2G的服务器上单独部署，QPS也能来到200

在这个小小的例子中，我们已经在不经意间窥探到了过去数十年运维技术圈的基本哲学：从物理机到虚拟机，从虚拟主机到云主机，再从云主机到 Kubernetes，虽然推动运维架构演进的是越来越复杂的软件架构和越来越多的计算资源需求，但是运维的基本哲学是不变的：

运维的核心价值不在于资源的扩充，而在于资源的隔离。

实际案例

维护一个面向 SEO 的 CMS（内容管理系统）网站，该网站每日 PV 达到两百万。这类网站往往有很多的“相关内容”需求，需要进行类似于搜索引擎的“相关查询”，导致页面相应十分缓慢。由于内容的独特性，经常受到爬虫和采集机器人的关注，导致频繁被爬取，给运维工作带来了很大压力。

随着网站内容的逐渐丰富，除了被正规蜘蛛访问外，某一天还突然遭遇了每秒 100 次 HTTP 请求的采集机器人袭击，当时的配置是可怜的 1 核 2G 云主机和 1 核 1G 的 MySQL 数据库，网站瞬间就宕机了。后来，在网站恢复以后，测试了一下，由于页面的复杂度非常高，当 QPS 达到 7 以后，数据库就会满载，随后云主机也会满载，网站就挂了。

落地解决方案：

动静分离，将静态资源放入CDN，CDN具有强缓存的特点，服务器CPU损耗降低90%

这个web系统当时采用like来实现文章推荐机制，我们预设了一个关键词库来实现，但这个服务器造成很大的压力，利用 Elasticsearch 提升网页响应速度，我们单节点部署在一台8核32G的机器上，让ES来完成搜索任务，响应时间从300ms~500ms，减低到200ms左右

mysql索引优化

在绝大多数情况下，要想优化性能，mysql索引优化都是我们的第一选择，这种策略甚至可以带来几十倍的性能提升，只需要消耗小部分资源

为什么不做静态化？

这个时候可能有人会问了，既然是内容网站，为什么不静态化呢？因为数据量太大了，500 万个页面，一个页面 100KB，就是 476GB 的磁盘容量，这个量级太大了。

在这个规模下，和缓慢但可用的数据库相比，这么多静态资源的管理和刷新反而是个更大的问题，不如选择做数据库和架构优化，问题会更少。在百万量级下，数据库绝对是更好的数据存储解决方案，远比自己管理文件要更简单更稳定。如果我们从头观察数据库的发展史，就会发现数据库就是为了处理单靠读写一堆磁盘文件已经无法满足需求的场景而被发明出来的。