针对高并发业务的应对思考与一些解决办法

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。

响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。

吞吐量：单位时间内处理的请求数量。

QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。

并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

更多的介绍可以看这里
https://www.cnblogs.com/yuwensong/p/9563100.html

高并发业务目前来说应该是避免不开的，目前针对高并发的业务最简单粗暴的方法就是买买买，用更多更强的服务器来生扛业务量的激增（土豪业主 ）
但是这肯定是不可续的，如何低成本高效率的应对并发才是思考的方向（正常业主 ）
我们的做法是这样

终端先访问云服务器 》云服务器访问nginx 》nginx做负载均衡流量发到服务节点 》服务节点根据业务访问数据库 》根据业务类型访问数据库或redis 》返回结果

数据库也要做读写分离，根据业务又分为查询与写入业务，查询业务先访问redis，若存在则返回，若不存在访问读库，从而减少数据库访问量。写入业务时才直接访问写库，进行写入或更新操作，从而避免频繁访问导致的锁库锁表。

这应该是目前较普遍的应对高并发的简单方法，效果目前来看还过得去