那么如此之高的并发量，加上原本就如此之复杂的业务，我们该如何设计一个可以支持高并发访问的系统呢，主要从以下几点去考虑：
- 系统拆分
- 使用缓存
- 引入MQ
- 分库分表
- 读写分离
二、设计高并发系统的关键点
2.1、系统拆分
将一个大的系统拆分为基于微服务架构的多个子系统，技术落地选择使用SpringCloud来做，然后每个子系统连一个数据库，这样本来就一个库，现在多个数据库，这样也可以扛高并发。
2.2、使用缓存
缓存，一定要用缓存。大部分的高并发场景，都是读多写少，我们完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存，可以引入Redis作为分布式缓存的技术解决方案，redis单机就支持每秒几万的并发，在集群情况下更是可以达到每秒几十万的并发。所以我们要考虑项目里那些承载主要请求的读场景，怎么用缓存来抗高并发，同时也得处理好【缓存雪崩】、【缓存穿透】、【缓存击穿】这些问题
2.3、引入MQ
MQ，一定得用上MQ。因为系统还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，那高并发访问的情况下绝对搞挂数据库，这个时候就可以考虑用MQ去削峰，将大量的写请求先灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在数据库承载范围之内。所以我们要考虑项目里那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机可以扛得起几万并发。MQ的技术选型可以选择用rabbitMq或者Kafka。当然了，系统引入MQ之后，也会导致整个系统的可用性降低，系统复杂度提高，系统引入的外部依赖越多，越容易挂掉。所以引入MQ后，要考虑【如何保证消息队列的高可用】、【如何保证消息没有重复消费】、【如何处理消息丢失的情况】、【如何保证消息传递的顺序性】等问题，引入MQ有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉。
2.4、分库分表
分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，那么就将一个数据库拆分为多个库，多个库来扛更高的并发;然后将一个表拆分为多个表，每个表的数据量保持在一定范围内，提高sql跑的性能。推荐使用ShardingSphere作为分库分表的技术解决方案
2.5、读写分离
读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。
