红包雨压测环境

1. 参加活动的用户数量：10万人
2. 红包雨持续时间：30分钟
3. 一共5场，每次持续30秒
4. 每个用户在每场红包雨期间发出的请求数量：90个
5. 响应时间：500毫秒
6. 每台机器的使用情况：80%的CPU和内存，每个请求需要占用2MB的带宽
7. 积分作为基础权重，活跃度和贡献度指标的加权平均值作为调整权重
8. 总红包金额：100000元
9. 最小红包金额：0.01元
10. 最大红包金额：10元
11. 70%的请求集中在前15分钟内
12. 用户每秒发起的请求3个
13. 用户总数：30万
14. 在线人数：3万
15. 环境英国和波兰
16. 日活跃用户平均每天使用时长为约30分钟，每天打开次数在5-6次
17. Java环境/SpringBoot+SpringCloud+MyBatis/Redis/MySQL/RocketMQ/JDK8
18. 独立部署

并发预估

计算红包雨期间总请求数量： 总请求次数 = 用户数量 x 每个用户在红包雨期间发出的请求数量 总请求次数 = 10万 x 15 = 150万次

计算红包雨期间每分钟请求次数： 每分钟请求次数 = 总请求次数 ÷ 红包雨持续时间（分钟数） 每分钟请求次数 = 150万 ÷ 30 = 5万次/分钟

高峰期：150万 x 0.7 = 105万次，105万次 ÷ 15 = 7万次/分钟

峰值：

积分与权重

用户发布文章得10积分、点赞和评论得1积分、分享得5积分。

权重 = 积分 + 0.5 * 活跃度 + 0.5 * 贡献度

对于新用户，活跃度占比为70%，贡献度占比为30%。

新用户可以获得更高的活跃度权重，激励其参与平台活动。活跃度和贡献度比例：70:30。

活跃度权重分配：

登录频率的权重可以为20%
阅读文章的数量的权重可以为30%
关注的话题的权重可以为10%
分享的内容的权重可以为10%

贡献度权重分配：

发布文章的质量的权重可以为10%
被点赞的数量的权重可以为10%
被评论的数量的权重可以为5%
被分享的数量的权重可以为5%

对于高质量作品的作者，活跃度占比为30%，贡献度占比为70%。

根据用户行为数据，对用户进行分析。高质量作品的作者可以获得更高的贡献度权重，激励其继续创作。活跃度和贡献度比例：30:70

活跃度指标权重：

登录频率：5%
阅读文章的数量：5%
关注的话题：5%
分享的内容：15%

贡献度指标权重：

发布文章的质量：25%
被点赞数量：15%
被评论数量：15%
被分享数量：15%

对于普通用户，活跃度占比为50%，贡献度占比为50%。

普通用户活跃度和贡献度比例：50:50。

活跃度权重分配

登录频率： 30%
阅读文章的数量： 30%
关注的话题和分享的内容： 40%
登录频率可以占总权重的15%
阅读文章的数量可以占总权重的15%
关注话题可以占总权重的10%
分享内容可以占总权重的10%

贡献度权重分配

文章质量可以占总权重的15%
被点赞数量可以占总权重的10%
被评论数量可以占总权重的10%
被分享数量可以占总权重的15%

每个用户分发的红包数量

首先红包雨肯定是提前生成好的，在预热阶段已经拆分好具体的金额和数量了，60个。

每个红包的存活时间

根据年龄分配，超过60岁的为2秒，低于60岁的1.5秒

随机分配红包位置

在后端生成随机数，并将位置和数量发送给前端呈现，避免在客户端，用户可以通过调试工具等手段获取到随机数的算法，从而影响红包的位置。

红包速度、红包运动的轨迹、红包落地

红包速度、红包运动轨迹和红包落地方式都是设计游戏体验和用户体验的重要因素。以下是一些参考值：

1. 红包速度：一般来说，红包速度应该不太快也不太慢，以确保玩家有足够的时间点击红包。速度的参考值为每秒钟移动40到60个像素。

2. 红包运动轨迹：为了增加游戏趣味性和挑战性，可以设计不同的红包运动轨迹。参考值包括上下浮动、左右摆动、斜着飞行等。

3. 红包落地方式：落地方式可以设计成落到地面反弹、落到地面直接停止等。参考值为落到地面后反弹的弹性系数设置为0.6至0.8。

需要注意的是，以上参考值仅供参考，实际的设计应该根据游戏类型和玩家群体做出具体的调整。

红包状态、抢夺结果

红包雨的红包状态可以设计为以下几种：

1. 未开始状态：在活动时间之前，红包雨活动会显示为未开始状态，用户无法进行任何操作。

2. 进行中状态：在活动开始后，红包雨会进入进行中状态，此时用户可在规定的时间内参与抢红包活动。

3. 结束状态：当规定的时间到达或红包数量达到限制时，红包雨活动会进入结束状态，此时用户无法进行任何操作。

抢夺结果可以设计为以下几种：

1. 抢到红包：用户抢到红包后，可以在弹出的提示框中看到抢到的红包金额或优惠券信息。

2. 未抢到红包：用户如果没有抢到红包，可以在弹出的提示框中看到未抢到的信息提醒，同时可以继续等待下一轮红包雨。

3. 已经抢完：在红包雨活动结束后，如果红包已经被抢完，用户可以看到已经抢完的信息提示。

服务器环境配置

华为云

2台8核16GB通用型SSD500GB
云数据库Redis2核4节点
云数据库主备4核16GB通用型SSD200GB
弹性负载均衡
内容分发网络
缺点没有英国的，切仅包年包月

