扩展数据库中的临时记录以计算总数以阻止过度订阅

Question

我正在研究一个系统，人们可以在其中回复免费的网络会议，这些网络会议可能会变得非常忙碌，有很多兴趣，而且席位有限，所以必须有某种方法来确保它不会过度 -已订阅...因此，我们需要从他们预订座位到完成并确认订单的时间进行倒计时。这样，实际上点击“参加”的前 X 个人就获得了会议席位。如果用户没有完成预订，他们分配的座位将被放回池中供其他人抢用...

发生的情况概述（我如何看待这个最佳工作方式）

1）用户在事件上单击“RSVP”，这使得 发送到 /rsvp/{event_id}/ 的 AJAX 请求

并存储唯一的 id（在本问题的其余部分中称为令牌）以及时间戳。它也将该令牌存储在会话中。

然后通知用户他们有 X 时间（假设 5 分钟）来完成其余详细信息（姓名/电子邮件/出生日期等）

但是：在将任何内容放入数据库之前，它会检查待处理的数量是否订单少于可用座位总数，如果不是（会议没有剩余座位），则返回“抱歉，没有可用座位了，请继续检查，因为预订尚未完成，有更多可用座位”

2)如果用户填写此内容及时，它将他们的详细信息存储在数据库中作为“参加”......

但是，如果他们未能及时填写表格，则每秒都会运行一个 cron 作业，并检查并删除任何时间戳超过的令牌5 分钟前，他们将失去参加会议的机会，会议上的这个“席位”随后会被放回池中。 （他们会收到通知，他们不成功并返回到第一步）

所有这些都很容易编写，只需将记录放入数据库中，执行 COUNT(*) FROMending_bookings WHEREconference_id = {x} 计算出有多少席位已确认或待定订单，然后从会议可用席位总数中减去。

但我不认为使用 MySQL 在这方面具有很大的可扩展性 - 这些已经（而且我确信还会有）超过 20 万人试图抢占大约 200 个席位，为每个席位执行 COUNT(*)这些人会变得相当昂贵，而且我们无法做任何像样的缓存，因为它需要实时检查有多少人在这个过程中。

我已经研究过使用 Amazon SimpleDB 来实现此目的，只是因为它具有部署即用的可扩展性，但是我以前用过它，发现 COUNT() 不一定准确（我猜它是可扩展性的本质）-出于明显的原因，COUNT 需要 100% 准确，我需要能够添加记录和时间戳对它和能够删除超过五分钟的记录。

Answer 1

在我看来，所有 20 万人都可以得到一个“令牌”来开始，但只有 200 人可以完成令牌。

所以我想到了两件事；
1) 为什么不跟踪活动本身的“剩余座位”，这样您就不会进行计数，并且不会发生超额预订，因为更新活动所需的锁定将防止其低于零。

2) 在个人订阅期间的任何时候，如果剩余席位降至零，所有剩余代币将变得无效，并且用户被“踢”出注册过程（对此表示友好并道歉，但所有席位现在都已满等）

Answer 2

为其中每一个人执行 COUNT(*) 操作将变得相当昂贵

你发现了吗，或者这是一种直觉？我宁愿对此进行基准测试（以及您的网络服务器是否可以承载该负载），而不是事先假设它。索引（以及正确选择存储引擎）在这里可能会有很大帮助。

此外，让人们在注册活动之前注册并输入帐户数据不是更方便用户吗？因为现在你似乎更喜欢打字速度快的人，或者使用不错的浏览器的人。

Answer 3

您可以缓存数据库中的可用计数，并在每次发出（注册开始）、确认（注册完成）或撤销（超过 5 分钟）令牌时更新该计数。但如果您需要这种性能，那么这确实不是 SQL 数据库的用途。

