red_envelope_server

这个版本主要是理清业务的逻辑，实现三个接口，用postman测试通过

设计

数据库

数据库的设计是两张表，数据库的读取、写入用的是GORM框架

red_envelope

id	uid	Opened	Value	snatch_time
1	123	1	10	Int(64)

user

id	Count
123	5

在这个版本中，对red_envelope，user两张表的查询操作在sql文件夹中

web框架——Gin框架

在这个版本中，为结构清晰，分三个文件创建了路由，见router文件夹

功能需求——实现三个接口

抢红包接口

1、根据前端传入的uid查询用户，没有的话就创建用户（写入数据库）

2、判断用户的count是否大于个人最多抢红包数

3、判断当前的发放的总红包数是否超过了上限

4、根据概率计算用户这次应不应该拿到红包，轮盘赌算法，请求有10分之1的概率被处理，这样既满足了概率也减轻了后端的压力,只处理十分之一的请求

5、如果上述的2，3，4条件都满足了，为当前用户生成红包（写入数据库），当前的发放的总红包数加1，当前用户的count加1（更新数据库）

拆红包接口

1、前端传来两个值envelope_id和uid，判断envelope_id的值是否已经在数据库中存在，不存在直接返回

2、利用envelope_id找到对应的红包（查询数据库），用查到的uid和前端传来的检验对比进行检验（安全性之一）

3、如果这个红包已经开过了，直接返回就行

4、打开一个未打开的红包，更改红包的状态为opened，返回value

这里是没有数据库的写入操作的就是读一次

钱包列表接口

1、根据uid查询用户的所有的红包，按时间排序

2、构造符合要求的json格式

打开的红包返回value，没打开的红包不需要返回value

{
                "envelope_id": 123,
                "value": 50,     // 红包面值
                "opened": true,   // 是否已拆开
                "snatch_time": 1634551711     // 红包获取时间，UNIX时间戳
  },

性能需求——高并发

数据库预热

包括两个部分

1、mysql

因为红包雨的总金额，总个数，每个红包的金额范围都是配置好的，所以可以直接把钱分到每个红包中，把数据库中envelope_id，opened，value都填入

2、redis

缓存预热，把数据库中的一部分值先读到缓存中

消息队列RocketMQ

参考链接https://www.cnblogs.com/sindragosa/p/14262100.html

基本的思路是把利用消息队列RocketMQ存储用户抢红包的请求，

消息队列的服务用docker容器部署到云平台上，golang需要完成的部分是client-go Topic，client-go producer，client-go consumer

Nginx负载均衡

这个地方我还没来的及调研，但我想部属的时候能做成微服务，一般注册中心对同类型的服务/请求都可以实现负载均衡