新手浅聊大型高并发系统架构
作者：互联网
1. 大型高并发系统架构
高并发的系统架构都会采用分布式集群部署，服务上层有着层层负载均衡，并提供各种容灾手段保证系统的高可用,流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。
Nginx,是一款非常高性能的http代理/反向代理服务器,服务开发中也经常使用它来做负载均衡。Nginx实现负载均衡的方式主要有三种:轮询、加权轮询、ip hash轮询。
Nginx实现负载均衡通过upstream模块实现，其中加权轮询的配置是可以给相关的服务加上一个权重值，配置的时候可能根据服务器的性能、负载能力设置相应的负载。下面是一个加权轮询负载的配置，我将在本地的监听8001-8004端口,分别配置1，2，3，4的权重:
upstream load_server {
server 127.0.0.1:8001 weight=1;
server 127.0.0.1:8002 weight=2;
server 127.0.0.1:8003 weight=3;
server 127.0.0.1:8004 weight=4;
}
...
server {
listen 80;
server_name xxx.com;
location / {
proxy_pass http://load_server;
}
}
2.秒杀抢购系统选型
像火车票秒杀、很火的演唱会抢票、双十一活动秒杀等系统如何在高并发情况下提供正常、稳定的服务呢？
从上面的介绍我们知道用户秒杀流量通过层层的负载均衡，均匀到了不同的服务器上，即使如此，集群中的单机所承受的QPS也是非常高的。如何将单机性能优化到极致呢？要解决这个问题，我们就要想明白一件事：通常订票系统要处理生成订单、减扣库存、用户支付这三个基本的阶段，我们系统要做的事情是要保证订单票不超卖、不少卖，每张售卖的票都必须支付才有效，还要保证系统承受极高的并发。这三个阶段的先后顺序改怎么分配才更加合理呢?
2.1 下单减库存
当用户并发请求到达服务端时，首先创建订单，然后扣除库存，等待用户支付。这种顺序是我们一般人首先会想到的解决方案，这种情况下也能保证订单不会超卖，因为创建订单之后就会减库存，这是一个原子操作。但是这样也会产生一些问题，第一就是在极限并发情况下，任何一个内存操作的细节都至关影响性能，尤其像创建订单这种逻辑，一般都需要存储到磁盘数据库的，对数据库的压力是可想而知的；第二是如果用户存在恶意下单的情况，只下单不支付这样库存就会变少，会少卖很多订单，虽然服务端可以限制IP和用户的购买订单数量，这也不算是一个好方法。
2.2 支付减库存
如果等待用户支付了订单在减库存，第一感觉就是不会少卖。但是这是并发架构的大忌，因为在极限并发情况下，用户可能会创建很多订单，当库存减为零的时候很多用户发现抢到的订单支付不了了，这也就是所谓的“超卖”。也不能避免并发操作数据库磁盘IO。
2.3 预扣库存
从上边两种方案的考虑，我们可以得出结论：只要创建订单，就要频繁操作数据库IO。那么有没有一种不需要直接操作数据库IO的方案呢，这就是预扣库存。先扣除了库存，保证不超卖，然后异步生成用户订单，这样响应给用户的速度就会快很多；那么怎么保证不少卖呢？用户拿到了订单，不支付怎么办？我们都知道现在订单都有有效期，比如说用户五分钟内不支付，订单就失效了，订单一旦失效，就会加入新的库存，这也是现在很多网上零售企业保证商品不少卖采用的方案。订单的生成是异步的,一般都会放到RabbitMQ这样的即时消费队列中处理,订单量比较少的情况下，生成订单非常快，用户几乎不用排队。
未完待续
标签：负载,库存,并发,浅聊,用户,server,订单,新手 来源： https://blog.csdn.net/zt_9773/article/details/120784692