高并发架构

一.什么是高并发？

        高并发（High Concurrency）是指系统能够同时处理很多请求或者任务的能力。在计算机领域，特别是在网络服务、数据库系统、Web应用等领域，高并发是一个重要的性能指标。

当一个系统需要处理大量用户的请求时，如果系统能够有效地支持并处理这些请求，就可以说这个系统具有高并发能力。高并发系统通常需要处理大量的并发用户，而不降低系统的性能或导致请求的延迟。

      以双十一举例，某宝上有双凉鞋，因物美价廉大受欢迎，所以有一千万人在一秒内竞相购买。换句话说，系统服务在一秒内承受了一千万次访问。这便是高并发场景。

二.如何提高并发的能力？

1.服务器性能提升：

        提高单机性能（垂直扩展），项目部署多台服务器，做分布式集群（水平扩展）。

2.微服务架构：

        将系统按业务拆分成多个服务，每个服务可独立运行，天然支持垂直扩展和水平扩展。

3.负载均衡：

        使用Consul负载均衡技术，将请求均匀地分发到不同的服务器节点上，防止某个节点过载。负载均衡可以基于轮询、权重、性能监测等算法进行。

4.数据库优化:

       合理设计数据库索引、表结构（减少冗余字段），数据类型。使用数据库连接池，采用数据库读写分离，分库分表等策略，以提高数据库的并发处理能力。避免select * 全查，明确列出需要检索的列。对大数据集，避免使用not in子句，增加where条件，尽量使用limit分页子句。合理使用缓存（Redis）,数据库服务器可增加内存，使用固态硬盘等。

5.异步处理：

        将一些耗时的操作设计成异步任务（async/await/tpl），通过消息队列(mq)或异步处理框架来处理，从而释放主线程资源，提高系统的并发处理能力。

6.无状态设计:

        尽量设计为无状态的服务，这样可以更容易实现水平扩展。无状态的服务意味着每个请求都是独立的，不依赖于之前的请求状态。

7.并发控制：

        使用合适的并发控制手段，如锁、分布式锁、乐观锁等，来确保对共享资源的安全访问。同时，避免过度的锁竞争，以免造成性能瓶颈。

8.cdn(内容分发网络)：

         使用CDN可以将静态资源分发到全球各地的节点上，减轻服务器的负载，提高内容的访问速度。

9.压测和性能监控：

        定期进行压力测试，模拟高并发情况，发现系统的瓶颈并进行优化。同时，实时监控系统的性能，及时发现并解决问题。可利用Apifox，JMeter等工具进行并发测试。

10.高效算法和数据结构：

        使用高效的算法和数据结构来提高系统的处理效率，减少不必要的计算和存储开销。

11.容灾和备份：

        设计容灾和备份机制，确保系统在面临异常情况时能够保持可用性，防止因故障而导致系统无法正常工作。

这些方法通常需要根据具体的应用场景和系统架构来选择和组合使用。同时，随着技术的发展，新的方法和工具也不断涌现，因此保持对新技术的关注也是提高系统并发能力的重要手段。

三.超卖/少卖

        超卖：高并发场景中，凉鞋可能只有一百双，一千万个人竞相购买。如果系统设计不合理，可能会出现一百双已售磐，但仍然出现用户下单购买的情况。这将导致库存为负数，用户不能支付等情况。

        如何避免这种情况发生呢？可提前将商品，数量存入redis缓存中。秒杀商品时，判断redis库存是否充足，再通过lua脚本去执行扣减库存操作。因为redis是单线程性，所以在调用eval命令执行期间，是不会解收其他请求的。无需额外执行事务。业务方面，可在订单服务，或者支付服务，通过mq或者cap等，利用事件发布订阅机制，或者队列（先进先出）去执行数据库的一个扣减操作。表设计，可利用乐观锁，增加rowserion版本戳或时间状态字段标记每个商品的库存信息。在用户购买时，检查库存是否充足，如果充足则进行扣减操作，并更新版本号。如果库存不足，不进行扣减操作。这样可以在并发情况下避免超卖问题。代码层面可利用分布式事务和分布式事务锁确保同一时刻只有一个节点可以进行库存扣减操作，避免不同节点同时对同一商品进行扣减。

        少卖：高并发场景中，凉鞋本来有一百双，但一千万人抢购时，卖出去了九十九双，还剩最后一双，剩下的人被告知，不能购买了。虽然商家没有经济损失，但用户被恶心到了。身为用户的我们能忍嘛？当然不能忍。

        如何避免这种情况发生呢？首先探究一下为何会出现最后一双凉鞋卖不出。

        1.购买时，redis已进行扣减，但在支付时，用户取消下单了。数据库没有更改。针对这种情况，可使用队列或mq，如果用户取消下单，则通过mq/队列对redis进行补偿操作。

        2.购买时，redis扣减，支付时，支付功能出错。导致用户支付后迟迟未更新数据库。前端迟迟未更新。导致其他用户以为还剩下一双。可通过mq，或者分布式事务对业务功能进行重试策略。重试失败，还可保存错误日志，可人工处理，也可回滚业务。

        3.购买时，服务器可能因网络延迟等原因处理响应超时。可提升系统性能，对用户限流。避免用户在短时间内重复提交请求。可查看我之前的网关策略进行限流