您可以使用 堆 实现一个相当简单的令牌代理（基于 expiring-soonest ）。每次请求令牌时，它都会检查最早过期的令牌并查看它是否已过期。如果是这样，则将其从分配给的人手中撤销，然后将其交给新人。如果没有，请告诉他们稍后再试。

注册完成后，您必须从堆中删除该令牌（这是一个相对昂贵的操作，但您只执行了 200 次）。因此，您的堆中的令牌始终等于空闲+待处理插槽的数量。

每秒处理数千个 find-soonest-expiring 请求，例如 Fibonacci 堆即使在普通的硬件上也是微不足道的。

我没有检查，但我怀疑其他人已经解决了大部分（如果不是全部）这个问题，您也许可以下载所述令牌代理。

Answer 4

抱歉误读了问题。在这种情况下，我建议使用一个缓存表（是的，你可以），该表将使用事务所在表上的触发器（ON INSERT / DELETE）进行更新。

当您允许用户进入事务时，您将他的哈希值和过期时间戳插入该表中。它触发一个触发器，该触发器将根据 - +1（插入）/ -1（删除）更新缓存值（即缓存表中的值）。

当检查是否有空闲座位时，您检查缓存表。

这种缓存可以工作吗？ :)

Answer 5

Redis http://redis.io 非常适合您想要做的事情。您可以保留可用座位的柜台，存储临时数据并使其自动过期......超级通用。

Answer 6

我同意 xQbert 的观点，每次成功出席填写完成后，您只需减少该活动的数据库行（或相邻表）中的总数即可。

如果您担心预订冲突，那么只需在填写考勤信息时将其递减即可；然后向临时表添加一行，表示具有此会话 ID 的人员正在填写此活动的出席表，并且从该时间戳开始他们有 5 分钟的时间来完成。当他们完成表格后，他们的条目将从临时表中删除。

然后在此表上运行一个 cron 作业，查询小于或等于当前时间（5 分钟）的时间戳。任何出现的事件都将从表中删除，并且他们的事件将重新获得席位。然后，当他们在超过 5 分钟的时间范围内提交表格时，系统会检查以确保他们在表中仍有条目，然后再永久保存座位。

如果没有，请检查是否还有剩余座位。如果有则减少座位数并插入其预订记录。如果没有，那么给他们一个错误，表明他们没有在规定的时间内完成表格，失去了排队的位置，并且你的座位用完了。

它非常简单，并且可以在 PHP 端完成所有操作。您可能想在他们的页面上放置一个 JS 计时器，以便他们知道还剩下多少时间。

Answer 7

也许值得重新审视您的设计：

剩余座位数是座位总数减去预订座位数。

该数字仅在特定时刻有效，因为预订座位数会发生变化。

要预订座位，您需要进行一项交易：用户发出信号表示她想要预订一个或多个座位，处理注册，然后最终预订（或不预订）。

只要这笔交易还没有完成，你计算出的剩余座位数很可能是错误的。

这里有两个选项：

1. 宽容锁定
2. 乐观锁定

对于第一个选项，每次用户启动事务并告诉应用程序应该预订 X 个席位时，这些 X 个席位都会被锁定。这并不意味着这些座位已经被预订，它们只是被锁定，因此用户有足够的时间来完成预订交易。如果交易完成，这些锁定的座位将被用户预订。

对于第二个，乐观锁定，用户只是开始注册，但没有任何内容被锁定。预订交易结束时，如果不再有足够的座位，交易可能会失败。

宽容锁定可能会阻止某些用户在开始事务之前进行订阅 - 即使他们可以在一天后进行订阅 - 乐观锁定可能会阻止某些用户在事务结束时进行订阅。

您需要找出最适合您的情况的方法。通常乐观锁定对用户来说更友好（因为只有一些在最后失败），但是宽容锁定将帮助您在事务结束时不会让用户感到沮丧。如果票证总是出现挤兑，也许宽松锁定是最好的。

