大流量后端架构优化手段整理

大流量，是大多数项目期待的效果，同时也是大多后端技术岗需要面对的一个挑战。今天我把我学习时收集到相关技术手段进行整理，脑图如下：

大流量后端架构优化手段.png

如图所见，可以想到一个逻辑：

大流量 等同于 请求量大
请求量大 引起 高并发
请求量大 同样引起 数据量大
高并发（时间段内需要处理的事多）产生 容器与数据库负载
数据量大 产生 数据库负载

综上所述，可以总结出最后两个问题：

• 容器负载
• 数据库负载

说白了，就是负责解析服务端脚本的容器（apache或php-fpm）的压力很大，还有mysql的压力很大。

那么，我们就需要想办法解决它们的压力。

先说说mysql：

• 减少操作mysql的次数
• 当我们使用缓存技术、页面静态化技术，可以减少对mysql的访问次数，这个非常重要，假设请求量是一百万，如果每次都查询数据库，则不仅容器处理了一百万次请求，数据库也处理了至少一百万次操作（一次对容器的请求，可能涉及到多次数据库操作），这个时候如果合理利用了静态化技术，虽然没有减少容器的压力，但却大大减少了mysql的压力。
• 提升mysql的处理效率
• 包括索引优化、配置优化、分表技术、硬件升级，都是提升mysql处理效率的有效手段，当然，更重要也是最基本的，是设计一个合理的表结构
• 减轻mysql服务的压力
• 当一个人干不过来的事，那就多找几个人来干，谁都知道这个道理。所以，读写分离（均衡负载）是非常有效的手段。

再说说容器：

• 优化程序
• 至少别让程序做一些毫无意义的事，优化算法和优化逻辑。
• 均衡负载
• 硬件的解决，效果显著，立竿见影，但是费钱。软件的解决则普遍依靠nginx来解决。

另外，除了优化这些压力意外，我们还必须面对大流量引起的一个问题——带宽。
通常情况下，除了优化带宽开支（如使用对象存储、压缩资源等）和提升带宽意外，好像我也没有想到什么别的办法了。

总结

---

本文主要整理了一下“大流量后端架构”的优化手段，以填充后端开发人员的解决思路。在有些公司，均衡负载、读写分离可能是运维的事情，但作为后端，而且对技术有一种特殊的执着，我还是认为有必要对这些有了解，更应该去亲手实践一下。

本文来自半醒的狐狸博客