交易如何保持安全

Question

我很想知道是否有人有这方面的经验。假设我去Zynga Poker等网站购买5,000,000个筹码。 1分钟后，该数据库由于某种原因被破坏，最后一次数据库备份是在6小时前。他们怎么可能断言我不会丢失我刚买的芯片？有哪些方法可以实现微交易的这种安全性？

谢谢

Answer 1

这是一个高级视图，试图解释许多数据库中发生的事情。

通常，将信息存储到数据库涉及两个操作：

1. 将交易记录到安全存储（磁盘）
2. 修改数据页上的数据

只有在完成这两项操作后才会提交任何数据修改。可以在本地复制日志以确保安全副本。它可能存储在SSD上以提高速度。

通常，数据库的用户不必担心日志（尽管DBA 非常关注）。然后，可以通过转到最后一个备份和/或检查点并“重新运行”日志来恢复数据库。

这解决了数据库在本地发生故障的问题。但是，它还有另外两个问题。一个是恢复性能，另一个是数据库服务器的致命丢失。这两个都可以通过使用数据库复制来修复，其中数据库的完整副本存储在物理上分开的位置。

一个简单的模型是你有数据库，只有一个入口点，所有查询都通过。此入口点可以将任何只读查询发送到任何数据库，但会将数据修改查询发送到所有数据库。在所有或大多数底层数据库都已提交事务之前，它不会返回。如果数据库出现故障，则只需关闭它，查询就会转到其他数据库。在恢复时，它从其中一个工作数据库中读取恢复文件。

这是一个值得思考的有用模型，但它仍然只有一个失败点。因此，有更多包含方案和点对点模型来管理复制。

记住一件事。 备份数据绝不是问题。问题是恢复数据和完整功能。支持事务只是我们经历的一个开销，所以如果发生某些事情，我们可以恢复功能。

Answer 2

通常，在这种情况下，如果您有购买证明，公司会给予人们全额退款，例如： paypal交易ID。

Answer 3

为各自的数据库实施高可用性解决方案。 SQL Server同步镜像（或同步可用性组）是零数据丢失。 （当然，Generals Problem仍然适用 - 没有真正的零数据丢失）。

这可以通过将所有事务立即复制到从属服务器来实现。只有两个服务器都将事务强化到磁盘时才会确认提交。

大多数企业都无法接受6小时的数据丢失。

我看不出是什么让这个问题特别针对微交易。任何类型的重要数据都可以并且应该以限制最大数据丢失量和最大停机时间的方式得到保护。