一、为什么要做高并发
- 首先你得知道你当前的项目为什么要做高并发，之前的单体架构为什么不满足你的需求？
- 当前的系统架构已经远远不能满足你的业务需求？
- 当前的系统的并发数已经越来越多，加机器代理已经无法解决此问题？
- 当前系统用户数越来越多，数据量越来越大，数据库极可能在崩的边缘？
- 当前公司的业务数上来了，需要提升性能。
二、如果做到高并发呢？
分析： 以数据库mysql而言其单库单表的情况下并发量最多可以达到2000-3000，在往上就可能数据库就扛不住更高的并发量，这是你肯定得想分库分表造起来，不够的话再加MQ队列来抗并发，这样可以满足你的业务需求的并发量。所以说这个只是数据库层面上的一些解决方案，但是你的系统其他层次也是需要提升的，接下来给大家介绍一下基本高并发系统需要具备哪些东东？
- 系统拆分
- 缓存
- MQ
- 分库分表
- 读写分离
- ElasticSearch
三、模块分析
- 系统拆分
将系统按照业务模块化的形式拆分成多个子系统，用dubbo来搞,将所有的服务注册到注册到中心上去，这样的子系统有单独的库，不行分别加库加表（涉及数据的导入可用：1.停机机制 2.双写机制（推荐）），这样就可以抗得住你的高并发了 - 缓存
当前系统都是肯定要将缓存搞上去的，大部分开发的人员都知道现在的数据读多写少，像redis随便能抗得住几万的并发，可以根据你自己的业务场景将数据放入缓存中，提高你的系统并发量，问题是你得根据场景用缓存来抗并发 - MQ
为你的数据库减轻压力，提高数据库的写能力，我们可以将大量的写请求放入到我们的队列中，然后让下游的数据库慢慢的写入，这样异步写入到数据库，毕竟MQ是没有问题的，比如单机版的RabbitMQ都能抗得住好几万的并发量。这样数据库的并发就很好的解决了 - 分库分表
如果你的数据库的并发还没有上来，那你就分库分表呗，保证一下每张表的数据量不超过500万，提高mysql的读写能力，这样不就解决了问题了吗 - 读写分离
你可以做一个主从复制模式，或者是多主多从，这样主进行写数据，从进行读数据，做到读写分离，当你的读流量过大时你可以随意的加个从数据库上去抗并发 - ElasticSearch
es,天然的分布式，可以随便扩容，可以随意的根据你的并发量来扩容，对于一些查询，全文搜索可以用它来替你分担。
四、总结
做完了上述东西，再业务中需要考虑：哪些需要分库分表，哪些不需要分库分表，单库单表跟分库分表如何 join，哪些数据要放到缓存里去，放哪些数据才可以扛住高并发的请求，你需要完成对一个复杂业务系统的分析之后，然后逐步逐步的加入高并发的系统架构的改造，这个过程是无比复杂的，加油吧，一起成长！！！
标签：分库,数据库,系统,并发,缓存,分表,设计 From： https://www.cnblogs.com/qxlzzj/p/18129103