高并发高可用系统的一些胡乱思考

原文连接： 何晓东 博客

我的理解高并发系统主要在于：机器资源的合理分配和性能的压榨，代码质量，及维护高并发系统在请求峰值的时候，系统中有机器宕机时整个系统的可用性。 核心是提升吞吐，下降响应时间。

随意想

还有几个观点是：高并发技术能够有，可是不少公司没有高并发场景。越是没有高并发场景的公司越愿意问高并发的问题，是为了考察面试者对于行业尖端技能的学习仍是为了压价？而有高并发场景的公司通常很在意基础，基础好的人写出来的代码比烂代码性能强一点的话，并发时会严重放大提高的这一点性能。

至于在有并发场景以前的优化网站性能，多数状况会依赖：1. 前端资源 CDN 化，公用的资源编译压缩，同时使用浏览器自身缓存，提高资源加载速度，也减小访问一个页面给此域名带来不少的请求。 2. 优化 SQL 操做，95%+ 的问题是 sql 优化能够提高的，对应也有代码中的魔性操做，带来的执行效率的问题。

高并发依赖于场景和逻辑

不必定每一个场景都会产生高并发，不要为了高并发而盲目的设计，过分设计带来的问题远比意料以外的高并发要多不少，依赖于具体场景和行为进行分析，一个购物类网站，抢购场景，会触发不少的读取商品详情，计算库存等操做，并且不须要每一个请求都到达支付页面，也不会在网站主页带来不少的请求，因此须要针对抢购场景进行优化，而不是巨大的支付流程进行优化，固然商品数量多和用户多的状况，才须要也优化一下支付流程。

抛开场景，不谈流量的盲目高并发设计，通常是过分设计，将来维护臃肿而复杂的代码会惩罚你当初的过分设计。

突如其来的高并发

基本是被人刷了，或者比预估的状况要多了几倍，才有这种状况，前者可能性很大，最近这两年的金融网站，区块链，xx币网站，基本会被羊毛党盯上，没作好访问防做弊，或者被对手 ddos 攻击，都会形成高并发中网站瘫痪，清洗流量通常就能够的，不要让辣鸡流量贯穿整个业务。高并发会带来网站请求慢，但网站请求慢不必定是高并发了，对症下药。

若是是网红带货什么的，给网站带来高并发了，这种状况下能够在提早流量上作些手脚，例如：1. 用消息队列排队流量，例如猴王网站的抢购 2. 采用一些高端点的验证码，让一些秒杀抢购的机器号被过滤出去，尽可能不影响真实用户的抢购结果 3. 分层过滤，例如静态资源放在 CDN 上，NGINX 层面使用自身的缓存，根据路由缓存基础数据，其余动态数据再读写数据库，而不是每一个请求都通过总体的业务，这样带来的压力太大了，并且也不值得。

并发中的总体项目稳定性

能够将高并发的业务部分分离到单独的服务器。这种状况下可以避免这部分业务带来机器性能的消耗，从而影响整个项目的稳定性，这样的结果不太好的。也能够预先将热数据放到缓存中，提升读写效率，也能让 MySQL 比较稳定，通常状况下能有高并发的网站，数据量也很多，举例某个电商网站，可能有 100w 商品数据，但你们抢购的是今天热推的 10 个商品，将这十个数据提取放到缓存中，而不是每次去数据库中查询，固然 MySQL 设置合理的话，自身的 buffer pool 也能搞定这些热数据缓存。这样至关于将这 10 条数据隔离出来，而不是影响到总体数据。关于热点数据的发现，还有一些高端的是从 NGINX 访问日志层面实时分析，听说淘宝这种是这样的，实时发现访问不少的路由，分析路由获取到对应的商品数据，放到缓存中，减轻服务器压力。

稳定性不光存在于业务机器层面，也多是网络宽带不够，或者程序在磁盘写日志的时候遇到瓶颈，或者内存不够，致使可用缓存空间很小。这些在测试和计算层面须要注意的问题，也会影响总体稳定性和性能的，应该提早解决。例如秒杀系统须要关注 CPU，并发读须要关注缓存，静态资源多的也须要考虑宽带。

预先测试

简单能够是压测关键业务部分，简单的查询通常不会带来问题，这个页面的静态资源太多，同时都在统一个域名下的话，至关于在现有并发的数量上加了更多，这很是不利，对于浏览器的加载也是不利的，简单业务也会体验不好。压力测试应当遵循慢慢提高流量的方式，并发量和响应时间并非等比例上涨的，慢慢提高并发量的测试，会展现代码的瓶颈部分在哪，而后在去解决和提高。测试也能够

在基础的并发测试以外，还有在正是服务器上的全链路压力测试，为了防止和真实数据冲突，能够将请求中加上额外的标记，或者针对特定的用户账号测试，在数据中体现这部分额外标记，测试完毕以后将数据删除。

同时，不要高并发的主要业务一直占用机器的 100% 的运算能力，这样总体逻辑和请求支持已经到了极限，基本再高一点就会形成问题，应该尽可能让业务只占用机器 60-70% 的运算能力，留出一部分的余地，防止意外。

安全及备用方案

高并发 + 高可用就须要考虑到崩溃的状况怎么处理，实时监控确定须要有，而后在崩溃以前，能够采起几个措施：1. 从 NGINX 层面限制单个 IP 单位时间内请求频率和次数，屏蔽掉机器刷的可能性，从而不影响正常访问。 2. 切记高并发 + 高可用不能够用单点系统，例如不能由于热数据少而就用一台 Redis 服务器，或者更狠的直接本机缓存，一旦系统崩溃，至关于触发连锁反应，连保存现场和恢复都很难。 3. 提早设计兜底方案 ① 降级，例如商品详情页面不展现推荐商品，或者减小推荐商品展现数量等， ② 限流，不让更多流量涌入，能减小不少压力 ③ 过载临界点拒绝服务，这个是最坏的状况，直接阻断压垮系统的最后一个流量。

参考连接：

1. 构建一个高性能、高可用的大型分布式网站
2. 关于高并发 - 知乎专栏
3. 如何得到高并发经验 - 知乎问答
4. sf 咱们讨论高并发的时候在讨论什么
5. 极客时间 - 设计一个高并发系统 -> 用个人码去购买