前言：终于有时间能来研究研究自己感兴趣的东西了，这里假设我们系统部署的机器是 4 核 8G，数据库服务器是 16 核 32G，这篇文章也算是高并发的一个引子，后面会据此篇进行扩展，扩展一些其它高并发优化技术与一些高并发优化技术的具体应用场景与具体代码实现，因为本篇文章大部分算是转载的，所以就标个转载了，不过本人对原文章还是进行了微调以及加进了自己的总结与反思，供本人复习之用。
参考：https://www.jianshu.com/p/4f35b3ad47bc（此篇文章绝大部分转载于此博客）
目录
第一章 估算网站的访问量
此时假设你的系统用户量总共就 10 万，用户量很少，日活用户按照不同系统的场景有区别，我们取一个较为客观的比例，10% 吧，每天活跃的用户就 1 万。
按照 28 法则，每天高峰期算它 4 个小时，高峰期活跃的用户占比达到 80%，就是 8000人活跃在 4 小时内。
然后每个人对你的系统发起的请求，我们算他每天是 20 次吧。那么高峰期 8000 人发起的请求也才 16 万次，平均到 4 小时内的每秒（14400 秒），每秒也就 10 次请求服务器。
然后系统层面每秒是 10 次请求，对数据库的调用每次请求都会有好几次数据库操作的，比如做做 crud 之类的。
那么我们取一个一次请求对应 3 次数据库请求吧，那这样的话，数据库层每秒也就 30 次请求。
按照这台数据库服务器的配置，支撑是绝对没问题的。上述描述的系统，用一张图表示，就是下面这样：
第二章 系统集群化部署
假设此时你的用户数开始快速增长，比如注册用户量增长了 50 倍，上升到了 500 万，此时日活用户是 50 万，高峰期对系统每秒请求是 500/s。然后对数据库的每秒请求数量是 1500/s，这个时候会怎么样呢？
4 核 8G 的机器每秒请求达到 500/s 的时候，很可能你会发现你的机器 CPU 负载较高了。
然后数据库层面，以16 核 32G而言，其实基本上 1500/s 的高峰请求压力的话，还算可以接受。
对我们来说，解决这种情况最简单的应该是系统的集群化部署，即将系统从单实例，扩展为多实例，比如说这里假设给系统增加部署一台机器，那么每台机器就只有 250/s 的请求了。
第三章 数据库分库分表 + 读写分离
假设此时用户量继续增长，达到了 1000 万注册用户，然后每天日活用户是 100 万。
那么此时对系统层面的请求量会达到每秒 1000/s，系统层面，你可以继续通过集群化的方式来扩容，反正前面的负载均衡层会均匀分散流量过去的。
但是，这时数据库层面接受的请求量会达到 3000/s，这个就有点问题了，每次到了高峰期，磁盘 IO、网络 IO、内存消耗、CPU 负载的压力都会很高，一般来说，对那种普通配置的线上数据库，建议就是读写并发加起来，按照上述我们举例的那个配置，不要超过 3000/s。
此时需要对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这是作为主库承载写入请求的，然后每个主库都挂载至少一个从库，由从库来承载读请求。
那么一旦分库分表之后，采用两台数据库服务器上部署主库来支撑写请求，每台服务器承载的写并发就是 500/s。
每台主库挂载一个服务器部署从库，那么 2 个从库每个从库支撑的读并发就是 1000/s。
第四章 缓存集群引入
如果你的注册用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。
在数据库层面，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库（这里个人有点疑问，写在了第六章）。
但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。
所以在这里对那种写少读多的请求，可以引入缓存系统，就是在写或读数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。
比如说上面那个图里，读请求目前是每秒 2000/s，两个从库各自抗了 1000/s 读请求，但是其中可能每秒 1800 次的读请求都是可以直接读缓存里的不怎么变化的数据的。
那么此时你一旦引入缓存集群，就可以抗下来这 1800/s 读请求，落到数据库层面的读请求就 200/s。
按照上述架构，它的好处是什么呢？
可能未来你的系统读请求每秒都几万次了，80%~90% 的请求都是读请求（个人推断，这个还是要看实际项目），如果用缓存可能两三台机器就够了，要是换成是数据库，可能就要不停的加从库到 10 台、20 台机器才能抗住每秒几万的读并发，那个成本是极高的。
第五章 引入消息中间件集群
上面主要是缓解读方面的压力，如果集群的压力再增大，我们需要缓解写方面的压力，缓解写压力的方法之一可以引入MQ，因为有一些写入的操作可以不用立即写入，可以将信息写入MQ，由消费者慢慢处理写入写数据库。
假如说，你现在每秒是 1000/s 次写请求，其中比如 500 次请求是必须请求过来立马写入数据库中的，但是另外 500 次写请求是可以允许异步化等待个几十秒，甚至几分钟后才落入数据库内的。
那么此时你完全可以引入消息中间件集群，把允许异步化的每秒 500 次请求写入 MQ，然后基于 MQ 做一个削峰填谷。
比如就以平稳的 100/s 的速度消费出来，然后落入数据库中即可，此时就会大幅度降低数据库的写入压力。
第六章 个人总结
这篇文章的概要大概是这样的，4核8G的系统服务器大概的处理能力为500QPS，16核32G数据库服务器处理能力大概
为3000QPS。网站的优化流程从前到后大概是如下流程。
1. 网站会遇到系统服务器的瓶颈，对于这个瓶颈可以将服务器从单实例扩展程多实例。
2. 网站会遇到数据库方面的瓶颈，可以将数据库进行拆解，进行分库分表，读数据从读库进行读取，写数据从写库进行处理。
3. 读压力继续增大时，简单的拆解会导致数据库服务器台数过多等问题，所以一般采用缓存中间件，将要不怎么变化的（应该正常的项目大概百分之90数据都不怎么变化）数据缓存到中间件中，这样能缓解大部分读压力。
4. 缓解了读压力就要缓解写压力了，这里作者提出了用MQ缓解写入压力，即将不需要立即写入数据库的数据写到MQ中，然后由消费者慢慢写入数据库来缓解压力。
第七章 个人反思感悟
7.1 反思
这篇文章对我这种刚入门的人来说还挺有帮助的，但是对其中的几点还存有疑问，后面会查找资料求证。
1. 一般高并发的系统都会将系统进行拆分，组成分布式系统，如对于商城的话会拆分程商品模块，订单模块，用户模块等等，每个模块自成一个系统，这篇文章中并没有提到在哪里拆分系统，个人推测可能会有以下几种可能(1) 在系统设计的时候就按分布式系统来设计(2)在分库分表的同时拆分系统，如将订单和商品系统解耦(3) 拆解在最后一步后面，即用MQ缓解写压力都不行的情况下便进行系统拆分。
2.在第三步引入缓存集群时说，引入缓存集群是因为数据库服务器一般配置比较高，比较贵，我想这和数据库多了之后同步效率降低是否也有关系，同时上面的架构用到了分表，我想是不是和分表如果数据库多了不利于分表也有关系，后面要看看在具体的场景下怎么分库分表以及数据库的主库与从库的同步流程。
7.2 感悟
这篇文章通过简练的语言说明了如何进行一些优化，但具体的优化步骤还需要在下面再进行学习，比如将单实例扩展成多实例时用户的登陆如何处理，如何在实际的场景中进行分库分表，即分库分表的准则是什么，进行读写分离的在代码上的实现，当使用缓存时遇到了缓存穿透、缓存击穿、缓存雪崩怎么办，当使用MQ进行异步处理时，如何保证事务的一致性，这都是后面要学习的。
在文章的最后作者提到了一个完整而复杂的高并发系统架构中，一定会包含如下内容，这里个人对基础自研架构还是挺感兴趣的，因为目前网上说到的一些高并发的解决方案好象都是利用现成的框架做的，如数据库分库分表有专门的数据库中间件，消息传递有RocketMQ和kafka等精妙的消息中间件，分布式存储有FDFS等等，还没见到过为了解决某个特定场景单独设计的基础自研架构，可能大厂里面会有，但是这种应该不可能给出来，后面打算去找找哪里有这种东西然后学习以下。
- 各种复杂的自研基础架构系统。
- 各种精妙的架构设计（比如热点缓存架构设计、多优先级高吞吐 MQ 架构设计、系统全链路并发性能优化设计，等等）。
- 还有各种复杂系统组合而成的高并发架构整体技术方案。
- 还有 NoSQL（Elasticsearch 等）/负载均衡/Web 服务器等相关技术。
761
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
