歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
原創宣告：本文首發騰訊雲·雲+社群，未經允許，不得轉載
前言
儲存網路行業協會SNIA（StorageNetworking Industry Association）快照的定義：關於指定資料集合的一個完全可用拷貝，該拷貝包括相應資料在某個時間點（拷貝開始的時間點）的映像。快照可以是其所表示的資料的一個副本，也可以是資料的一個複製品。
需要注意的是：快照是完全可用的拷貝，但不是一份完整的拷貝，至於為什麼，後面會詳細講。
儲存快照的使用場景
場景一：
儲存快照，是一種資料保護措施，可以對源資料進行一定程度的保護，通俗地講，可以理解為----後悔藥。
如上圖，假設在t0時刻，有一份完整的源資料，我們在t1時刻，針對這份源資料建立一份快照。
t2時刻，若因為各種原因（誤操作、系統錯誤等）導致源資料損毀，那麼，我們可以通過回滾（rollback）快照，將源資料恢復至快照建立時的狀態（即t1時刻），這樣，可以儘量降低資料損失（損失的資料，是t1到t2之間產生的資料）。
這種功能，常用於銀行、公安戶籍、科研單位等。作業系統、軟體升級或機房裝置更替，一般會選擇在夜間或其他無生產業務時，進行高危操作，操作前會對資料進行快照，若操作失敗，則將快照進行rollback，將源資料恢復至操作前的狀態。
場景2：
前言中說過，快照是一份完全可用的副本，那麼，它完全可以被上層業務當做源資料。
如上圖，針對源資料，建立快照後，將快照卷對映給其他上層業務，可以用於資料探勘和開發測試等工作，針對快照的讀操作不影響源卷的資料。
這種功能，常用於直播（視訊&圖片）鑑黃、科研資料模擬開發測試等，比如，視訊直播平臺需要將某一段時間的視訊提供給執法機構進行篩查分析，那麼可以通過對特定時間點儲存的資料建立快照，將快照對映給執法機構的業務主機去進行挖掘分析。
儲存快照的實現原理
目前，快照的實現方式均由各個廠商自行決定，但主要技術分為2類，一種是寫時拷貝COW（Copy On Write），另一種，是寫重定向ROW（Redirect On Write）。
寫時拷貝COW
COW(Copy-On-Write)，寫時拷貝，也稱為寫前拷貝。
建立快照以後，如果源卷的資料發生了變化，那麼快照系統會首先將原始資料拷貝到快照捲上對應的資料塊中，然後再對源捲進行改寫。
寫操作：
如上圖簡要示例，快照建立以後，若上層業務對源卷寫資料X，X在快取中排隊，快照系統將X即將寫入的位置（邏輯地址）上的資料Y，拷貝到快照卷中對應的位置（邏輯地址）上，同時，生成一張對映表，表中一列記錄源捲上資料變化的邏輯地址，另一列記錄快照捲上資料變化的邏輯地址。我們可以看到，上層業務每下發一個資料塊，儲存上，發生了兩次寫操作：一次是源卷將資料寫入快照卷（即圖中Y），一次是上層業務將資料寫入源卷（即圖中X）。
讀操作：
如上圖，快照卷若對映給上層業務進行資料分析等用途時，針對快照進行讀操作時，首先由快照系統判斷，上層業務需要讀取的資料是否在快照卷中，若在，直接從快照卷讀取，若不在，則查詢對映表，去對應源卷的邏輯地中讀取（這個查表並去源卷讀的操作，也叫讀重定向）。這一點，恰好就解釋了為什麼快照是一份完全可用的副本，它沒有對源捲進行100%的拷貝，但對上層業務來說，卻可以將快照看做是和源卷“一模一樣”的副本。
針對源卷進行讀操作時，與快照卷沒有資料互動。
我們可以看到，快照對源卷的資料具有很好的保護措施，快照可以單獨作為一份可以讀取的副本，但並沒有像簡單的映象那樣，一開始就佔用了和源卷一樣的空間，而是根據建立快照後上層業務產生的資料，來實時佔用必需的儲存空間。
快照回滾（rollback）：
如上圖，回滾操作的前提條件是，鎖定源卷（暫停對待回滾的邏輯地址上的IO操作），然後通過查對映表，將快照捲上的對應資料回拷到源卷中。
快照刪除：
採用COW技術的快照，其源卷即儲存著完整的實時資料，因此，刪除快照時，直接銷燬了快照卷和對映表，與源卷不存在資料互動。
寫時重定向ROW
ROW(Redirect-on-write )，也稱為寫時重定向。
建立快照以後，快照系統把對資料卷的寫請求重定向給了快照預留的儲存空間，直接將新的資料寫入快照卷。上層業務讀源卷時，建立快照前的資料從源卷讀，建立快照後產生的資料，從快照卷讀。
寫操作：
如上圖簡要示例，快照建立以後，若上層業務對源卷寫資料X，X在快取中排隊，快照系統判斷X即將寫入源卷的邏輯地址，然後將資料X寫入快照卷中預留的對應邏輯地址中，同時，將源卷和快照卷的邏輯地址寫入對映表，即寫重定向。我們可以看到，上層針對源卷寫入一個資料塊X，儲存上只發生一次寫操作，只是寫之前進行了重定向。
讀操作：
若快照建立以後，上層業務對源捲進行讀，則有兩種情況：1）若讀取的資料，在建立快照前產生，資料是儲存在源捲上的，那麼，上層就從源捲進行讀取；2）若需要讀取的資料是建立快照以後才產生的，那麼上層就查詢對映表，從快照捲進行讀取（即讀重定向）。
若快照建立以後，上層業務對快照捲進行讀，同樣也有兩種情況：1）若讀取的資料，在建立快照前產生，資料是儲存在源捲上的，那麼上層就查詢對映表，從源捲進行讀取；2）若需要讀取的資料是建立快照以後才產生的，那麼上層就直接從快照捲進行讀取。
我們可以看到，ROW快照也是根據建立快照後上層業務產生的資料，來實時佔用必需的儲存空間。
快照回滾（rollback）：
採用ROW技術的快照，其源卷始終儲存著快照建立前的完整資料，快照建立後，上層業務產生的資料都寫入了快照中，因此，快照的回滾只是取消了對源卷的讀重定向操作。通俗地說，就是源捲上沒有進行任何資料操作，上層業務對源卷的讀，僅限於讀源卷（即不會去讀取快照卷的資料）。
快照刪除：
採用ROW技術的快照，其源卷始終儲存著快照建立前的完整資料，快照建立後，上層業務產生的資料都寫入了快照中。因此，若要刪除快照，必然要先將快照卷中的資料，回拷到源卷中，拷貝完成才能刪除，如上圖。此時我們可以設想，如果，針對一份源資料，在18:00建立了快照，上層業務持續產生大量新的資料，19:00又建立了快照，20:00又建立了快照……那麼，在有多份快照的情況下，如果需要刪除快照，就會出現，多個快照向源捲回拷資料的情況，可能導致回拷量非常大，耗時很長。
兩種技術對比
如上表，COW的寫時拷貝，導致每次寫入都有拷貝操作，大量寫入時，源卷的寫效能會有所下降，而讀源卷是不會受到任何影響的，刪除快照時，只是解除了快照和源卷的關係，同時刪除了快照卷的資料而已。ROW在每次寫入僅做了重定向操作，這個操作耗時是幾乎可以忽略不計的，源卷的寫效能幾乎不會受到影響，但讀源卷時，則需要判斷資料是建立快照前還是建立快照後，導致大量讀時，效能受到一定影響，比較致命的是，若源卷有多個快照，在刪除快照時，所有快照的資料均需要回拷到源卷才可以保證源卷資料的完整性。
結語
上面簡單地介紹了儲存快照的實現原理，實際上，快照特性應用廣泛，其應用物件是很多的：
目前，主流廠商在自研產品上，對上面的ROW和COW技術都有小範圍的改動，也有一些新興的快照技術已經誕生，但這個行業裡，沒有最好的快照技術。技術為業務服務，只有針對業務型別做好本地化適配，才能達到最佳效用。
問答
相關閱讀
此文已由作者授權騰訊雲+社群釋出，原文連結：https://cloud.tencent.com/developer/article/1158686?fromSource=waitui
歡迎大家前往騰訊雲+社群或關注雲加社群微信公眾號（QcloudCommunity），第一時間獲取更多海量技術實踐乾貨哦~
海量技術實踐經驗，盡在雲加社群！