参照一个大佬的文章，我也写一篇应对高并发的文章

待我称王封你为后i 2021-10-09 07:30 334阅读 0赞

参照一个大佬的文章，我也写一篇高并发的文章，探讨一下这门高级的现象，以及一些解决措施。

一个关于高并发的问题：

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

那位大佬说：如果真的干过高并发系统的人，面试官是绝对不会对你提出这个问题的，否则就是他太不明智了。至于为嘛这样说呢，因为如果设计一个高并发系统，这句话就是错误的了，因为在脱离了业务的系统架构中都是一群纸上谈兵，真正在复杂业务场景而且存在高并发的时候，那系统架构一定不是那么简单的，用个redis、消息队列就能解决？那不是扯淡吗？在真实的实际开发中，系统架构配上了业务场景后，会比这种所谓的“高并发”要复杂的多多的。

为什么会出现高并发呢？为啥高并发听起来就很牛掰的一个东西呢？一个并发很厉害，加一个高就更加高级了，都是服务级别了。

那么到底什么是高并发呢？

先说下是什么原因会出现高并发系统的，在刚刚开始的时候，一些基础的系统，都是直连数据库的，直接对数据库操作CRUD，在之前的帖子里面，我也说到过，对于MySQL而言，能够一秒承受2000的并发量就差不多了，真达到5000，估计就瘫了。那么在从前信息量还没有大爆炸之前，2000的并发并未常见，但是现在就不一样的，现在人人都接触了互联网，很多的app，网站，实时在线人数就达到了几万，甚至上百万，在大型的网络活动的时候，几千万的人在线并不是不可能的。例如淘宝的双十一，那是普通用户没感觉，在阿里内部，每年双十一一过去，就开始着手准备来年的双十一技术支持了，做电商的朋友最烧脑的就是类似秒杀活动了，双十一0点的时候，每秒十几万的并发量那不是跟吃面条一样么？？？所以，现在用户量越大，那么作为技术储备，架构支撑，我们就要考虑从系统架构上来应对高并发的请求了。。

那么从那个大佬帖子中共总结了6点，我就用我自己的理解来讲解一下，有哪些并发系统设计的优化方案，向这些优化方案都是高级操作，所以大家能够学习就坚决学习一下。

1.系统拆分：为啥要拆分？这就是做分布式的概念了，将整个系统按照各个服务进行划分，各司其职，然后通过webservice或者rpc通讯机制，服务间内部通讯，一种面向服务（SOA）的架构思维。就好比一堆人开个饭馆，A侧重做端菜，服务员的业务，B侧重做炒菜的业务，C作为老板，只是在前台安排一下新来的客人做哪里，然后安排A带领去，然后收一下银之类的；由于炒菜可能业务量比较重，为了让菜炒得及时，炒得好吃，那么B专职只炒菜；A呢，有可能早上的时候，人少，那么也充当一下配菜的角色，帮助B进行一下早上的切菜，那这就是分布式思想了。那么针对收银，在超市里面，我们通常可以看到有多个收银的入口，这样的话，是不是就分担了收银的压力了呢？收银员干得活都一样的。但是就是有好几个人同时在收银，那么顾客看到哪里人排队少，那么顾客就会去那里排队，均摊每个收银队伍的长度了。那么在系统中，也是模拟类似的思想来增加结账的效率，我们可以通过一些分布式框架来搭建一个分布式系统，然后有可能多个服务节点在分布式架构中注册，然后做着同样的业务处理，设计多个数据库集群部署，那么多个数据库，一个数据库最大扛2000，多个2000，并行工作，那并发量的瓶颈就接触了。

2.缓存，缓存这个概念其实在任何的设备上都有直接的应用，怎么理解呢？好比一个手机，内存和硬盘，我们在打游戏的时候，刚刚启动和平精英，是不是需要弹一个天美，，然后一个烧鸡？然后正在加载中？然后再一步步进到吃鸡的运行界面中？是的，它正是从Android系统中自带的sqlite轻量数据库读取游戏的数据信息，这种db操作是很耗时，耗资源的。那我们已经启动好了游戏，临时退出一下游戏，去聊个天，然后再返回的时候，它并不需要像刚启动那样一点一点加载，而是直接就加载好的，这就是它游戏数据直接在内存中准备好了，并没有回收。这个例子也不一定和缓存，db的概念一模一样，理解个大概意思。只需要记住，高速缓冲区不是数据库直接能比的，要知道，redis可是轻轻松松单机应对几万的并发量的。所以在系统中缓存必须要，尤其在于那些主read业务的服务中，可能就是配合多个缓存服务工作的，缓存的作用可不止那么点，比如缓存共享，分布式锁，各种提高业务的处理能力的支持。那么至于高并发系统中，缓存是一员大将。