阿里云

3台8核16GB通用型SSD500GB
优点，有英国伦敦的服务器，且支持按量收费

ALB负载均衡（最高百万并发）计费方式：
https://help.aliyun.com/document_detail/447066.html?spm=a2c4g.311110.0.0.49403365fCu0sZ
ALB规格：
https://help.aliyun.com/document_detail/197202.html?spm=a2c4g.250240.0.0.6e69253bJsXvzj

CDN默认是按量计费，但是如果想包年包月计费可以购买资源包，利用资源包进行抵扣
具体扣费标准参考以下文档：
https://help.aliyun.com/zh/cdn/product-overview/billing-rules-of-basic-services?spm=a2c4g.11186623.0.0.32ec4ebfZpo5tP

腾讯云

法兰克福节点覆盖欧洲地区用户，带宽主要面向海外，大陆访问延时较高。

按照二八法则来推算 30w 用户的访问量

假设有 30W 用户，每天访问网站的用户占比为 20%，那么每天大约有6W 用户访问。
假设每个用户平均点击6次，那么总的页面浏览量 PV=36W。
一天有 24 小时，根据二八定律，每天大部分用户活跃的时间点集中在(24 * 0.2) 约等于 5 个小时以内，而大部分用户指的是（36w点击 * 80%）约等于 28.8W（PV）， 意味着在 5 个小时以内，大概会有 28.8W 点击进来，也就是每秒大约有 16( 28.8W/5 小时/3600)个请求。
16只是一个平均数值。在这 5 小时内，请求量并不一定均匀，可能会出现大量用户集中访问的情况（比如像淘宝这样的网站，日访问量高峰时间段集中在下午 14:00 和晚上 21:00，其中 21:00 是一天中访问量的最高峰）。通常情况下，访问量高峰时段的请求量是平均请求量的 3 到 4 倍（这是一个经验值），我们按照 4 倍来计算。那么在这 5 小时内，可能会出现每秒 64个请求的情况。因此，问题由原本的支撑 30W 用户，变成了一个具体的问题，就是服务器端需要能够支撑每秒64 个请求（QPS=64 ）。而这仅是日常访问量而言。

而压测环境下红包雨的用户在10万，一共5场，红包雨持续时间：30分钟，六分钟一场，平均每场大概有2万用户每秒发起的请求3个，每次持续30秒，2w*3=6W(PV)，6w/30=2000个请求每秒。峰值4倍就是每秒8000个请求(QPS)，TPS是（8000/0.5）= 16000(TPS是指每秒事务处理数，即每秒钟能完成多少个操作)。

Tomcat 影响因素

Tomcat 是一个基于 Java 的 Web 服务器，它需要通过 TCP 连接与客户端进行通信。TCP 连接对系统资源的开销最大的是内存，因为它需要设置读取缓冲区和写入缓冲区。在 Linux 系统中，这两个缓冲区的最小大小为 4096 字节。因此，一个 tcp 连接最小占用内存为 4096+4096 = 8k。如果机器内存为 8G，那么最大并发数约为 100 万。但是，在实际应用中，受到 Linux 内核对部分资源的限制以及程序业务处理的影响，8GB 内存很难达到 100 万连接。而对于红包雨而言，基本到不了这个级别的连接，所以不用担心这一个因素。

Tomcat 依赖的 JVM 的配置，JVM 内存的大小受到服务器配置的影响，例如，一台拥有 2 个核心和 4G 内存的服务器，分配给 JVM 进程的内存大约为 2G。这是因为服务器本身也需要内存，并且还需要为其他进程预留内存。这 2G 内存还需要分配给栈内存、堆内存和元空间，因此，堆内存可用的大约为 1G。

Tomcat 本身的配置：accept-count：这是最大等待数，当 HTTP 请求数量达到 Tomcat 的最大线程数时，如果有新的 HTTP 请求到达，Tomcat 会将该请求放入等待队列中。这个 acceptCount 就是指能够接受的最大等待数，默认值为 100。如果等待队列也被填满，那么新的请求将会被 Tomcat 拒绝（connection refused）。
maxThreads：这是最大线程数，每当一个 HTTP 请求到达 Web 服务时，Tomcat 都会创建一个线程来处理该请求。maxThreads 决定了 Web 服务容器能同时处理多少个请求。maxThreads 默认值为 200，建议增加。然而，增加线程会有成本，更多的线程不仅会带来更多的线程上下文切换成本，还会消耗更多的内存。JVM 默认在创建新线程时会分配大小为 1M 的线程栈，因此，更多的线程意味着需要更多的内存。线程数的经验值为：1 核 2g 内存为 200，线程数经验值 200；4 核 8g 内存，线程数经验值 800。
maxConnections：这是最大连接数，这个参数指定了在同一时间内，Tomcat 能够接受的最大连接数。对于 Java 的阻塞式 BIO，默认值是 maxthreads 的值；如果在 BIO 模式下使用自定义的 Executor 执行器，默认值将是执行器中 maxthreads 的值。对于 Java 新的 NIO 模式，maxConnections 默认值是 10000。对于 Windows 上的 APR/native IO 模式，maxConnections 默认值为 8192。
如果设置为-1，则禁用 maxconnections 功能，表示不限制 tomcat 容器的连接数。maxConnections 和 accept-count 的关系为：当连接数达到最大值 maxConnections 后，系统会继续接收连接，但不会超过 acceptCount 的值。