php - 如何构建账户余额系统

Question

这更多是关于如何构建用户记账余额架构的理论问题。对于堆栈，我们可能会使用带有 Doctrine 的 Symfony，但我认为该语言不是最相关的。

问题:

我们需要为每个用户创建和维护使用余额，以便我们的 rest API 用于计费。

计费分为三种类型:

1. 固定价格，例如每年/每月
2. 根据每次 API 调用后付费使用。
3. 根据每次 API 调用预付费用。

在同一个帐户中混合使用这些。 API 调用可以有不同的价格。

问题并不像拥有一个带有“余额”列的 SQL 表并更新它那么简单。我们需要记录账户上的存款和取款，并跟踪每个 API 调用和使用情况以供审计。所以这意味着我们可能需要一个交易表。

所以这是我需要建议的地方。对于大型应用程序，我们是否应该将每个用户的交易都放在同一个表中，然后使用 SQL 汇总每个日期的余额？不久之后，这张 table 可能会变得很大。 100 万次 API 调用 = 100 万行。

我们或许可以利用某种借记/贷记解决方案。因此，当支付发票时，订单系统将向该帐户添加正余额。当进行 API 调用时，它会根据价格扣款。

由于我们有 3 种不同的计费模型，我们可能会使用某种标签，上面写着“API 调用 1 2 3 是固定价格，API 调用 4 5 6 按使用量付费”。

如果是后付款，余额将为负值。

在每次计费运行中，订单系统都会询问余额系统要开具多少发票。

关于如何以合理的方式构建它有什么想法吗？

Answer 1

如果您定义“正常”的标准，您可能会得到更多/更好的答案。

这方面的规范模型确实是一个事务表。暂时忽略性能问题，事务表给您带来很多好处:

• 每个操作都会被记录下来，因此您可以轻松查看当前帐户余额是如何产生的。
• 您可以轻松查看过去任意时间的账户余额。
• 在创建交易时很容易管理 - 您只需在交易表中插入一个新行，而不必执行一堆复杂的业务逻辑来查找当前用户的余额，制定适当的定价模型，然后修改余额，同时维护事务/锁以避免并发写入

因此，我推荐“事务表”模型。

至于实际问题 - 是的，它们会增长得相当快。幸运的是，SQL 数据库非常擅长处理大量记录，在设计良好的数据库中，数亿行并不是特别大的挑战。但是，有一些常见的策略可以避免大量记录。

最常见的是，您可以编写一个归档程序。通常，在“后付款”帐户中，例如，当客户支付发票时，您将发票中涵盖的所有交易写入存档表，并在交易表中将它们替换为一行。对于后付款客户，您可以执行相反的操作。

您还可以随时间对逻辑进行分区 - 我工作的一个系统有一个名为“事务”的 View ，它是基于时间的表架构上的一个薄层每个月，IT 部门都会删除并重新创建查看指向名为例如 jan2014、feb2014 等的表。他们将在这些月度表中填充每个客户的期初余额。这工作出奇地好，尽管它很笨重并且需要在月底停机。

您可以根据客户类型进行分区 - 3 个事务表，而不是一个大表。