3.MQ（消息队列）消息队列，在我的另一篇文章中有详细的介绍过消息队列的几大优点，以及任何架构带来优点的同时都会带来一些弊端，这里就不详细介绍了。昨天朋友说到一个问题，他把余额宝的钱提取到银行卡的时候，发现余额宝中的钱扣了，但是银行卡中还没到账，然后他有点慌，哈哈。其实我们大家都有类似的经历，我们从各种支付平台，网络账户进行余额提现的时候都会发现一个提示：提现24小时内到账。快一点的2小时到账。这也是银行系统的一种自保机制，提现是需要等待的。这么讲，倘若，好多个平台，同时提现到一家银行，在一秒钟，这家银行突然同时收到了5000的提现请求，需要在各自对应的账户中打款，然后加事务，给各大平台响应，我这边加好钱了，你那边赶紧扣，或者说我这边加钱的时候碰到点问题，失败了，你那边回滚一下。想想，这流程还是挺复杂的，5000/秒，系统也吃不消啊，那么就需要中间件的接入了，比如消息队列，你们进来的提现请求，一个个排好队，我加钱一个个加，不要着急，我一累倒了，谁都加不了。我叫下一个的时候，我再把你的请求领进来加钱。这样就是将加钱服务的业务量平摊，将顶峰进行削峰了。但是我立马回了我朋友一句，要是消息丢失啦这咋办。哈哈，平台扣了钱，银行卡钱没加上。。那就GG了，所以也就有了备份节点待命的保护机制，如果像这种主从服务，主服务挂了，那么其他配合的服务等同于挂了，那系统也挂了。回到正题，高并发系统怎么通过MQ来进行并发压力降低。也是一个道理，排队，我db操作慢慢来，需要异步，但是这样是最好保护我系统的方式，能做的，只有我加硬件，算法优化，将这“慢慢来”的速度提升，按照2000最大的mysql，一秒5000，也就是2-3秒的延迟感，而且我们都是异步机制，几乎对于用户来说就是无感的。那么你几万，我多开几个收银入口，那或许来说原来1秒，我现在就是0.2秒了。

4.分库分表，如果还问有什么优化的空间，那就在数据库的角度进行优化了，且不说那种粒度小的优化方式。可以从冷热数据，按业务将数据库的表分成几个库，几个数据库服务。如果是那种记录表，可以按年月划分不同时间段表，这样，每一张表的IO压力就降低了，我就不信了，这还防不住并发？

5.读写分离：这其实也是也是数据库角度的优化方案，我公司现在用到的一张表就是几乎的读操作，原始数据表，根本不让更新，删除操作，然后读取的话，通常都是后台erp管理系统用于数据统计用到，这是在erp后台系统中，然后写入操作，就是在examservice中进行检测业务时进行队列写入的。那么这里我们也可以用一个主从架构，主库负责写入，我负责生产，从库负责读取，那么这样再添加一个从库也是很方便的，多一个消费服务就是了。

6.ElaticsSearch(基于Lucene的开源搜索项目)，这是大数据范畴的一个工具了，其中的倒排索引，索引量爆炸都为主核心，想我们熟悉的百度搜索引擎，谷歌搜索引擎，都是应用到这个倒排索引的方案，然后再基于一些网页爬虫进行的操作了。因为es是基于分布式的，那么可以随意的扩容，分布式的诞生一部分原因就是为了支撑高并发的，那么至于其中的倒排索引原理，我就现先不在这里细讲了，下次再写篇文章细讲一下。所以在搜索引擎框架的选用，全文搜索的操作可以选择es来承载。

基本上来说，以上6点都是很常见的并发系统设计方案，对于选择的时候，也要根据实际的业务场景来进行并发系统设计。需要考虑哪些表结构的哪个字段添加索引，索引添加不当，反而会性能降低；哪些需要分表，分表后，到时候有哪些业务需要链表查询，哪些的操作频率高，我们都需要考虑取舍的。哪些数据是需要放到缓存的，因为有些需要实时更新的，我们需要实时的从db中读取，哪些数据的并发访问的，这些地方都要考虑缓存击穿，缓存穿透，缓存雪崩。所以说，设计一个高并发的系统，设计好了，无疑是好的，是可以抗很大并发压力的，但是要知道有些时候，杀鸡用牛刀，你多浪费的力气做什么。系统集成的架构越多，维护的成本就会越大，而且，并发系统在市面上都是通用的，并不是针对某个公司现状针对设计的，所以得结合公司项目自身的情况来进行适当的选择。

祝各位代码无bug！！

这里拷贝一张别人的图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FMTEVOc2FrYXJ1_size_16_color_FFFFFF_t_70][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FMTEVOc2FrYXJ1_size_16_color_FFFFFF_t_70]: /images/20211009/93da9c2a3def48dbbfa3ff8071f14916.png