本文分析了在TeamsApp中大用户并发抽奖导致的性能问题，主要聚焦于存储和HTTP请求。通过场景模拟，指出当有2000用户并发参与时，storage table读写成为瓶颈。提出将抽奖信息与参与者信息分离，利用SQL DB优化读写操作，减少数据库压力。同时，讨论了用户反复点击可能导致的额外读操作，并提出了可能的解决方案。
我们这篇文章来分析一下之前遇到的大用户并发抽奖的性能问题，看看到底问题出在哪里，想想看后面如何解决。
做性能分析，我们需要先设想一个大用户的场景，然后基于这个场景来做评估，评估数据量，计算量，传输量，存储量等等。有了正确的评估后，就可以对症下药，设计相应的优化方案。
之前 LuckyDraw 遇到的问题就是当一个 Teams 的 team 里有 2000 用户同时点击参与抽奖，luckydraw 基本上就卡死了，之前在 azure app insights 里看过错误日志，基本上都是 azure storage table 的错误，错误是指 storage table 返回无法处理请求。
所以这次分析我假设的场景是 3000 个用户一个 Teams 的一个 team 里，或者在一个 group chat 里，然后有人发了一个抽奖，大家看到后纷纷点击参与抽奖，所有的用户在15秒内都完成了点击参与抽奖。所以在这个场景下，我们至少要能 handle 每秒处理 200 个参与抽奖的请求。
有了这个假设后，我们再来看一下单个参与抽奖的操作有哪些，我过了一遍代码，有这些步骤：
从 storage table 读取抽奖的完整信息（包含目前所有的已经参与的人）
最低0.47元/天 解锁文章
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
