本文目录导航：
关于惊群效应
什么是惊群，这篇文章写的很好： 举一个很便捷的例子，当你往一群鸽子两边扔一块食物，只管最终只要一个鸽子抢到食物，但一切鸽子都会被惊扰来争夺，没有抢到食物的鸽子只好回去继续睡觉， 期待下一块食物来到。
这样，每扔一块食物，都会惊扰一切的鸽子，即为 惊群 。
关于操作系统来说，多个进程/线程在期待同一资源是，也会发生相似的成果，其结 果就是每当资源可用，一切的进程/线程都来竞争资源，形成的结果：参考 1）系统对用户进程/线程频繁的做有效的调度、上下文切换，系统系能大打折扣。
2）为了确保只要一个线程失掉资源，用户必需对资源操作启动加锁包全，进一步放大了系统开支。
关于惊群效应的场景形容，最经常出现的就是关于socket操作符的accept操作的形容。
当多个用户进程/线程同时监听同一个端口时，由于实践上一个恳求上来，只要一个进程/线程accept成功，所以就会发生惊群效应。
实践上这是一个很新鲜的疑问。
linux操作系统在内核层面很早就处置了这个疑问，一个恳求上来，内核只会唤醒一个进程来accept，这样就没有惊群现象了。
然而在很多场景下，只需有竞争，就或许会出现惊群效应。
比如经常出现的消费者-消费者模型，普通来说消费或许会比拟耗时，所以消费者会有多个。
当突然有消费者往队列外面投了一个job时，这些消费者就会一哄而上去队列中抢这个job，这就出现了惊群效应。
一个基本的线程池框架也是基于消费者-消费者模型的。
也就是说只需用到了进程池或许线程池，你或许就防止不了要处置惊群效应带来的疑问。
所以 你能觉失掉惊群效应的无处不在了吗 。
。
。
那么关于线程池这个模型，我们怎样处置它或许出现的惊群疑问呢？
一个线程池的定义普通如上所示：有最大线程数限度max_threads，以后线程数curr_threads和闲暇线程数idle_threads，而后还有线程互斥锁，还有线程条件变量， 每个线程条件变量对应一个惟一线程 ，而后还有一个线程义务队列(链表)。为什么须要线程条件变量和线程义务队列这些？？
消费者普通在期待义务和处置义务的环节中，处置逻辑可以简化为：
假设消费者有义务了，就会经过内核通知消费者。消费者的通知环节可简化为：
留意上方用的是pthread_cond_signal，这个是依据进程条件变量来通知某一个期待消费的线程，而不是用pthread_cond_broadcast函数来广播给一切期待义务的消费者，这样就不会发生惊群效应。
pthread_cond_signal函数的作用上方也说了，是依据条件变量发送信号给一个正在休眠期待消费的线程，这个休眠消费线程失掉到这个信号后马上激活，启动消费。
假设某一时辰，一切的消费线程都在启动各自的消费，此时又有一个消费者发送了一个义务，如今没有闲暇消费者来接怎样办？？
在这种状况下，消费者调用pthread_cond_signal函数也会立刻前往，只不过此时不是依据条件变量通知一个消费线程来accept，而是将此义务放到线程池队列中去，期待有闲暇的消费线程上来取。
上方说了一个条件变量对应一个消费线程（意思就是每次都能依据过后的条件找到惟一的一个消费进程），那条件变量究竟是什么呢？？
条件变量的作用就是挑选出一个最适合的消费线程。那消费者消费了一个义务后，是怎样依据条件变量挑选出那个最适合的消费线程的呢？？
假定有多个消费线程正在休眠，首先依据各消费线程优先级的高下确定哪个线程接纳到信号开局继续口头。
假设各线程优先级相反，则依据期待时期的长短来确定哪个线程取得信号。
在上方这种机制下，我们能保证消费者消费了一个义务后只会通知惟一的一个消费者线程，所以不会出现惊群效应。等等，到目前为止，我们定义的线程池中，pthread_mutex如同并没有用到呢？？
刚刚我们只是假定有pthread_cond_signal这种函数来保证每个义务只通知一个惟一的消费进程，那假设有的系统没有这样的繁多通知机制，只要pthread_cond_broadcast函数这种广播机制怎样办？？
此时pthread_mutex这个线程池互斥锁便派上用场了。在只要pthread_cond_broadcast函数这种广播机制的状况下，经过一个线程互斥锁，给每一个消费者线程创立一个条件变量......（如同原文前面说的不是很清楚）
【大意】：在线程池中，参与一组线程条件变量，对应于每一个线程。
参与义务的时刻，假设有闲暇线程，那么只通知某一个闲暇线程，并且将其置忙。
忙与闲，可以经过条件变量来表征，用一个链表示意(相似衔接池)。
假设一切线程都忙，那么就将义务参与全局队列，并且通知一切消费者（这时惊群是很小的，除非一切线程都刚好同一时辰成功义务，同一时辰争夺资源，否则只要极少数线程会出现惊群）。
上方也说道了linux在操作系统层曾经防止了惊群效应的出现，然而nginx作为一个移植性十分高的web主机，它自己也成功了一套防止出现惊群效应的机制。
高并发，你真的了解透彻了吗？
高并发，简直是每个程序员都想领有的阅历。
要素很便捷：随着流质变大，会遇到各种各样的技术疑问，比如接口照应超时、CPU load升高、GC频繁、死锁、大数据量存储等等，这些疑问能推进我们在技术深度上始终精进。
在过往的面试中，假设候选人做过高并发的名目，我通常会让对方谈谈关于高并发的了解，然而能系统性地回答好此疑问的人并不多。
大略分红这样几类：
1、对数据化的目的没有概念 ：不清楚选用什么样的目的来权衡高并发系统？分不清并发量和QPS，甚至不知道自己系统的总用户量、生动用户量，平峰和高峰时的QPS和TPS等关键数据。
3、了解全面，把高并发设计同等于性能优化 ：大谈并发编程、多级缓存、异步化、水平扩容，却漠视高可用设计、服务控制和运维保证。
4、把握慷慨案，却漠视最基本的物品 ：能讲清楚垂直分层、水平分区、缓存等大思绪，却没看法去剖析数据结构能否正当，算法能否高效，没想过从最基本的IO和计算两个维度去做细节优化。
这篇文章，我想联合自己的高并发名目阅历，系统性地总结下高并发须要把握的常识和通常思绪，宿愿对你有所协助。内容分红以下3个部分：
高并发象征着大流量，须要运用技术手腕抵制流量的冲击，这些手腕好比操作流量，能让流量更颠簸地被系统所处置，带给用户更好的体验。
我们经常出现的高并发场景有：淘宝的双11、春运时的抢票、微广博V的热点资讯等。
除了这些典型事情，每秒几十万恳求的秒杀系统、每天千万级的订单系统、每天亿级日活的信息流系统等，都可以归为高并发。
很显然，上方谈到的高并发场景，并发量各不相反， 那究竟多大并发才算高并发呢？
1、不能只看数字，要看详细的业务场景。
不能说10W QPS的秒杀是高并发，而1W QPS的信息流就不是高并发。
信息流场景触及复杂的介绍模型和各种人工战略，它的业务逻辑或许比秒杀场景复杂10倍不止。
因此，不在同一个维度，没有任何比拟意义。
2、业务都是从0到1做起来的，并发量和QPS只是参考目的，最关键的是：在业务量逐突变成原来的10倍、100倍的环节中，你能否用到了高并发的处置方法去演进你的系统，从架构设计、编码成功、甚至产品打算等维度去预防和处置高并发惹起的疑问？而不是一味的更新配件、加机器做水平裁减。
此外，各个高并发场景的业务特点齐全不同：有读多写少的信息流场景、有读多写多的买卖场景， 那能否有通用的技术打算处置不同场景的高并发疑问呢？
我觉得大的思绪可以自创，他人的打算也可以参考，然而真正落地环节中，细节上还会有有数的坑。
另外，由于软配件环境、技术栈、以及产品逻辑都没法做到齐全分歧，这些都会造成雷同的业务场景，就算用相反的技术打算也会面临不同的疑问，这些坑还得一个个趟。
因此，这篇文章我会将重点放在基础常识、通用思绪、和我曾经通常过的有效阅历上，宿愿让你对高并发有更深的了解。
先搞清楚高并发系统设计的目的，在此基础上再探讨设计打算和通常阅历才无心义和针对性。
高并发绝不象征着只谋求高性能，这是很多人全面的了解。
从微观角度看，高并发系统设计的目的有三个：高性能、高可用，以及高可裁减。
1、高性能：性能表现了系统的并行处置才干，在有限的配件投入下，提高性能象征着节俭老本。
同时，性能也反映了用户体验，照应时期区分是100毫秒和1秒，给用户的感触是齐全不同的。
2、高可用：示意系统可以反常服务的时期。
一个全年不停机、无端障；另一个隔三差五出线上意外、宕机，用户必需选用前者。
另外，假设系统只能做到90%可用，也会大大连累业务。
3、高裁减：示意系统的裁减才干，流量高峰时能否在短时期内成功扩容，更颠簸地承接峰值流量，比如双11优惠、明星离婚等热点事情。
这3个目的是须要通盘思考的，由于它们互关系联、甚至也会相互影响。
比如说：思考系统的裁减才干，你会将服务设计成有形态的，这种集群设计保证了高裁减性，其实也直接优化了系统的性能和可用性。
再比如说：为了保证可用性，通常会对服务接口启动超时设置，以防少量线程阻塞在慢恳求上形成系统雪崩，那超时时期设置成多少正当呢？普通，我们会参考依赖服务的性能表现启动设置。
再从微观角度来看，高性能、高可用和高裁减又有哪些详细的目的来权衡？为什么会选用这些目的呢？
2.2.1 性能目的
经过性能目的可以度量目前存在的性能疑问，同时作为性能优化的评价依据。
普通来说，会驳回一段时期内的接口照应时期作为目的。
1、平均照应时期：最罕用，然而缺点很显著，关于慢恳求不敏感。
比如1万次恳求，其中9900次是1ms，100次是100ms，则平均照应时期为1.99ms，只管平均耗时仅参与了0.99ms，然而1%恳求的照应时期曾经参与了100倍。
2、TP90、TP99等分位值：将照应时期依照从小到大排序，TP90示意排在第90分位的照应时期， 分位值越大，对慢恳求越敏感。
3、吞吐量：和照应时期呈正比，比如照应时期是1ms，则吞吐量为每秒1000次。
通常，设定性能目的时会统筹吞吐量和照应时期，比如这样表述：在每秒1万次恳求下，AVG控制在50ms以下，TP99控制在100ms以下。
关于高并发系统，AVG和TP分位值必需同时要思考。
另外，从用户体验角度来看，200毫秒被以为是第一个分界点，用户觉得不到提早，1秒是第二个分界点，用户能感遭到提早，然而可以接受。
因此，关于一个 肥壮 的高并发系统，TP99应该控制在200毫秒以内，TP999或许TP9999应该控制在1秒以内。
2.2.2 可用性目的
高可用性是指系统具备较高的无端障运转才干，可用性 = 反常运转时期 / 系统总运转时期，普通经常使用几个9来形容系统的可用性。
关于高并发系统来说，最基本的要求是：保证3个9或许4个9。
要素很便捷，假设你只能做到2个9，象征着有1%的缺点时期，像一些大公司每年动辄千亿以上的GMV或许支出，1%就是10亿级别的业务影响。
2.2.3 可裁减性目的
面对突发流量，无法能暂时变革架构，最快的形式就是参与机器来线性提高系统的处置才干。
关于业务集群或许基础组件来说，裁减性 = 性能优化比例 / 机器参与比例，现实的裁减才干是：资源参与几倍，性能优化几倍。
通常来说，裁减才干要维持在70%以上。
然而从高并发系统的全体架构角度来看，裁减的目的不只仅是把服务设计成有形态就行了，由于当流量参与10倍，业务服务可以极速扩容10倍，然而数据库或许就成为了新的瓶颈。
像MySQL这种有形态的存储服务通常是裁减的技术难点，假设架构上没提早做好布局（垂直和水平拆分），就会触及到少量数据的迁徙。
因此，高裁减性须要思考：服务集群、数据库、缓存和信息队列等两边件、负载平衡、带宽、依赖的第三方等，当并兴旺到某一个量级后，上述每个要素都或许成为裁减的瓶颈点。
了解了高并发设计的3大目的后，再系统性总结下高并发的设计打算，会从以下两部分倒退：先总结下通用的设计方法，而后再围绕高性能、高可用、高裁减区分给出详细的通常打算。
通用的设计方法关键是从「纵向」和「横向」两个维度登程，俗称高并发处置的两板斧：纵向裁减和横向裁减。
3.1.1 纵向裁减（scale-up）
它的目的是优化单机的处置才干，打算又包含：
1、优化单机的配件性能：经过参与内存、 CPU核数、存储容量、或许将磁盘 更新成SSD 等堆配件的形式来优化。
2、优化单机的软件性能：经常使用缓存缩小IO次数，经常使用并发或许异步的形式参与吞吐量。
3.1.2 横向裁减（scale-out）
由于单机性能总会存在极限，所以最终还须要引入横向裁减，经过集群部署以进一步提高并发处置才干，又包含以下2个方向：
1、做好分层架构：这是横向裁减的提早，由于高并发系统往往业务复杂，经过火层处置可以简化复杂疑问，更容易做到横向裁减。
上方这种图是互联网最经常出现的分层架构，当然实在的高并发系统架构会在此基础上进一步完善。
比如会做动态分别并引入CDN，反向代理层可以是LVS+Nginx，Web层可以是一致的API网关，业务服务层可进一步按垂直业务做微服务化，存储层可以是各种异构数据库。
2、各层启动水平裁减：有形态水平扩容，有形态做分片路由。
业务集群通常能设计成有形态的，而数据库缓和存往往是有形态的，因此须要设计分区键做好存储分片，当然也可以经过主从同步、读写分别的打算优化读性能。
上方再联合我的团体阅历，针对高性能、高可用、高裁减3个方面，总结下可落地的通常打算。
3.2.1 高性能的通常打算
1、集群部署，经过负载平衡减轻单机压力。
2、多级缓存，包含静态数据经常使用CDN、本地缓存、散布式缓存等，以及对缓存场景中的热点key、缓存穿透、缓存并发、数据分歧性等疑问的处置。
3、分库分表和索引优化，以及借助搜查引擎处置复杂查征询题。
4、思考NoSQL数据库的经常使用，比如Hbase、TiDB等，然而团队必需相熟这些组件，且有较强的运维才干。
5、异步化，将无所谓流程经过多线程、MQ、甚至延时义务启动异步处置。
6、限流，须要先思考业务能否准许限流（比如秒杀场景是准许的），包含前端限流、Nginx接入层的限流、服务端的限流。
7、对流量启动 削峰填谷 ，经过 MQ承接流量。
8、并发处置，经过多线程将串行逻辑并行化。
9、估量算，比如抢红包场景，可以提早计算好红包金额缓存起来，发红包时直接经常使用即可。
10、 缓存预热 ，经过异步 义务 提早 预热数据到本地缓存或许散布式缓存中。
11、缩小IO次数，比如数据库缓和存的批量读写、RPC的批量接口支持、或许经过冗余数据的形式干掉RPC调用。
12、缩小IO时的数据包大小，包含驳回轻量级的通讯协定、适合的数据结构、去掉接口中的多余字段、缩小缓存key的大小、紧缩缓存value等。
13、程序逻辑优化，比如将大略率阻断口头流程的判别逻辑前置、For循环的计算逻辑优化，或许驳回更高效的算法。
14、各种池化技术的经常使用和池大小的设置，包含HTTP恳求池、线程池（思考CPU密集型还是IO密集型设置外围参数）、数据库和Redis衔接池等。
15、JVM优化，包含重生代和老年代的大小、GC算法的选用等，尽或许缩小GC频率和耗时。
16、锁选用，读多写少的场景用失望锁，或许思考经过火段锁的形式缩小锁抵触。
上述打算无外乎从计算和 IO 两个维度思考一切或许的优化点，须要有配套的监控系统实时了解以后的性能表现，并撑持你启动性能瓶颈剖析，而后再遵照二八准则，抓关键矛盾启动优化。
3.2.2 高可用的通常打算
1、平等节点的缺点转移，Nginx和服务控制框架均支持一个节点失败后访问另一个节点。
2、非平等节点的缺点转移，经过心跳检测并实施主备切换（比如redis的哨兵形式或许集群形式、MySQL的主从切换等）。
3、接口层面的超时设置、重试战略和幂等设计。
4、升级处置：保证外围服务，就义非外围服务，必要时启动熔断；或许外围链路出疑问时，有备选链路。
5、限流处置：对超越系统处置才干的恳求直接拒绝或许前往失误码。
6、MQ场景的信息牢靠性保证，包含producer端的重试机制、broker侧的耐久化、consumer端的ack机制等。
7、灰度颁布，能支持按机器维度启动小流量部署，观察系统日志和业务目的，等运转颠簸后再推全量。
8、监控报警：全方位的监控体系，包含最基础的CPU、内存、磁盘、网络的监控，以及Web主机、JVM、数据库、各类两边件的监控和业务目的的监控。
9、灾备演练：相似以后的“混沌工程”，对系统启动一些破坏性手腕，观察部分缺点能否会惹起可用性疑问。
高可用的打算关键从冗余、取舍、系统运维3个方向思考，同时须要有配套的值班机制和缺点处置流程，当出现线上疑问时，可及时跟进处置。
3.2.3 高裁减的通常打算
1、正当的分层架构：比如上方谈到的互联网最经常出现的分层架构，另外还能进一步依照数据访问层、业务逻辑层对微服务做更细粒度的分层（然而须要评价性能，会存在网络多一跳的状况）。
2、存储层的拆分：依照业务维度做垂直拆分、依照数据特色维度进一步做水平拆分（分库分表）。
3、业务层的拆分：最经常出现的是依照业务维度拆（比如电商场景的商品服务、订单服务等），也可以依照外围接口和非外围接口拆，还可以依照恳求源拆（比如To C和To B，APP和H5 ）。
高并发确实是一个复杂且系统性的疑问，由于篇幅有限，诸如散布式Trace、全链路压测、柔性事务都是要思考的技术点。
另外，假设业务场景不同，高并发的落中央案也会存在差异，然而总体的设计思绪和可自创的打算基本相似。
高并发设计雷同要秉承架构设计的3个准则：便捷、适合和演进。
过早的优化是万恶之源，不能脱离业务的实践状况，更不要适度设计，适合的打算就是最完美的。
作者简介：985硕士，前亚马逊工程师，现大厂技术控制者。
超详细的Guava RateLimiter限流原了解析
限流是确保高并发系统稳固性的三大工具之一，其他两个为缓存和升级。
限流常运行于多个场景，如秒杀抢购，以包全系统和下游系统免受渺小流量的冲击。
限流的目的在于经过限速处置并发访问或恳求，以包全系统。
当到达限度速率时，系统可以拒绝服务或启动流量整形。
经常出现的限流方法和场景包含：限度总并发数（如数据库衔接池、线程池）、限度刹时并发数（如nginx的limitconn模块，Java的Semaphore）、限度时期窗口内的平均速率（如Guava的RateLimiter、nginx的limitreq模块）。
此外，还可以依据网络衔接数、网络流量、CPU或内存负载等来限流。
例如，若要限度方法被调用的并发数不超越100（同一时期并发数），可以经常使用信号量Semaphore成功。
但若要限度方法在一段时期内平均被调用次数不超越100，则须要经常使用RateLimiter。
接上去，我们来解说两个与限流关系的算法：漏桶算法和令牌桶算法。
漏桶算法相似于一个漏斗，出去的水量代表访问流量，出去的水量代表系统处置恳求。
当访问流量过大时，漏斗中会积水，若水太多，则会溢出。
漏桶算法通常依赖于队列，恳求抵达时，假设队列未满则直接放入队列，而后有一个处置器依照固定频率从队列头取出恳求启动处置。
假设恳求量大，队列会满，新来的恳求则会被放弃。
令牌桶算规律是一个寄存固定容量令牌的桶，依照固定速率向桶里参与令牌。
桶中寄存的令牌数有最大下限，超出后会被放弃或拒绝。
当流量或网络恳求抵达时，每个恳求都要失掉一个令牌，假设失掉到，则直接处置，并删除一个令牌。
假设失掉不到，该恳求会被限流，要么直接放弃，要么在缓冲区期待。
Guava的RateLimiter提供了令牌桶算法成功，包含平滑突发限流（SmoothBursty）敌对滑预热限流（SmoothWarmingUp）。
RateLimiter的类图展现了RateLimiter是入口类，提供了两套工厂方法来创立出两个子类，这合乎《Effective Java》中用静态工厂方法替代结构函数的倡导。
经常使用RateLimiter的静态方法创立一个限流器，设置每秒搁置的令牌数为5个。
前往的RateLimiter对象可以保证1秒内不会给超越5个令牌，并以固定速率启动搁置，到达平滑输入的成果。
RateLimiter经常使用令牌桶算法，会启动令牌的累积。
假设失掉令牌的频率较低，则不会造成期待，直接失掉令牌。
RateLimiter可以应答突发流量。
在没有足够令牌发放时，驳回滞后处置的形式，即前一个恳求失掉令牌所需期待的时期由下一次性恳求来接受。
RateLimiter的SmoothWarmingUp是带有预热期的平滑限流，它会启动后有一段预热期，逐渐将散发频率优化到性能的速率。
RateLimiter的原理是每次调用acquire时用以后时期和nextFreeTicketMicros启动比拟，依据二者的距离和参与单位令牌的时时期隔stableIntervalMicros来刷新存储令牌数storedPermits。
而后acquire会启动休眠，直到nextFreeTicketMicros。
RateLimiter的reserveEarliestAvailable是刷新令牌数和下次失掉令牌时期nextFreeTicketMicros的关键函数。
它有三个步骤：一是调用resync函数参与令牌数，二是计算预支付令牌所需额外期待的时期，三是更新下次失掉令牌时期nextFreeTicketMicros和存储令牌数storedPermits。
RateLimiter的SmoothWarmingUp成功预热缓冲的关键在于其散发令牌的速率会随时期和令牌数而扭转，速率会先慢后快。
RateLimiter只能用于单机的限流，假构想要集群限流，则须要引入redis或阿里开源的sentinel两边件。
