⾼并发⾼可⽤⾼性能的解决⽅案汇总整理
捕鼠笼难题与⽅案
⾯临难题：对于每天上亿流量，拥有上亿页⾯的⼤型电商⽹站来说，能够⽀撑⾼并发访问，同时能够秒级让最新模板⽣效的商品详情页系统的架构是如何设计的?
解决⽅案：异步多级缓存架构+nginx本地化缓存+动态模板渲染的架构 2、redis企业级集架构
⾯临难题：如何让redis集⽀撑⼏⼗万QPS⾼并发+99.99%⾼可⽤+TB级海量数据+企业级数据备份与恢复?
解决⽅案：redis的企业级备份恢复⽅案+复制架构+读写分离+哨兵架构+redis cluster集部署
3、多级缓存架构设计
⾯临难题：如何将缓存架构设计的能够⽀撑⾼性能以及⾼并发到极致?同时还要给缓存架构最后的⼀个安
全保护层?
解决⽅案：nginx抗热点数据+redis抗⼤规模离线请求+ehcache抗redis崩溃的三级缓存架构
4、数据库+缓存双写⼀致性解决⽅案
⾯临难题：⾼并发场景下，如何解决数据库与缓存双写的时候数据不⼀致的情况?
解决⽅案：异步队列串⾏化的数据库+缓存双写⼀致性解决⽅案
5、缓存维度化拆分解决⽅案
⾯临难题：如何解决⼤value缓存的全量更新效率低下问题?
解决⽅案：商品缓存数据的维度化拆分解决⽅案
6、缓存命中率提升解决⽅案
⾯临难题：如何将缓存命中率提升到极致?
解决⽅案：双层nginx部署架构+lua脚本实现⼀致性hash流量分发策略
7、缓存并发重建冲突解决⽅案
⾯临难题：如何解决⾼并发场景下，缓存重建时的分布式并发重建的冲突问题?
解决⽅案：基于zookeeper分布式锁的缓存并发重建冲突解决⽅案
8、缓存预热解决⽅案
⾯临难题：如何解决⾼并发场景下，缓存冷启动导致MySQL负载过⾼，甚⾄瞬间被打死的问题?
解决⽅案：基于storm实时统计热数据的分布式快速缓存预热解决⽅案
⾯临难题：如何解决热点缓存导致单机器负载瞬间超⾼?
解决⽅案：基于storm的实时热点发现+毫秒级的实时热点缓存负载均衡降级
10、⾼可⽤分布式系统架构设计
⾯临难题：如何解决分布式系统中的服务⾼可⽤问题?避免多层服务依赖因为少量故障导致系统崩溃?
测量温度表
解决⽅案：基于hystrix的⾼可⽤缓存服务，资源隔离+限流+降级+熔断+超时控制
11、复杂的⾼可⽤分布式系统架构设计
⾯临难题：如何针对复杂的分布式系统将其中的服务设计为⾼可⽤架构?
解决⽅案：基于hystrix的容错+多级降级+⼿动降级+⽣产环境参数优化经验+可视化运维与监控
12、缓存雪崩解决⽅案
⾯临难题：如何解决恐怖的缓存雪崩问题?避免给公司带来巨⼤的经济损失?
解决⽅案：全⽹独家的事前+事中+事后三层次完美缓存雪崩解决⽅案
运维流程管理13、缓存穿透解决⽅案
⾯临难题：如何解决⾼并发场景下的缓存穿透问题?避免给MySQL带来过⼤的压⼒?大功率控制器
解决⽅案：缓存穿透解决⽅案
14、缓存失效解决⽅案
⾯临难题：如何解决⾼并发场景下的缓存失效问题?避免给redis集带来过⼤的压⼒?
解决⽅案：基于随机过期时间的缓存失效解决⽅案
具体措施
1、HTML静态化
其实⼤家都知道，效率最⾼、消耗最⼩的就是纯静态化的html页⾯，所以我们尽可能使我们的⽹站上的页⾯采⽤静态页⾯来实现，这个最简单的⽅法其实也是最有效的⽅法。但是对于⼤量内容并且频繁更新的⽹站，我们⽆法全部⼿动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚⾄他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录⼊⾃动⽣成静态页⾯，还能具备频道管理、权限管理、⾃动抓取等功能，对于⼀个⼤型⽹站来说，拥有⼀套⾼效、可管理的CMS是必不可少的。挤压件
除了门户和信息发布类型的⽹站，对于交互性要求很⾼的社区类型⽹站来说，尽可能的静态化也是提⾼性能的必要⼿段，将社区内的帖⼦、⽂章进⾏实时的静态化、有更新的时候再重新静态化也是⼤量使⽤的策略，像Mop的⼤杂烩就是使⽤了这样的策略，⽹易社区等也是如此。
同时，html静态化也是某些缓存策略使⽤的⼿段，对于系统中频繁使⽤数据库查询但是内容更新很⼩
的应⽤，可以考虑使⽤html静态化来实现。⽐如论坛中论坛的公⽤设置信息，这些信息⽬前的主流论坛都可以进⾏后台管理并且存储在数据库中，这些信息其实⼤量被前台程序调⽤，但是更新频率很⼩，可以考虑将这部分内容进⾏后台更新的时候进⾏静态化，这样避免了⼤量的数据库访问请求。
2、图⽚服务器分离
⼤家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图⽚是最消耗资源的，于是我们有必要将图⽚与页⾯进⾏分离，这是基本上⼤型⽹站都会采⽤的策略，他们都有独⽴的、甚⾄很多台的图⽚服务器。这样的架构可以降低提供页⾯访问请求的服务器系统压⼒，并且可以保证系统不会因为图⽚问题⽽崩溃。
在应⽤服务器和图⽚服务器上，可以进⾏不同的配置优化，⽐如apache在配置ContentType的时候可以尽量少⽀持、尽可能少的LoadModule，保证更⾼的系统消耗和执⾏效率。
电阻加热炉
3、数据库集、库表散列
⼤型⽹站都有复杂的应⽤，这些应⽤必须使⽤数据库，那么在⾯对⼤量访问的时候，数据库的瓶颈很快就能显现出来，这时⼀台数据库将很快⽆法满⾜应⽤，于是我们需要使⽤数据库集或者库表散列。
在数据库集⽅⾯，很多数据库都有⾃⼰的解决⽅案，Oracle、Sybase等都有很好的⽅案，常⽤的MySQL提供的Master/Slave也是类似的⽅案，您使⽤了什么样的DB，就参考相应的解决⽅案来实施即可。
上⾯提到的数据库集由于在架构、成本、扩张性⽅⾯都会受到所采⽤DB类型的限制，于是我们需要从应⽤程序的⾓度来考虑改善系统架构，库表散列是常⽤并且最有效的解决⽅案。
我们在应⽤程序中安装业务和应⽤或者功能模块将数据库进⾏分离，不同的模块对应不同的数据库或者表，再按照⼀定的策略对某个页⾯或者功能进⾏更⼩的数据库散列，⽐如⽤户表，按照⽤户ID进⾏表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。
sohu的论坛就是采⽤了这样的架构，将论坛的⽤户、设置、帖⼦等信息进⾏数据库分离，然后对帖⼦、⽤户按照板块和ID进⾏散列数据库和表，最终可以在配置⽂件中进⾏简单的配置便能让系统随时增加⼀台低成本的数据库进来补充系统性能。
4、缓存
缓存⼀词搞技术的都接触过，很多地⽅⽤到缓存。⽹站架构和⽹站开发中的缓存也是⾮常重要。这⾥先讲述最基本的两种缓存。⾼级和分布式的缓存在后⾯讲述。
架构⽅⾯的缓存，对Apache⽐较熟悉的⼈都能知道Apache提供了⾃⼰的缓存模块，也可以使⽤外加的Squid模块进⾏缓存，这两种⽅式均可以有效的提⾼Apache的访问响应能⼒。
⽹站程序开发⽅⾯的缓存，Linux上提供的Memory Cache是常⽤的缓存接⼝，可以在web开发中使⽤，⽐如⽤Java开发的时候就可以调⽤MemoryCache对⼀些数据进⾏缓存和通讯共享，⼀些⼤型社区使⽤了这样的架构。另外，在使⽤web语⾔开发的时候，各种语⾔基本都有⾃⼰的缓存模块和⽅法，PHP有Pear的Cache模块，Java就更多了，不是很熟悉，相信也肯定有。
5、镜像
镜像是⼤型⽹站常采⽤的提⾼性能和数据安全性的⽅式，镜像的技术可以解决不同⽹络接⼊商和地域带来的⽤户访问速度差异，⽐如ChinaNet和EduNet之间的差异就促使了很多⽹站在教育⽹内搭建镜像站点，数据进⾏定时更新或者实时更新。在镜像的细节技术⽅⾯，这⾥不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，⽐如Linux上的rsync等⼯具。
6、负载均衡
负载均衡将是⼤型⽹站解决⾼负荷访问和⼤量并发请求采⽤的⾼端解决办法。
负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个⼈接触过⼀些解决⽅法，
其中有两个架构可以给⼤家做参考。
（1）、硬件四层交换
第四层交换使⽤第三层和第四层信息包的报头信息，根据应⽤区间识别业务流，将整个区间段的业务流分配到合适的应⽤服务器进⾏处理。
第四层交换功能就像是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端⼝地址来决定，在第四层交换中的应⽤区间则由源端和终端IP地址、TCP和UDP端⼝共同决定。
在硬件四层交换产品领域，有⼀些知名的产品可以选择，⽐如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供⾮常优秀的性能和很灵活的管理能⼒。“Yahoo中国”当初接近2000台服务器，只使⽤了三、四台Alteon就搞定了。
(2)、软件四层交换
⼤家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运⽽⽣，这样的解决⽅案实现的原理⼀致，不过性能稍差。但是满⾜⼀定量的压⼒还是游刃有余的，有⼈说软件实现⽅
式其实更灵活，处理能⼒完全看你配置的熟悉能⼒。
软件四层交换我们可以使⽤Linux上常⽤的LVS来解决，LVS就是Linux Virtual Server，他提供了基于⼼跳线heartbeat的实时灾难应对解决⽅案，提⾼系统的强壮性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满⾜多种应⽤需求，这对于分布式的系统来说必不可少。
⼀个典型的使⽤负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集，这种思路在很多⼤型⽹站包括搜索引擎上被采⽤，这样的架构低成本、⾼性能还有很强的扩张性，随时往架构⾥⾯增减节点都⾮常容易。
对于⼤型⽹站来说，前⾯提到的每个⽅法可能都会被同时使⽤到，这⾥介绍得⽐较浅显，具体实现过程中很多细节还需要⼤家慢慢熟悉和体会。有时⼀个很⼩的squid参数或者apache参数设置，对于系统性能的影响就会很⼤。
7、最新：CDN加速技术
什么是CDN？
CDN的全称是内容分发⽹络。其⽬的是通过在现有的Internet中增加⼀层新的⽹络架构，将⽹站的内容发布到最接近⽤户的⽹络“边缘”，使⽤户可以就近取得所需的内容，提⾼⽤户访问⽹站的响应速度。
CDN有别于镜像，因为它⽐镜像更智能，或者可以做这样⼀个⽐喻：CDN=更智能的镜像+缓存+流量导流。因⽽，CDN可以明显提⾼Internet⽹络中信息流动的效率。从技术上全⾯解决由于⽹络带宽⼩、⽤户访问量⼤、⽹点分布不均等问题，提⾼⽤户访问⽹站的响应速度。
CDN的类型特点
CDN的实现分为三类：镜像、⾼速缓存、专线。
镜像站点（Mirror Site），是最常见的，它让内容直接发布，适⽤于静态和准动态的数据同步。但是购买和维护新服务器的费⽤较⾼，还必须在各个地区设置镜像服务器，配备专业技术⼈员进⾏管理与维护。对于⼤型⽹站来说，更新所⽤的带宽成本也⼤⼤提⾼了。
⾼速缓存，成本较低，适⽤于静态内容。Internet的统计表明，超过80%的⽤户经常访问的是20%的⽹站的内容，在这个规律下，缓存服务器可以处理⼤部分客户的静态请求，⽽原始的服务器只需处理约20%左右的⾮缓存请求和动态请求，于是⼤⼤加快了客户请求的响应时间，并降低了原始服务器的负载。
CDN服务⼀般会在全国范围内的关键节点上放置缓存服务器。
专线，让⽤户直接访问数据源，可以实现数据的动态同步。
CDN的实例
举个例⼦来说，当某⽤户访问⽹站时，⽹站会利⽤全球负载均衡技术，将⽤户的访问指向到距离⽤户最近的正常⼯作的缓存服务器上，直接响应⽤户的请求。
当⽤户访问已经使⽤了CDN服务的⽹站时，其解析过程与传统解析⽅式的最⼤区别就在于⽹站的授权域名服务器不是以传统的轮询⽅式来响应本地DNS的解析请求，⽽是充分考虑⽤户发起请求的地点和当时⽹络的情况，来决定把⽤户的请求定向到离⽤户最近同时负载相对较轻的节点缓存服务器上。
通过⽤户定位算法和服务器健康检测算法综合后的数据，可以将⽤户的请求就近定向到分布在⽹络“边缘”的缓存服务器上，保证⽤户的访问能得到更及时可靠的响应。
由于⼤量的⽤户访问都由分布在⽹络边缘的CDN节点缓存服务器直接响应了，这就不仅提⾼了⽤户的访问质量，同时有效地降低了源服务器的负载压⼒。
附：某CDN服务商的服务说明
采⽤GCDN加速⽅式
采⽤了GCDN加速⽅式以后，系统会在浏览⽤户和您的服务器之间增加⼀台GCDN服务器。浏览⽤户
访问您的服务器时，⼀般静态数据，如图⽚、多媒体资料等数据将直接从GCDN服务器读取，使得从主服务器上读取静态数据的交换量⼤⼤减少。
为VIP型虚拟主机⽽特加的VPN⾼速压缩通道，使⽤⾼速压缩的电信<>⽹通、电信<>国际（HK）、⽹通<==>国际（HK）等跨⽹专线通道，智能多线，⾃动获取最快路径，极速的动态实时并发响应速度，实现了⽹站的动态脚本实时同步，对动态⽹站有⼀个更加明显的加速效果。
每个⽹络运营商（电信、⽹通、铁通、教育⽹）均有您服务器的GCDN服务器，⽆论浏览⽤户是来⾃何处，GCDN都能让您的服务器展现最快的速度！另外，我们将对您的数据进⾏实时备份，让您的数据更安全！
8、降级
降级的最终⽬的是保证核⼼服务可⽤，即使是有损的。⽽且有些服务是⽆法降级的（如加⼊购物车、结算）。
降级预案
在进⾏降级之前要对系统进⾏梳理，看看系统是不是可以丢卒保帅；从⽽梳理出哪些必须誓死保护，哪些可降级；⽐如可以参考⽇志级别设置预案：
⼀般：⽐如有些服务偶尔因为⽹络抖动或者服务正在上线⽽超时，可以⾃动降级；
警告：有些服务在⼀段时间内成功率有波动（如在95~100%之间），可以⾃动降级或⼈⼯降级，并发送告警；
错误：⽐如可⽤率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最⼤阀值，此时可以根据情况⾃动降级或者⼈⼯降级；
严重错误：⽐如因为特殊原因数据错误了，此时需要紧急⼈⼯降级。
降级按照是否⾃动化可分为：⾃动开关降级和⼈⼯开关降级。
降级按照功能可分为：读服务降级、写服务降级。
降级按照处于的系统层次可分为：多级降级。
降级的功能点主要从服务端链路考虑，即根据⽤户访问的服务调⽤链路来梳理哪⾥需要降级：
页⾯降级、页⾯⽚段降级、页⾯异步请求降级、服务功能降级、读降级、写降级
⾃动开关降级：超时降级、统计失败次数降级、故障降级、限流降级
⼈⼯开关降级：读服务降级、写服务降级
9、分层
分层是企业应⽤系统中最常见的⼀种架构模式，将系统在横向维度上切分成⼏个部分，每个部分负责⼀部分相对简单并⽐较单⼀的职责，然后通过上层对下层的依赖和调度组成⼀个完整的系统。
在⽹站的分层架构中，常见的为3层，即应⽤层、服务层、数据层。应⽤层具体负责业务和视图的展⽰；服务层为应⽤层提供服务⽀持；数据库提供数据存储访问服务，如数据库、缓存、⽂件、搜索引擎等。
分层架构是逻辑上的，在物理部署上，三层架构可以部署在同⼀个物理机器上，但是随着⽹站业务的发展，必然需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，是⽹站拥有更多的计算资源以应对越来越多的⽤户访问。
所以虽然分层架构模式最初的⽬的是规划软件清晰的逻辑结构以便于开发维护，但在⽹站的发展过程中，分层结构对⽹站⽀持⾼并发向分布式⽅向的发展⾄关重要。
10、限流
在开发⾼并发系统时有三把利器⽤来保护系统：缓存、降级和限流。缓存的⽬的是提升系统访问速度和增⼤系统能处理的容量，可谓是抗⾼并发流量的银弹；⽽降级是当服务出问题或者影响到核⼼流程的性能则需要暂时屏蔽掉，待⾼峰或者问题解决后再打开；⽽有些场景并不能⽤缓存和降级来解决，⽐如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后⼏页），因此需有⼀种⼿段来限制这些场景的并发/请求量，即限流。
限流的⽬的是通过对并发访问/请求进⾏限速或者⼀个时间窗⼝内的的请求进⾏限速来保护系统，⼀旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（⽐如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。
⼀般开发⾼并发系统常见的限流有：限制总并发数（⽐如数据库连接池、线程池）、限制瞬时并发数（如nginx的limit_conn模块，⽤来限制瞬时并发连接数）、限制时间窗⼝内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）；其他还有如限制远程接⼝调⽤速率、限制MQ的消费速率。另外还可以根据⽹络连接数、⽹络流量、CPU或内存负载等来限流。
11、隔离
线程隔离：
线程隔离主要是指线程池隔离，在实际使⽤时，我们会把请求分类，然后交给不同的线程池处理。当⼀种业务的请求处理发⽣问题时，不会将故障扩散到其他线程池，从⽽保证其他服务可⽤。
进程隔离
由于传统的系统所有功能都集中在⼀个系统中，为了避免系统其中⼀个模块功能出现问题导致整个系统⽆法使⽤的情况发⽣，将其该系统拆分成多⼦系统实现物理隔离，故通过进程隔离使得某⼀个⼦系统出现问题时不影响到其他⼦系统。
集隔离
随着调⽤⽅的增多，当秒杀（并发量特别⼤功能）类似的服务被刷新会影响到其他服务的稳定性时，应该考虑为秒杀（并发量特别⼤功能）类似的服务提供单独的服务集，即分服务分组，这样当某⼀个分组出现问题时，不会影响到其他分组，从⽽实现了故障隔离愿景。
机房隔离
随着对系统可⽤性的要求，会进⾏多机房部署，每⼀个机房的服务都有⾃⼰的服务分组，本机房的服务应该只调⽤本机房的服务，不进⾏跨机房调⽤。其中，⼀个机房服务发⽣问题时，可以通过DNS/负载均衡将请求全部切到另⼀个机房，或者考虑服务能⾃动重试其他机房的服务，从⽽提升系统可⽤性。
读写隔离
为了提⾼数据访问，⼀般采⽤redis主从模式将读和写进分离，在正常情况下，当主redis集出现问题时，从redis集还是可以⽤的，从⽽不影响⽤户的访问。
动静隔离
例如当⽤户访问如结算页时，如果JS/CSS等静态资源也在结算页系统中时，很可能因为访问量太⼤导致带宽被打满导致出现不可⽤。
为了不影响结算等⽤户操作的功能，将其JS/CSS等静态资源静态化与⽤户操作功能分开部署。
资源隔离
最常见的资源如磁盘、CPU、⽹络；对于宝贵的资源都会存在竞争问题。
我们可以使⽤JIMDB数据同步时要dump数据，SSD盘容量⽤了50%以上，dump到同⼀块磁盘时遇到了容量不⾜的问题，我们通过单独挂⼀块SAS盘来专门同步数据。还有如使⽤Docker容器时，有的容器写磁盘⾮常频繁，因此要考虑为不同的容器挂载不同的磁盘。
12、超时重试
在实际开发过程中，我们见过太多故障时因为没有设置超时或者设置得不对⽽造成的，⽽这些故障都是因为没有意识到超时设置的重要性⽽造成的。如果应⽤不设置超时，则可能会导致请求响应慢，慢请求积累导致连锁反应，甚⾄造成应⽤雪塌。⽽有些中间件或者框架在超时后进⾏重试（例如dubbo默认重试两次），读服务天然适合重试，但写服务⼤多不能重试（如写订单、⽀付等），重试次数太多会导致多倍请求流量。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议