您可以考虑如何通过发挥可用性来减少用户的挫败感。例如，使用乐观锁定，事务中的每个页面都可以在顶部有一个 AJAX 剩余计数器，提供当前剩余席位数，因此您可以在席位用完时尽早通知用户。因此，即使他们可能已经将某些内容放入表格中，他们也可以看到他们的做法是多么幸运（或足够快）。

顺便说一句，我不会限制用户注册的时间。这会给用户带来压力。通过乐观锁定和 AJAX bar，如果座位用完，用户将承受足够的压力。只是你的系统不需要关心注册。

如果您想放心地允许注册，则需要选择宽松锁定。然后你需要一个超时，但我会为每个用户操作执行此操作，因此如果用户处于活动状态，超时将再延长 15 分钟，直到完成。我会在这里选择一个较高的值，以免用户因超时而感到沮丧。

对于那些想要在所有可用席位都被注册交易锁定的情况下注册的用户，您应该提供一个后备列表，并告诉用户当前 X 个席位已被注册锁定，但他们可能会幸运地稍后获得另一个席位。或者，您允许超额预订锁定席位的数量，以便这些用户排队，以防其他用户未成功完成其交易。

顺便说一句，数据库设计应该反映您预先定义的过程，我认为只要您知道要实现的目标，您就不会遇到真正的问题。由于一切都是在商业交易中完成的，您甚至可以对每个事件的总座位数、预订座位数和锁定座位数进行简单的统计。这是一个简单的查询，不需要像 COUNT(*) 那样进行聚合。触发器和存储过程也很有帮助。

Answer 8

我认为应用于 200k 条记录的 COUNT(*) 可以相当快地检索到。我刚刚尝试查询 243k 条记录，花费了不到 1 秒的时间。

但我认为你甚至不需要 COUNT，除了最后的确认步骤。

我认为你也不需要任何“cron jobs”。这肯定比仅仅查询数据库更加密集。

更不用说如果活动已经订满，您甚至不必让用户检查有多少人参加。一旦达到 200 名与会者，您就可以更改另一个 db 值。如果您没有剩余座位，首页甚至不应该显示可点击的按钮。

另外，如果还有足够的座位，为什么要限制用户 5 分钟呢？为什么用“cron job”清理他们的会话并强迫他们重新开始？如果还有100个座位怎么办？相反，当 200 个座位被预订但尚未全部确认时，最新的答题器将旧的一一排挤。

在首页上有“注册按钮”，不需要执行 COUNT(*) 查询。

你可以让它这样做：

SELECT `event_status` from `events` WHERE `event` = 'this_event';

一旦所有座位都被确认，event_status 就可以更新。

然后使用 PHP 或其他任何东西，您要么显示按钮，要么显示“抱歉，活动已满”。

if($event_status == 'full') { echo 'Sorry, it's full; }
else { echo $press_this_button; }

一旦 200 个座位全部被预订，但尚未全部确认，您就开始将人们赶出去。当新人单击该按钮时，您将执行此操作。

SELECT MIN(time_initiated) as time_initiated, id, sessID FROM testtime WHERE `time_initiated` <= DATE_SUB(NOW(), INTERVAL 5 MINUTE);

如果这给了你任何结果，那么你就可以将你的人从等候名单中剔除。只需将他的会话标记为“已过期”，如果他确实单击“提交”，请首先检查该事件是否已完全确认。如果是这样，请告诉他抱歉，他来得太晚了。如果没有，则重复上面的查询，将其他人从列表底部踢出，并确认他，除非所有等待列表上的人都小于5分钟，这种情况下你可以让他等几分钟，然后看看是否有空闲的地方。

每次成功确认后，您可以查询已确认客人的 COUNT，如果数量超过 200 人，您可以将 event_status 更改为“full”并防止其他人点击该按钮。他们只会看到活动已满的消息。您应该能够将这两个查询包装在一个事务中，以确保多人无法同时预订，从而导致您最终超额预订。

这只是我的2分钱。