交易如何保持安全

Question

我很想知道是否有人有這種事情的經驗。假設我去Zynga撲克這樣的網站，並且購買了5,000,000個籌碼。 1分鐘後，該數據庫出於某種原因被損壞，最後一次數據庫備份是6小時前。他們怎麼會斷言我不會丟失我剛買的芯片？有什麼方法可以爲微交易實現這種安全性？

感謝

Answer 1

這是一個高級視圖，試圖解釋在很多數據庫中會發生什麼。

通常，把信息存儲到數據庫涉及兩個操作：

1. 記錄該事務，以確保存儲（磁盤）
2. 修改數據頁

任何數據修改是數據只有在這兩個操作發生之後才進行承諾。日誌可能會在本地複製以確保安全複製。它可能存儲在SSD上以提高速度。

通常情況下，數據庫的用戶不必擔心日誌（儘管數據庫是非常有關）。然後可以通過轉到最後一個備份和/或檢查點並「重新運行」日誌來恢復數據庫。

這解決了數據庫本地關閉的問題。但是，它還有另外兩個問題。一個是性能恢復，另一個是數據庫服務器的致命損失。這些都可以通過使用數據庫複製來修復，其中數據庫的完整副本存儲在物理上分開的位置。

一個簡單的模型是，你有數據庫，所有查詢都經過一個單一的入口點。此入口點可以將任何只讀查詢發送到任何數據庫，但會將數據修改查詢發送到所有數據庫。直到所有或大部分底層數據庫都提交了該事務纔會返回。如果數據庫發生故障，則只需關閉數據庫並查詢其他數據庫。在恢復時，它從其中一個工作數據庫讀取恢復文件。

這是一個需要考慮的有用模型，但它仍然存在單點故障。因此，用於管理複製的包含更多的方案和對等模型。

請記住一件事。 備份數據從來都不是問題。問題是恢復數據和全功能。支持事情只是我們經歷的開銷，所以如果事情發生，我們可以恢復功能。

Answer 2

通常情況下，在這樣的情況下，公司給人的全退款，如果你有購買，例如證明貝寶交易ID。

Answer 3

爲相應數據庫實施高可用性解決方案。 SQL Server同步鏡像（或同步可用性組）是零數據丟失。 （當然，Generals Problem仍然適用 - 沒有真正的零數據丟失）。

這可以通過將所有事務立即複製到從服務器來實現。只有當兩個服務器都將事務硬盤化到磁盤時，纔會確認提交。

對於大多數企業而言，6小時的數據丟失是不可接受的。

我不明白是什麼使這個問題具體到微交易。任何類型的重要數據都可以並且應該以限制最大數據量丟失和最大停機時間的方式受到保護。