wordpress电商网站,网站目录,如何建立一个网站分享教程,做网站建设的上市公司有哪些目录01 如何理解高并发#xff1f;02 高并发系统设计的目标是什么#xff1f;2.1标题宏观目标高并发绝不意味着只追求高性能#xff0c;这是很多人片面的理解。2.2 微观目标2.2.1 性能指标2.2.2 可用性指标2.2.3 可扩展性指标03 高并发的实践方案有哪些#xff1f;3.1 通用…
目录01 如何理解高并发02 高并发系统设计的目标是什么2.1标题宏观目标高并发绝不意味着只追求高性能这是很多人片面的理解。2.2 微观目标2.2.1 性能指标2.2.2 可用性指标2.2.3 可扩展性指标03 高并发的实践方案有哪些3.1 通用的设计方法3.1.1 纵向扩展scale-up3.1.2 横向扩展scale-out3.2 具体的实践方案3.2.1 高性能的实践方案3.2.2 高可用的实践方案3.2.3 高扩展的实践方案总结首先说一下当我作为面试官问候选人「对于高并发的理解」时我觉得「答得不好」的情况分成以下几类
对数据化的指标没有概念不清楚选择什么样的指标来衡量高并发系统分不清并发量和QPS不知道自己系统的总用户量、活跃用户量平峰和高峰时的QPS和TPS等关键数据。设计过一些高并发方案但是细节掌握不透彻讲不出该方案要关注的技术点和可能带来的副作用。比如读性能有瓶颈会引入缓存但是忽视了缓存命中率、热点key、数据一致性等问题。理解片面把高并发设计等同于性能优化大谈并发编程、多级缓存、异步化、水平扩容却忽视高可用设计、服务治理和运维保障。掌握大方案却忽视最基本的东西能讲清楚垂直分层、水平分区、缓存等大思路却没意识去分析数据结构是否合理算法是否高效没想过从最根本的IO和计算两个维度去做细节优化。
下面我再结合我的高并发项目经验系统性地总结下高并发需要掌握的知识和实践思路内容分成以下3个部分
如何理解高并发高并发系统设计的目标是什么高并发的实践方案有哪些
01 如何理解高并发
高并发意味着大流量需要运用技术手段抵抗流量的冲击这些手段好比操作流量能让流量更平稳地被系统所处理带给用户更好的体验。我们常见的高并发场景有淘宝的双11、春运时的抢票、微博大V的热点新闻等。除了这些典型事情每秒几十万请求的秒杀系统、每天千万级的订单系统、每天亿级日活的信息流系统等都可以归为高并发。很显然上面谈到的高并发场景并发量各不相同那到底多大并发才算高并发呢
不能只看数字要看具体的业务场景。不能说10W QPS的秒杀是高并发而1W QPS的信息流就不是高并发。信息流场景涉及复杂的推荐模型和各种人工策略它的业务逻辑可能比秒杀场景复杂10倍不止。因此不在同一个维度没有任何比较意义。业务都是从0到1做起来的并发量和QPS只是参考指标最重要的是在业务量逐渐变成原来的10倍、100倍的过程中你是否用到了高并发的处理方法去演进你的系统从架构设计、编码实现、甚至产品方案等维度去预防和解决高并发引起的问题而不是一味的升级硬件、加机器做水平扩展。
此外各个高并发场景的业务特点完全不同有读多写少的信息流场景、有读多写多的交易场景那是否有通用的技术方案解决不同场景的高并发问题呢我觉得大的思路可以借鉴别人的方案也可以参考但是真正落地过程中细节上还会有无数的坑。另外由于软硬件环境、技术栈、以及产品逻辑都没法做到完全一致这些都会导致同样的业务场景就算用相同的技术方案也会面临不同的问题这些坑还得一个个趟。因此这篇文章我会将重点放在基础知识、通用思路、和我曾经实践过的有效经验上希望让你对高并发有更深的理解。
02 高并发系统设计的目标是什么
先搞清楚高并发系统设计的目标在此基础上再讨论设计方案和实践经验才有意义和针对性。
2.1标题宏观目标高并发绝不意味着只追求高性能这是很多人片面的理解。
从宏观角度看高并发系统设计的目标有三个高性能、高可用以及高可扩展。
高性能性能体现了系统的并行处理能力在有限的硬件投入下提高性能意味着节省成本。同时性能也反映了用户体验响应时间分别是100毫秒和1秒给用户的感受是完全不同的。高可用表示系统可以正常服务的时间。一个全年不停机、无故障另一个隔三差五出线上事故、宕机用户肯定选择前者。另外如果系统只能做到90%可用也会大大拖累业务高扩展表示系统的扩展能力流量高峰时能否在短时间内完成扩容更平稳地承接峰值流量比如双11活动、明星离婚等热点事件。 这3个目标是需要通盘考虑的因为它们互相关联、甚至也会相互影响。比如说考虑系统的扩展能力你会将服务设计成无状态的这种集群设计保证了高扩展性其实也间接提升了系统的性能和可用性。再比如说为了保证可用性通常会对服务接口进行超时设置以防大量线程阻塞在慢请求上造成系统雪崩那超时时间设置成多少合理呢一般我们会参考依赖服务的性能表现进行设置。
2.2 微观目标
再从微观角度来看高性能、高可用和高扩展又有哪些具体的指标来衡量为什么会选择这些指标呢
2.2.1 性能指标
通过性能指标可以度量目前存在的性能问题同时作为性能优化的评估依据。一般来说会采用一段时间内的接口响应时间作为指标。
平均响应时间最常用但是缺陷很明显对于慢请求不敏感。比如1万次请求其中9900次是1ms100次是100ms则平均响应时间为1.99ms虽然平均耗时仅增加了0.99ms但是1%请求的响应时间已经增加了100倍。TP90、TP99等分位值将响应时间按照从小到大排序TP90表示排在第90分位的响应时间 分位值越大对慢请求越敏感。 吞吐量和响应时间呈反比比如响应时间是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这种有状态的存储服务通常是扩展的技术难点如果架构上没提前做好规划垂直和水平拆分就会涉及到大量数据的迁移。因此高扩展性需要考虑服务集群、数据库、缓存和消息队列等中间件、负载均衡、带宽、依赖的第三方等当并发达到某一个量级后上述每个因素都可能成为扩展的瓶颈点。
03 高并发的实践方案有哪些
了解了高并发设计的3大目标后再系统性总结下高并发的设计方案会从以下两部分展开先总结下通用的设计方法然后再围绕高性能、高可用、高扩展分别给出具体的实践方案。
3.1 通用的设计方法
通用的设计方法主要是从「纵向」和「横向」两个维度出发俗称高并发处理的两板斧纵向扩展和横向扩展。
3.1.1 纵向扩展scale-up
它的目标是提升单机的处理能力方案又包括 提升单机的硬件性能通过增加内存、 CPU核数、存储容量、或者将磁盘 升级成SSD 等堆硬 件 的 方 式 来 提升 。 提升单机的软件性能使用缓存减少IO次数使用并发或者异步的方式增加吞吐量。
3.1.2 横向扩展scale-out
因为单机性能总会存在极限所以最终还需要引入横向扩展通过集群部署以进一步提高并发处理能力又包括以下2个方向
做好分层架构这是横向扩展的提前因为高并发系统往往业务复杂通过分层处理可以简化复杂问题更容易做到横向扩展。 上面这种图是互联网最常见的分层架构当然真实的高并发系统架构会在此基础上进一步完善。比如会做动静分离并引入CDN反向代理层可以是LVSNginxWeb层可以是统一的API网关业务服务层可进一步按垂直业务做微服务化存储层可以是各种异构数据库。各层进行水平扩展无状态水平扩容有状态做分片路由。业务集群通常能设计成无状态的而数据库和缓存往往是有状态的因此需要设计分区键做好存储分片当然也可以通过主从同步、读写分离的方案提升读性能。
3.2 具体的实践方案
下面再结合我的个人经验针对高性能、高可用、高扩展3个方面总结下可落地的实践方案。
3.2.1 高性能的实践方案
集群部署通过负载均衡减轻单机压力。多级缓存包括静态数据使用CDN、本地缓存、分布式缓存等以及对缓存场景中的热点key、缓存穿透、缓存并发、数据一致性等问题的处理。分库分表和索引优化以及借助搜索引擎解决复杂查询问题。考虑NoSQL数据库的使用比如HBase、TiDB等但是团队必须熟悉这些组件且有较强的运维能力。异步化将次要流程通过多线程、MQ、甚至延时任务进行异步处理。限流需要先考虑业务是否允许限流比如秒杀场景是允许的包括前端限流、Nginx接入层的限流、服务端的限流。对流量进行 削峰填谷 通过 MQ承接流量。并发处理通过多线程将串行逻辑并行化。预计算比如抢红包场景可以提前计算好红包金额缓存起来发红包时直接使用即可。缓存预热 通过异步 任务 提前 预热数据到本地缓存或者分布式缓存中。减少IO次数比如数据库和缓存的批量读写、RPC的批量接口支持、或者通过冗余数据的方式干掉RPC调用。减少IO时的数据包大小包括采用轻量级的通信协议、合适的数据结构、去掉接口中的多余字段、减少缓存key的大小、压缩缓存value等。程序逻辑优化比如将大概率阻断执行流程的判断逻辑前置、For循环的计算逻辑优化或者采用更高效的算法。各种池化技术的使用和池大小的设置包括HTTP请求池、线程池考虑CPU密集型还是IO密集型设置核心参数、数据库和Redis连接池等。JVM优化包括新生代和老年代的大小、GC算法的选择等尽可能减少GC频率和耗时。锁选择读多写少的场景用乐观锁或者考虑通过分段锁的方式减少锁冲突。上述方案无外乎从计算和 IO 两个维度考虑所有可能的优化点需要有配套的监控系统实时了解当前的性能表现并支撑你进行性能瓶颈分析然后再遵循二八原则抓主要矛盾进行优化。
3.2.2 高可用的实践方案
对等节点的故障转移Nginx和服务治理框架均支持一个节点失败后访问另一个节点。非对等节点的故障转移通过心跳检测并实施主备切换比如redis的哨兵模式或者集群模式、MySQL的主从切换等。接口层面的超时设置、重试策略和幂等设计。降级处理保证核心服务牺牲非核心服务必要时进行熔断或者核心链路出问题时有备选链路。限流处理对超过系统处理能力的请求直接拒绝或者返回错误码。MQ场景的消息可靠性保证包括producer端的重试机制、broker侧的持久化、consumer端的ack机制等。灰度发布能支持按机器维度进行小流量部署观察系统日志和业务指标等运行平稳后再推全量。监控报警全方位的监控体系包括最基础的CPU、内存、磁盘、网络的监控以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。灾备演练类似当前的“混沌工程”对系统进行一些破坏性手段观察局部故障是否会引起可用性问题。高可用的方案主要从冗余、取舍、系统运维3个方向考虑同时需要有配套的值班机制和故障处理流程当出现线上问题时可及时跟进处理。
3.2.3 高扩展的实践方案
合理的分层架构比如上面谈到的互联网最常见的分层架构另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层但是需要评估性能会存在网络多一跳的情况。存储层的拆分按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分分库分表。业务层的拆分最常见的是按照业务维度拆比如电商场景的商品服务、订单服务等也可以按照核心接口和非核心接口拆还可以按照请求源拆比如To C和To BAPP和H5 。
总结
高并发确实是一个复杂且系统性的问题如果业务场景不同高并发的落地方案也会存在差异但是总体的设计思路和可借鉴的方案基本类似。高并发设计同样要秉承架构设计的3个原则简单、合适和演进。 过早的优化是万恶之源 不能脱离业务的实际情况更不要过度设计合适的方案就是最完美的。希望上面这些总结能让你对于高并发有更全面的认识。即使你没有高并发的项目经验如果你能参考上面的内容回答得很体系我相信也一定能给面试官眼前一亮的感觉。
要是觉得不错那就帮我 点个赞一键三连呗硬核码字不易。
授权转载自原文作者Lowry
