如何设计一个抢红包系统？

拆包算法

• 随机发红包：每个人可以获取的红包金额等于[0.01,99.91)的左闭右开区间；最后一个人不用随机了。缺点是生成的过程不均匀。
• 线性切割法：把总金额类比成一根绳子，把绳子切N-1刀，每个人能抢到的红包金额等于切割绳子的占比。
• 二倍均值法：每次抢到的红包 = 随机区间（0， M/N * 2)，M是总金额，N是红包个数，任何人抢到的红包都不会大于人均的二倍。比如100个人抢5个红包，第一个人抢到的红包金额为(0.01,100/52)，第二个人抢到红包的金额为(0.01, 80/42)，最后符合金额正态分布，在20左右。

业务架构图

首先使用户和前端页面进行交互，网关微服务做主机鉴权，看看用户有没有登录认证，如果没有用户认证的话需要到用户认证微服务到用户微服务中查询用户，注册或者登录成功之后跳转到聊天室，对应聊天室微服务。

用户微服务，用户认证微服务和聊天室微服务是面向用户。用户微服务对应图片微服务和账户微服务，分别存储用户信息和提供账户管理功能，聊天室微服务可以发红包和存储历史消息。。

外部依赖redis缓存，Nacos注册中心和Seata-Server.

发，抢红包流程

调用发红包的API，先检查用户余额是否大于红包金额，如果用户的余额大于红包的金额的话，将一条红包记录保存到数据库里，更新账户余额把并且用红包生成算法将红包放入Redis.

抢红包的时候要判断红包个数是否大于0，大于0就更新redis的缓存并且插入一条抢红包记录，再把对应的红包入账。抢红包入账是异步实现的，采用消息队列，红包入库系统可以监听MQ,如果信道上有消息就更新账户并且将记录保存到数据库。引入MQ可以实现高并发，高可用，高可扩展。

首先将个人红包记录入库，红包个数和红包金额扣减，用户金额增加，成功就返回ACK，失败就返回失败ACK.

高并发问题

• 超卖：不同用户在读请求时候发现商品库存足够然后同时发起请求，进行秒杀操作导致库存为负数；同一个用户在有库存的时候连续发出多个请求，两个请求同时存在，于是生成多个订单，不同用户抢红包导致红包为负数或者同一个抢到多个红包。解决办法是分布式锁，可以基于Redis或者Zookeeper实现，Redis是NoSQL数据，ZK是分布式协调工具，redis通过设置key有效期防止死锁，zk通过使用绘画有效期解决思索，Redis是NoSQL并且ZK需要创建删除节点，所以Redis效率最好，但是Redis有效期不是很好控制，可能会导致有效期延迟，而ZK临时节点有先天可控的有效期，因此ZK更可靠。小并发选择ZK,性能优先选择redois。
• 数据一致性：发红包之后红包服务要将红包放入数据库，红包服务要调用账户服务更新账户数据库，微服务之间远程调用要保证数据一致性，然后还要保证事务不失败。为了保证数据一致性，要用到分布式事务。分布式事务方案可以使用seata，seata使用2pc实现。
• 消息可靠性：调用红包服务，更新Redis，然后利用MQ解耦，更新数据库。使用消息队列保证消息可靠性，有ACK确认机制。生产者ACK可以知道消息是否到达消息队列，消息队列ACK之后MQ队列能知道消费者有没有正常消费消息。可以使用重试机制或者消息补偿来保证幂等性。

秒杀系统优化点

秒杀界面CDN

内容分发网络(CDN)。可以在秒杀开始前，预先把网页的静态资源存放在CDN节点，用户在刷新界面时直接从CDN获取静态资源，从而降低刷新秒杀界面对服务器造成的压力。添加了CDN服务之后，秒杀界面有大量用户同时访问和刷新并不会给服务端带来多大压力。

秒杀按钮优化

秒杀系统往往会有一个秒杀按钮，如果不对按钮进行限制，可能存在以下问题：

• 用户在秒杀开始前点击按钮，造成很多无用的请求
• 用户在秒杀开始后多次点击按钮，造成很多重复请求
  可以对按钮做一些限制：秒杀开始前按钮不可用，用户点击一次秒杀暗流后，暗流也进入不可用状态。这种发过誓无法限制通过脚本请求后端的情况，但是可以限制正常用户的多次无效点击，大大降低请求量。

秒杀链接优化

用户在点击秒杀暗流的时候，前端会请求一个固定的 URL，这个URL可以在前端界面查到。对于普通不懂技术的用户来说，这没有什么问题，如果用户稍微懂点 Http 协议，就可以在秒杀开始前拿到 URL， 在秒杀开始前或者开始的毫秒级时间内请求秒杀链接，不仅会给服务端带来很大压力，还会造成不公平现象：商品都被开脚本的人抢走了。为了避免这种现象，可以把URL动态化，即使秒杀系统的开发人员也无法在知晓在秒杀开始时的URL。具体实现方法是在获取秒杀URL的接口中，返回一个服务器端生成的随机数，并在下单URL中传递该参数完成下单。

秒杀验证码

动态 URL 避免了用户在秒杀开始前请求秒杀链接，但是用户还是可以通过脚本在米哦啊啥开始的那一刻去请求秒杀链接，普通用户基本没有办法和脚本秒杀进行竞争。可以引进机器难以识别的验证码，用户在请求秒杀链接之前，需要填写验证码识别的结果，验证码错误的请求直接拒绝。使用验证码不仅可以增加脚本秒杀的难度，还可以降低请求的QPS，因为请求不再是在秒杀那一刻进来，而会被分散到填写验证码的时间段内。

过滤请求

可以在用户端和服务端添加一层过滤层，只要保证有100个以上的请求能打到秒杀服务器端。使用Nginx服务器来构建过滤层，一个Nginx服务器也没法扛100W的请求，假设每个 Nginx 服务器可以处理 10 W的请求，那么就需要10台 Nginx。可以简单的让每个Nginx服务器只通过前 100 个请求，后续请求直接返回降级界面，通过 Nginx过滤，可以把 100W的请求过滤为 1000 个请求，大大的减少了服务器端的压力。

Redis缓存

如果通过前面的过滤，请求量依旧非常大，如果数据库无法处理这些请求量，需要在数据库之上添加一层Redis缓存。单个Redis可以处理几万的 QPS，如果预估请求的 QPS 大于几万，可以使用 Redis 集群模式来增加 Redis 的处理能力， 在Redis 存放和售卖商品数目大小相同数字，藐视服务每次访问数据库之前，都需要先去Redis中扣减库存，扣减成功才能继续更新数据库这样，最终到的数据库的请求数目和需要售卖商品的数目基本一致，数据库的压力可以大大减少。

Redis原子性

Redis是不支持事务的，所以可能出现扣减为负数的情况，这种情况下可以使用Lua脚本来保证一次扣减操作的原子性，从而保证扣减结果的正确性。

异步更新数据库

通过Redis判断之后，去更新数据库的请求都是必要的请求，这些请求数据库不需要处理，但是如果数据库还是处理不过来这些请求怎么办呢？

这个时候就可以考虑消峰填谷操作了，消峰填谷最好的实践就是MQ了。经过Redis库存扣减判断之后，我们可以确保这次请求需要生成订单，我们就可以通过异步的形式通知订单服务生成订单并扣减库存。