相信每一位开发同学多多少少都想参与或负责一个高用户、高访问、高并发的系统吧。一来可以增加自己实际的项目经验，有应对高并发场景的解决方案，二来是有个高并发的项目经验无疑是自己简历的一个大大的加分项。
但是奈何很多人都没有机会可以参与这样的项目，本文从以下几点介绍一下设计一个高流量高并发的系统需要经历哪些步骤以及考虑哪些因素(文章中的不足之处还请大佬们多多指点)。
在设计一个系统之前，我们先要有一个统一且清晰的认知：不要想着一下就能设计出完美的系统，好的系统是迭代出来的。不要复杂化，要先解决核心问题。但是要有先行的规划，对现有的问题有方案，对未来系统有预案。
在设计高并发的系统时要遵循以下几个原则：
什么是无状态?服务器不保存状态，对单次请求的处理不依赖别的请求就是无状态，主要是为了在应对高并发时方便水平扩展。
在我们的系统体积过于庞大或者承载不了大量的请求时，就要考虑拆分系统，将复杂问题简单化或将流量分散不同子系统分担压力。可以按照以下几个维度进行拆分：
当我们的系统被拆分的足够大时，一旦发生故障靠人工来处理是非常耗时耗力。这个时候就可以通过注册发现、限流、熔断、降级等方案让每个服务可以自己处理问题来帮助我们减少排障成本。
在进行业务设计时要遵循一些最基本的原则比如：
在某些场景下要防止用户重复操作，例如：用户注册、用户下单、用户支付等。我们需要在客户端和服务端有一些方案避免这种问题。
在业务中每个功能多多少少是有联系的，在设计的时候模块尽量要独立，其他模块直接调用即可，调用减少代码的冗余。
在程序的运行中避免不了业务问题以及故障的发生，但是我们可以通过日志的方式快速定位问题，做到有据可查。
系统对用户的响应应该是具体、详细的，举一个很简单的例子，用户登录失败后应该反馈给用户的是“用户名错误”或者“密码错误”，而不是“登录失败”。
做好代码备份、数据备份以及人员备份。
在高并发高流量的系统客户端的优化是必不可少的，如果没有做好客户端的优化影响用户体验是一方面，有时候甚至是致命的。
这里分享下我之前惨痛的教训：之前参与过一个秒杀的业务，就是因为前端的没有做优化，大量用户在刷新页面时服务器的带宽被打爆，页面加载不出来，影响了系统的发展，这是非常致命的。主要原因还是没有经验，以为后端做好高并发抵抗就可以。
客户端优化主要集中以下几点：
常见的资源缓存就是图片、样式和脚本。有些场景可以利用客户端的缓存帮助服务端分担压力，比如网约车中的预估价格，客户端可以缓存计算规则并缓存，减少向服务端的请求。
我们知道页面中资源解析的顺序是从上到下，如果上面有改变下面也需要变动，所以我们要缩小回流、重绘的范围，比如虚拟dom。除此之外我们还可以利用懒加载和预加载进行优化：
<meta http-equiv="x-dns-prefetch-control" content="on"><link rel='dns-prefetch" href="www.baidu.com" ><link rel='preload" href="..js" ><link rel='prefetch" href="..js" >CDN应用在客户端——>服务端之前，能够实时的根据网络流量和各节点的连接、负载情况以及到用户的距离和响应时间等综合信息将用户的请求导向离用户最近的服务节点上，使用户可以就近取得所需内容，解决网络拥挤的状况，提高用户访问网站的响应速度和成功率。我们可以通过CDN服务商购买CDN服务，绑定我们的域名，其他的事就不用我们管了。
借用一张网络上的图片帮助理解下
通常高并发系统都存在集群节点，为了抵抗大量的请求，也为了系统的高可用。根据业务场景利用负载策略将一个请求分发到集群中的某个计算节点。通过Nginx、LVS、Keepalived等集群组件可以轻松的实现这一功能。
依然是借用一张网络上的图片
缓存的介入其实就是空间换时间，常见的缓存组件redis、memcache、guava都可以起到减少响应时间的作用，在高并发的项目中经常被使用到，适合读多写少、耗时长的查询场景。但是会带来开发人员学习、写代码、部署机器、维护的成本。在设计key时要有以下几点认知：
否则使用缓存的收益是非常低甚至没有必要的。
当然，缓存技术的引入也是可能会带来一些列缓存问题，比如缓存击穿、缓存穿透、缓存雪崩等，依然需要代码层面去解决，在使用时需要注意这些问题。
我们知道所有的业务数据最终都会落到数据库，随着数据量的增加会带来响应时间的增加，以及系统的负载不断上升，数据库单点压力会越来越大，这个时候对数据库的优化就不单仅是冗余、反范式、索引，可以根据业务场景参考以下方案：
在mysql中一张表的数据对应一个ibd文件，当文件过大时查找数据就会变的很慢。表分区是将一张表按照hash、list、key等规则进行分流，在物理上将这一张表ibd文件分成多个文件，但是逻辑上还是一张表。访问量不大，但是表数据很多的表，可以采用这种方式，这样的好处就是查询的数据在一个分区时会很快的查到。
分库分表是真正的把一张表分布在不同的库或多张表，在访问量大的时候可以把一张表分多张表并且分布在不同的库减少单个数据库的压力，提高并发。或者按照业务划分进行分库分表达到数据隔离的作用。但是这种方式往往会带来分布式id、事务、join查询等一系列问题，我们只能通过代码层面来解决，无疑增加了复杂度。
在读多写少的场景下我们可以利用shardingjdbc、mycat等开源框架或组件路由到写库或者读库实现读写分离。同样读写分离也存在一定的问题，比如主从复制问题、时间差问题等，可以结合业务场景规避。
在高并发的项目中，往往我们的后端服务是很庞大的，因为服务拆分所引发的如：服务调用、服务雪崩、节点故障问题，以及处理高并发请求的问题。如何解决这些问题，让服务更稳定地运行，我们管它叫作服务治理。通常有以下几种方案：
做好一个高流量高并发的系统，不论前端还是后端，过程中每一个步骤都是至关重要的。设计一个系统除了满足功能性，还要考虑兼容性、易用性、可靠性、安全性、可维护性、可移植性等软件质量。同时要对系统的吞吐量、并发数、平均响应时间等指标要完全掌握，在指标异常时可以快速做出决策避免一系列问题发生。
本文链接：http://www.28at.com/showinfo-26-20043-0.html一个高流量高并发系统，设计关注点有哪些
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： Gorm 中的钩子和回调
下一篇： 系统架构七个非功能性需求
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
