扩展阅读
这一小节，我截取自《分布式系统架构》这本书里面，我觉得这个示例写的还不错，分享给大家：
这是一个购物商场的例子：
系统部署在一台 4C/8G 的应用服务器上、数据在一台 8C/16G 的数据库上，都是虚拟机。
假设系统总用户量是 20 万，日均活跃用户根据不同系统场景稍有区别，此处取 20%，就是 4 万。
按照系统划分二八法则，系统每天高峰算 4 小时，高峰期活跃用户占比 80%,高峰 4 小时内有 3.2 万活跃用户。
每个用户对系统发送请求，如每个用户发送 30 次，高峰期间 3.2 万用户发起的请求是 96 万次，QPS=960 000/(4x60x60)≈67 次请求，每秒处理 67 次请求，处理流程如下图有所示：
一次应用操作数据库增删改查（CRUD）次数平均是操作应用的三倍，具体频率根据系统的操作算平均值即可。一台应用、数据库能处理多少请求呢？
具体分析如下。
- 首先应用、数据库都分别部署在服务器，所以和服务器的性能有直接关系，如 CPU、内存、磁盘存储等。
- 应用需要部署在容器里面，如 Tomcat、Jetty、JBoss 等，所以和容器有关系，容器的系统参数、配置能增加或减少处理请求的数目。
- Tomcat 部署应用。Tomcat 里面需要分配内存，服务器共 8GB 内存，服务器主要用来部署应用，无其他用途，所以设计 Tomcat 的可用内存为8/2=4GB (物理内存的1/2)，同时设置一个线程需要 128KB 的内存。由于应用服务器默认的最大线程数是 1000（可以参考系统配置文件），考虑到系统自身处理能力，调整 Tomcat 的默认线程数至 600，达到系统的最大处理线程能力。到此一台应用最大可以处理 1000 次请求，当超过 1000 次请求时，暂存到队列中，等待线程完成后进行处理。
- 数据库用 MySQL。MySQL 中有连接数这个概念，默认是 100 个，1 个请求连接一次数据库就占用 1 个连接，如果 100 个请求同时连接数据库，数据库的连接数将被占满，后续的连接需要等待，等待之前的连接释放掉。根据数据库的配置及性能，可适当调整默认的连接数，本次调整到 500，即可以处理 500 次请求。
显然当前的用户数以及请求量达不到高并发的条件，如果活跃用户从 3.2 万扩大到 32 万，每秒处理 670 次请求，已经超过默认最大的 600 ，此时会出现高并发的情况，高并发分为高并发读操作和高并发写操作。
好了，书上分享的案例就是这样的。
最后说一句(求关注)
好了，看到了这里安排个 “一键三连”吧，周更很累的，不要白嫖我，需要一点正反馈。
才疏学浅，难免会有纰漏，如果你发现了错误的地方，可以在留言区提出来，我对其加以修改。 感谢您的阅读，我坚持原创，十分欢迎并感谢您的关注。
我是 why，一个被代码耽误的文学创作者，不是大佬，但是喜欢分享，是一个又暖又有料的四川好男人。
还有，欢迎关注我呀。
