你开发的系统到底可以支撑多少并发访问？ _并发访问

你开发的系统到底可以支撑多少并发访问？100万？10万？1万？1千？500？为什么能支撑，又为什么不能支撑？这是个直击心灵的问题，能否准确回答这个问题是程序员的一个分水岭，也是一个能否持续做技术的门槛，能够准确回答的人，可以不看这篇文章了，如果仔细思考过这个问题但是却没有思路去回答这个问题的人，建议读下去。
微服务不等于高并发，集群也不等于高并发， k8s更不等于高并发，一提性能优化就想到压测，连压测结果是否合理可能都不知道，如何去优化呢？就是用explain去看看sql么？
所谓的高并发是针对某些大用户量同时访问系统的场景抽象而出的一个模糊的概念，高并发只是所有那些场景的统称，所以不存在高并发的通用解决方案，只存在某些特定场景的解决方案。经过多年N多个高并发场景的不断积累，目前针对特定的高并发场景均有相对成熟的解决方案，但仅仅是解决方案，对于具体业务还需要具体分析。
讲个故事针对一个简单场景分析，开发了一个系统，若干个功能，会存在问题么？如果只是几百个活跃用户，谈不上什么并发，那么很简单，只需一个应用集群和一个数据库主备即可，基本上80%的中小型公司开发的系统都是这样部署的，一个Tomcat集群，一个主备MySQL数据库，有钱的客户来个主备的oracle就行了。此时无所谓什么性能优化，如下图：

文章插图

但是，此时，如果发现活跃用户数到了几千上万，突然有一天客户跟你说，系统崩了，无法访问或者特别慢，此时到服务器上一看，进程还在啊， CPU也算正常啊，数据库也还好啊，然后看日志，没什么报错啊，顶多是sql超时了，很可能会说，系统正常运行着，怎么访问不了了呢，重启下吧，重启之后一切正常，客户让你写故障报告，你憋了半天来了句可能是网络问题，或者实话实说系统没发现什么异常，不知道为何重启就好了，这个事儿可能就过去了。之后很可能每隔一段时间来一次重启，如果一直没解决，也许客户失去信心，也就不用这个系统了。这是一个比较常见的场景，我遇到过很多客户的软件开发商都是这样处理问题的，这也是市面上大多数开发人员想要高并发经验但是又没有高并发经验的原因。很多时候不是没场景，而是即使遇到问题也没思路解决。
故事的第一阶段完了，现在需要针对第一阶段来分析分析，如何解决这次的宕机问题。当系统的用户数从几百逐渐增加到几万的时候，如果预先没有针对高并发场景进行特殊设计，那么当高并发或频繁访问某个功能的时候就会出现此类问题，要么是数据库崩了一堆网络请求异常，要么是系统特别慢一个接口执行个几十秒，要么是系统内存溢出了。为何会出现这个问题？80%的原因都是数据库查询太慢了，这就是最常见的瓶颈点——数据库慢查询。
哪出的问题数据库慢查询的原因实在太多， sql编写不规范，没有遵循ESR原则，业务复杂等等。抛去数据库问题先不谈，先说说瓶颈是如何出现的，为何某几个查询慢会导致服务器全面崩溃-雪崩呢，雪崩之后我们应该如何分析如何下手呢？看看下图，一个请求从服务端接收开始，一直到数据库，然后再返回给前端，大概经过这些步骤。这个时候我们就得逼着自己思考几个问题了，假定100并发进来的时候，哪会存在瓶颈呢？网络处理？程序执行？数据库查询？为什么存在或不存在瓶颈将是一个直击灵魂的问题让你久久不能寐。