1.为什么上网人数多，很多APP、网站、系统承载高并发请求，高峰期可能每秒上千并发，这很正常。尤其是电商APP，如果是双十一之类的，每秒几万、几十万的并发访问都是有可能的。高并发访问带来的问题是系统和数据库无法处理，容易宕机。要知道数据库支持到每秒2000到3000并发的时候就快完蛋了。如果数据库瞬间承载5000、8000，甚至几万个并发，那肯定会崩溃。比如mysql根本无法处理这么高的并发。那么这么高的并发量，加上这么复杂的业务，我们应该如何设计一个能够支持高并发访问的系统，主要从以下几点来考虑：系统拆分使用缓存引入MQ分库分库分离表读写2.高并发系统设计要点2.1．系统拆分一个大系统基于微服务架构拆分成多个子系统。该技术使用SpringCloud实现，每个子系统都连接到一个数据库，以至于本来是一个库，现在是多个数据库，也可以处理高并发。2.2、使用cache缓存，一定要使用缓存。大多数高并发场景需要多读少写。我们可以在数据库和缓存中都写入一份，然后大量读取缓存。我们可以引入Redis作为分布式缓存的技术方案。Redis单机支持每秒几万并发，集群情况下甚至每秒几十万并发。所以我们要考虑项目中承载主要请求的读取场景，如何使用缓存来抵抗高并发，同时还要处理好【缓存雪崩】、【缓存穿透】的问题，[缓存故障]2.3。引入MQMQ，必须使用MQ。因为系统还是会有高并发写入的场景。比如在一次业务操作中，数据库要频繁使用几十次，增删改查。在高并发访问的情况下，数据库肯定会挂掉。这时候就可以考虑MQ了。调峰，先把大量的写请求倒入MQ，排队慢慢播放，待会儿被系统消费后再慢慢写，控制在数据库的负载范围内。所以我们不得不考虑在项目中承载复杂编写业务逻辑的场景下，如何使用MQ异步编写，提高并发性。MQ单机可以处理上万并发。MQ技术选择可以选择使用rabbitMq或者Kafka。当然，系统引入MQ后，也会降低整个系统的可用性，增加系统的复杂度。系统引入的外部依赖越多，越容易挂掉。所以引入MQ之后，需要考虑【如何保证消息队列的高可用】，【如何保证消息不被重复消费】，【消息丢失如何处理】，【如何保证消息传递的顺序]等问题。MQ的引入有很多好处，但是必须做出各种额外的技术方案和架构来避免它带来的弊端。2.4.分库分表，分库分表可能在最终的数据库层面为了抵抗高并发需求是不可避免的，那么将一个数据库拆分成多个库，多个库可以处理更高的并发；然后将一张表拆分成多张表，将每张表的数据量保持在一定范围内，提高SQL运行的性能。推荐使用ShardingSphere作为分库分表的技术方案。2.5.读写分离。这意味着大多数时候，数据库可能读多写少。从架构上看，主库写，从库读，搞了一个读写分离。当阅读流量过大时，可以添加更多的从库。
