如何设计一个高并发的系统？

如何设计一个高并发的系统？

从以下6点着手：

• 系统拆分
  将一个系统拆分为多个子系统，然后每个系统连接一个数据库，这样本来一个库现在多个数据库，也可以抗住一定的高并发。
• 缓存
  必须得使用缓存，大部分高并发场景都是读多写少，那么你完全可以数据库和缓存里都写一份，读的时候大量走缓存，缓存redis单机轻轻松松抗住几万的并发。所以你可以考虑你的项目中读场景，怎么用缓存来抗高并发。
• MQ
  可能还会出现高并发的场景，比如说一个业务操作里需要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对会挂掉你的系统，你如果用redis来承载写肯定是不行，人家是缓存数据随时会被淘汰掉，数据格式还无比简单，没有事务支持。所以还是得使用mysql。那就用MQ吧，把大量的写请求灌入到MQ中，排队慢慢处理，后边系统消费后慢慢写，控制在mysql能承受的范围内。所以你得考虑你的项目里，那些承载复杂业务逻辑的场景里，如果用MQ来异步写，提升并发性。MQ单机抗几万并发也是OK的。MQ特性异步、肖峰、解耦。
• 分库分表
  到了后面一个数据库还是扛不住高并发，好吧，那就将一个数据库拆分为多个库，多个库来抗更高的高并发；然后把一个表拆分为多个表来提高sql的跑的性能。
• 读写分离
  大部分时候数据库可能是读多写少，没必要所有的请求都集中在一个库上，可以搞一个主从架构，主库写入，从库读取，搞一个读写分离。读请求大的时候可以增加更多的从库。需要注意主库与从库之间的时延问题。
• ElasticSearch
  Elasticsearch，简称es。es是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来扛更高的并发。那么一些比较简单的查询、统计类的操作，可以考虑用es来承载，还有一些全文搜索类的操作，也可以考虑用es来承置。

上面的6点，说句实话，不是在于弄明白一些技术，或者大概知道一个高并发系统应该长什么样？其实实际上在真正的复杂的业务系统里，做高并发要远远比上面提到的点要复杂几十倍到上百倍。你需要考虑：哪些需要分库分表，哪些不需要分库分表，单库单表跟分库分表如何join，哪些数据要放到缓存里去，放哪些数据才可以扛住高并发的请求，你需要完成对一个复杂业务系统的分析之后，然后逐步逐步的加入高并发的系统架构的改造，这个过程是无比复杂的。
其实大部分公司，真正看重的，不是说你掌握高并发相关的一些基本的架构知识，架构中的一些技术，RocketMQ、Kafka、Redis、Elasticsearch，高并发这一块，你了解了，也只能是次一等的人才。对一个有几十万行代码的复杂的分布式系统，一步一步架构、设计以及实践过高并发架构的人，这个经验是难能可贵的。