但是奈何很多人都没有机会可以参与这样的项目，本文从以下几点介绍一下设计一个高流量高并发的系统需要经历哪些步骤以及考虑哪些因素(文章中的不足之处还请大佬们多多指点)。
高流量高并发系统关注点
1、设计原则
1.1、系统设计原则
在设计一个系统之前，我们先要有一个统一且清晰的认知：不要想着一下就能设计出完美的系统，好的系统是迭代出来的。不要复杂化，要先解决核心问题。但是要有先行的规划，对现有的问题有方案，对未来系统有预案。
在设计高并发的系统时要遵循以下几个原则：
无状态原则
什么是无状态?服务器不保存状态，对单次请求的处理不依赖别的请求就是无状态，主要是为了在应对高并发时方便水平扩展。
拆分原则
在我们的系统体积过于庞大或者承载不了大量的请求时，就要考虑拆分系统，将复杂问题简单化或将流量分散不同子系统分担压力。可以按照以下几个维度进行拆分：
- 系统维度： 比如电商系统，我们可以拆分成商品、支付、优惠券多个子系统。
- 功能维度： 将系统按功能再次拆分。
- 读写维度： 按照读写比例将服务拆分成读服务和写服务。
- 模块维度： 将系统按照基础架构、消息队列、分库分表 、组件等模块进行拆分维护。
服务化原则
当我们的系统被拆分的足够大时，一旦发生故障靠人工来处理是非常耗时耗力。这个时候就可以通过注册发现、限流、熔断、降级等方案让每个服务可以自己处理问题来帮助我们减少排障成本。
1.2、业务设计原则
在进行业务设计时要遵循一些最基本的原则比如：
防重原则
在某些场景下要防止用户重复操作，例如：用户注册、用户下单、用户支付等。我们需要在客户端和服务端有一些方案避免这种问题。
模块复用原则
在业务中每个功能多多少少是有联系的，在设计的时候模块尽量要独立，其他模块直接调用即可，调用减少代码的冗余。
可追溯原则
在程序的运行中避免不了业务问题以及故障的发生，但是我们可以通过日志的方式快速定位问题，做到有据可查。
反馈原则
系统对用户的响应应该是具体、详细的，举一个很简单的例子，用户登录失败后应该反馈给用户的是“用户名错误”或者“密码错误”，而不是“登录失败”。
备份原则
做好代码备份、数据备份以及人员备份。
2、客户端优化
在高并发高流量的系统客户端的优化是必不可少的，如果没有做好客户端的优化影响用户体验是一方面，有时候甚至是致命的。
这里分享下我之前惨痛的教训：之前参与过一个秒杀的业务，就是因为前端的没有做优化，大量用户在刷新页面时服务器的带宽被打爆，页面加载不出来，影响了系统的发展，这是非常致命的。主要原因还是没有经验，以为后端做好高并发抵抗就可以。
客户端优化主要集中以下几点：
资源下载
- 减少不必要传输：例如减少cookie使用，因为cookie 随着请求发送而发送从而增加数据量。
- 减少数据量输出：例如删除JS无效注释，一来可以减少体积，二来可以提高代码安全。或者可以将文件压缩后传输。
- 减少请求 ：将资源数目多、体积小、频繁创建http请求的文件合并，比如JS合并、矢量图 SVG。
- 转移第三方：将请求转移至第三方，例如oss。
资源缓存
常见的资源缓存就是图片、样式和脚本。有些场景可以利用客户端的缓存帮助服务端分担压力，比如网约车中的预估价格，客户端可以缓存计算规则并缓存，减少向服务端的请求。
资源解析
我们知道页面中资源解析的顺序是从上到下，如果上面有改变下面也需要变动，所以我们要缩小回流、重绘的范围，比如虚拟dom。除此之外我们还可以利用懒加载和预加载进行优化：
- 懒加载： 先加载基础的，再根据用户的操作进行局部加载。将原来一次性要加载的拆分成多次加载，减少下载数量和耗时。比如：树节点、折叠面板、二级菜单等。
- 预加载： 当前页面对下个页面的解析、拉取资源。下面代码作为参考