在商业聊天室中计算信用的正确方法是什么？答案

【问题标题】：What's the proper way to calculate credit in a commercial chat room?在商业聊天室中计算信用的正确方法是什么？
【发布时间】：2013-04-18 16:49:57
【问题描述】：

我正在开发一个项目，让用户可以在私人聊天室与专家聊天。用户购买积分与专家聊天，他们将在每次聊天结束时根据他们交谈的分钟数付费。每个专家每分钟聊天的信用率不同。

一个计时器在聊天会话开始时开始计时，并定期通知用户他们在聊天室上花费的总时间和当前聊天会话的当前总积分。这些计算必须在服务器端进行并保存在数据库中。顺便说一句，专家可以暂停/恢复聊天会话。

这是一个简单的场景...
用户当前拥有：10 个积分
“专家A”要求2学分/每分钟

CurrentTime Event       Timer       Credit

10:40 聊天会话开始 00:01 分钟 2credits
10:41 他们在聊天 00:02 分钟 4credits
10:42 Expert on idle 00:02 mins 4credits（聊天暂停）
10:45 专家上线00:02 分钟 4credits（聊天继续）
10:46 他们在聊天 00:03 分钟 6credits
10:46 客户端结束会话 00:04 分钟 8credits

将向客户收取 8 个积分。他还有 2 个学分。

聊天会话将在新一分钟开始时收费，将基于分钟进行计算，秒将被省略。

我的问题是如何在服务器端以正确的方式为当前正在谈论的每个聊天会话进行这些计算？

我目前的做法是；

服务器端计时器每 15 秒计时一次，获取当前聊天正在讨论的会话，

对于每个聊天会话：如果聊天会话没有暂停，则添加 15 秒到会话的时间跨度，然后计算总当前会话的信用，如果用户即将用完信用，通知他，如果他的信用已经用完，则结束当前聊天会议。将这些事务保存到数据库。更新聊天会话客户端。

但这种方法存在一些缺陷。例如，如果聊天会话现在开始并且计时器在 2 秒内滴答作响，那么它将在当前聊天会话的总时间跨度上增加 15 秒，因此它会计算错误。如果我减少计时器的滴答间隔，那么当前可能有 500 个正在交谈的聊天会话，并且计时器滴答间隔将不足以在 10 秒内计算每个聊天会话的信用。

有没有更好的方法来处理这个问题？欢迎所有建议。

顺便说一句，我正在使用 Asp.net MVC4 C# 和 Signalr 来处理实时聊天。

提前致谢。

【问题讨论】：

听起来您需要准确衡量聊天开始/停止/暂停/恢复的时间。如果您使用的聊天系统不提供该功能，那么您可能每秒（或几秒钟）存储所有活动聊天会话的列表，并每 15 秒使用此数据来完成更昂贵的工作以完全处理一切。请注意，如果您无法在 10 秒内处理当前负载，那么它只需增加 50%，您也无法在 15 秒内完成。因此，您可能很快就必须考虑提高效率或增加容量。
为什么要批量运行这些计算？我认为让它成为事件驱动会更简单：每 n 次通过聊天程序发送一条消息（来自专家或用户），检查花费的总时间并计算信用并采取行动因此从那里开始。这样一来，它是针对每个聊天会话进行的，并且比批量分析所有会话更精确且更容易扩展。
@ScottMermelstein 有很多不同的情况，例如如果专家 2 分钟或更长时间没有写信，则暂停聊天会话。所以我认为我必须使用一个计时器。可能，如果有人在你的方法上没有写 2 分钟，我将无法检测到用户是否用尽了信用。
您可以让聊天的一侧或另一侧成为计算时间的“大师”。如果用户提出问题而专家从不回应，那么真的不应该收取任何费用。专家回复后，您可以使用该回复的时间戳来计算当前聊天时长等。

标签： c# asp.net-mvc algorithm signalr

【解决方案1】：

我认为您必须不要批量执行操作。正如您所说，您会遇到如何充电的精确度问题。而且我相信您已经意识到快速扩展成为一个问题。最好让它全部由事件驱动。

正如我在 cmets 中所建议的，其中一部分需要简单地计算准确使用的时间。这很容易做到 - 存储开始时间（或专家的开始时间，取决于您的偏好），然后从结束时间中减去它，然后据此计费。

这可能带来的问题：

结束时间是什么时候？ 那是聊天程序通过会话超时、专家结束或用户结束关闭的时间。根据您的计费结构，我建议在这种情况下使结束时间也包括会话暂停。为了计算成本，可以离散地计算每个开始-暂停迭代（尽管理想情况下，它们会在计费摘要中组合在一起）。您可以在每次发送消息时检查用户是否仍有信用。
空闲时间呢？我们如何解释用户在消息之间的空闲时间比他们拥有的时间长？ 这应该不重要，真的。下次发送消息时，您可以告诉他们他们已过期。他们可能会因为花了几分钟输入一条不会发送的消息而感到恼火，但有一些方法可以避免这种情况。
- 如果您在每次发送消息时都检查帐单，则很容易注意到它们何时用尽，并发出警告。
- 这是一种完全不同的计费方式：会话开始后，您的服务器可以根据费率和余额计算会话可以持续多长时间。除非在此之前有停止或暂停事件，否则您确切知道他们何时会用完信用，如果暂停恢复，您可以根据剩余时间重新计算。

我实际上建议你做的是基于最后一个要点。在会话开始或恢复时，根据信用计算会话何时到期。将会话保持在按到期时间排序的有序列表中。然后，您的服务器端很容易 - 检查时间是否在任何会话到期时间之后。如果是，则推送结束通知。

在重新阅读您的要求时，我的想法可能过于被动，无法满足您的需求。一个问题是所有计算都在服务器端有多重要？我会提倡客户端保持会话计时器和成本计算器运行，这样用户就可以在没有客户端/服务器流量的情况下看到它。不过，服务器本身仍将负责计费方面。

否则，如果您必须推送时间和余额通知，我仍然会单独完成，而不是批量操作。您可以更新每条消息并为每次聊天添加计时器。每次有消息时重置计时器，否则，当计时器触发时，发送时间和余额更新。或者，如果您没有那么多计时器的资源，请对排序列表执行相同的想法 - 每次有活动时更新列表，并在最后一次活动时间 + 15 秒时对其进行排序。列表顶部的人可能需要推送时间和余额更新。

无论如何，我会专注于发送时间和平衡每条消息的想法，并找到一种方法让它从那里开始工作。

【讨论】：

感谢 Scott 提供详细的解决方案描述。您的排序列表解决方案可能不是一个好方法，因为客户不会为每个聊天会话购买积分。他们可以随心所欲地消费他们的积分。我在我的问题上添加了一个简单的场景。我的方法没有意义，因为它不像你所说的那样可扩展。我担心为每次聊天添加计时器，但我会考虑的。
我不会在这一点上过于努力，但我想提一下，我的解决方案并不假设每次聊天会话都购买积分。只要给定用户拥有的积分数和每次会话的成本，您就可以计算出最长可用时间。在您的示例场景中，您可以在会话开始时告知用户与专家最多有 5 分钟的活动时间。我不确定如何处理它，但很高兴看到您按分钟计费。在这种情况下，15 秒的精度就足够了，您只需要担心可扩展性。