本文讲述了作者在面临App高并发问题时，如何从理论出发理解并发用户数和QPS，并分析了现有服务器（Tomcat）的承载能力。面对未来可能的增长，作者探讨了数据库读写分离和使用Redis作为缓存的解决方案，倾向于后者以应对大量读写操作。此外，还提及了Nginx在负载均衡中的作用，为未来扩展服务器集群打下基础。
App频繁访问服务器造成的高并发问题
这一系列写的比较杂，基本上是想到什么写什么。自从App开发和后台管理模块完善的差不多之后，我开始考虑起服务器的高并发问题。
这里简单说一下什么是服务器的并发（以下内容来源于网上）：
服务器并发量分为：1.业务并发用户数；2.最大并发访问数；3.系统用户数；4.同时在线用户数； 一般只需要分析出业务并发用户数。
在网上找了个计算业务并发用户量的公式： C=nL/T C是平均的业务并发用户数、n是login session的数量、L是login
session的平均长度、T是指考察的时间段长度。
假设OA系统有1000用户，每天400个用户发访问，每个登录到退出平均时间2小时，在1天时间内用户只在8小时内使用该系统。
C=400×2/8=100
然而，我的业务场景比较特殊，基本上需要假设所有用户全部在线（假设10000来算），而且是24小时不间断自动运行，所以公式就变成了这样：
C = 10000
并发用户数就是用户数，那每秒访问量（QPS）则为10000/60=166。
我用的是tomcat服务器，Tomcat 默认配置的最大请求数是 150，也就是说同时支持 150 个并发，假设我的请求平均需要500ms处理完成，则每秒并发量在300左右。
现在看来是完全够用的，但是一般架设服务器需要在目前性能的基础上提高一倍的性能空间，也就是说刚刚够用，如果用户数量再多一些，或者不巧某几
最低0.47元/天 解锁文章
扫一扫
901
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
