Schemaless的主要功能是什么

本篇內容介紹了“Schemaless的主要功能是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Schemaless trigger是一項具有可擴展性、容錯性和無損性的技術，監聽Schemaless實例中的變更。在行程（trip）流程中起到引擎的作用，從司機按下“結束行程”并向系統提交費用，直到相應數據進入數據庫等待分析。在Schemaless系列的最后一篇中，我們將深入講解Schemaless trigger的功能，以及如何開發出這個可擴展的容錯系統。

簡單來說，在Schemaless數據的基本單位被命名為單元（cell）。它是不可變的，一旦寫入，便無法被覆蓋。（在特殊情況下，我們可以刪除舊記錄）；單元可以被行鍵（row key）、列名（column name）和引用鍵（ref key）來引用；單元內容通過編寫引用鍵更高的新版來執行更新，但行鍵和列名保持不變。Schemaless不對其中存儲的數據執行任何操作（故而命名schemaless）。從Schemaless的觀點來看，它只負責存儲JSON對象。

Schemaless Trigger案例

我們來看一下實踐中Schemaless trigger的運作方式。下面的代碼是簡化版的異步計費方式（大寫標注Schemaless的列名）。案例Python代碼：

#我們實例化一個客戶端，以便與Schemaless實例通訊 schemaless_client = SchemalessClient(datastore=’mezzanine’) #為BASE列注冊一個bill_rider功能 @trigger(column=’BASE’) def bill_rider(row_key): # row_key是行程的UUID status = schemaless_client.get_cell_latest(row_key, ‘STATUS’) if status.is_completed: #也就是說我們已經提交了乘客的賬單 return #否則就嘗試提交賬單 #我們從BASE列拿到了基本行程信息 trip_info = schemaless_client.get_cell_latest(row_key, ‘BASE’) #提交乘客賬單 result = call_to_credit_card_processor_for_billing_trip(trip_info) if result != ‘SUCCESS’: #提交例外，讓Schemaless trigger稍后重試。 raise CouldNotBillRider() #成功提交乘客賬單，寫入Mezzanine schemaless_client.put(row_key, status, body={‘is_completed’: True, ‘result’: result})

在Schemaless實例中，我們在函數中通過添加decorator@trigger來定義trigger，并指定列。如果指定列的單元中有內容，通知Schemaless trigger框架調用函數——本例是bill_rider。這里通過BASE中的一個新單元表明行程結束。觸發trigger，然后通過函數來發送行鍵——本例是行程UUID。如果需要更多數據，必須從Schemaless實例——本例是從行程存儲Mezzanine中獲取真實數據。

bill_rider trigger函數的信息流見下表（這里是乘客結賬）。箭頭方向指明調用方與被調方，旁邊的數字指明流程的順序：

首先將行程輸入Mezzanine，Schemaless Trigger框架調用bill_rider。在調用時，函數向行程存儲請求STATUS列的最新信息。本例中is_completed字段不存在，也就是說乘客尚未結賬。然后獲得BASE列的行程信息，通過函數調用信用卡provider來結賬。在本例中，我們成功用信用卡付費，并返回成功信息到Mezzanine，然后設置STATUS列的is_completed為True。

Trigger框架確保在每個Schemaless實例中的每個單元至少調用bill_rider一次。一般來說只觸發trigger函數一次，不過在出錯的情況下（無論是trigger功能還是其他功能短暫出錯），都可能需要多次調用該函數。也就是說trigger函數是冪等的，在本例中要檢查單元是否處理完畢。如果答案為是，則返回函數。

在查看下文中Schemaless如何在流程中提供支持時，要記得這個案例。我們將會解釋Schemaless如何被看作變更日志，并討論與Schemaless相關的API，分享讓流程支持可擴展和可容錯的技術。

將Schemaless視為日志

Schemaless包含所有單元，也就是說包含指定行鍵、列keypair的所有版本。由于包含單元的所有歷史版本，除了隨機訪問key-value存儲外，Schemaless還可作為變更日志。事實上它就是一個分區日志，每個分片都是自己的日志，如下圖：

根據行鍵（也就是UUID）將每個單元寫入特定的分片。分片中的所有單元都有唯一標識符，稱為添加ID。添加ID是一個自動遞增的字段，代表著單元的插入順序（越新的單元，添加ID的數字越大）。除了添加ID之外，每個單元都有單元寫入的時間（datetime）。在所有分片備份中，單元的添加ID是唯一的，這點對于故障時轉移非常重要。

Schemaless的API支持隨機訪問和日志類訪問。隨機訪問API是針對單獨的單元，均由row_key、column_key和ref_key一同定義。

Schemaless還包含這些API端點的批處理版本，這里省略。之前說過的trigger函數bill_rider就使用這些函數來獲取并操縱單個單元。

對于日志類訪問API，我們關心單元的分片數字與時間戳以及添加ID（合稱位置location）：

與隨機訪問API類似，日志訪問API有更多可用的knob，實時從多個分片中抓取單元，不過上面的端點更為重要。位置可以是timestamp或added_id。調用get_cells_for_shard，除了單元之外，還返回下一個添加ID。例如，如果調用位置1000的get_cells_for_shards，請求10個單元，返回的下一個位置偏移是1010。

追蹤日志

通過日志類訪問API，可以追蹤Schemaless實例，就像可以在系統中追蹤文件一樣（比如tail -f），或者類似最新變更輪詢的事件隊列（比如Kafka）。然后，客戶端持續追蹤偏移，并將其用在輪詢中。要想引導追蹤程序，需要從第一條開始（比如位置0），或從任何時間，或偏移后。
Schemaless trigger通過使用日志類訪問API完成相同的追蹤，并保持追蹤偏移。輪詢API的好處直接表現在，通過Schemaless trigger讓這個過程具有可擴展性與容錯性。通過配置從哪個Schemaless實例、哪一列開始輪詢數據，將客戶端程序與Schemaless trigger框架鏈接。使用的函數或回調與框架中的數據流相關，在新單元格插入實例時通過Schemaless trigger或調用或觸發。反過來，通過框架在程序所運行的主集群中找到要找的工作進程。框架將工作分到可用進程中，然后通過將分到故障進程的工作分配給其他可用進程，巧妙地解決出現故障的進程。work分配代表著程序員只用編寫處理程序（比如trigger函數），并確保它是冪等的。剩下的交給Schemaless trigger來處理。

架構

在這部分中，我們會討論Schemaless trigger如何擴展，如何將故障影響最小化。下圖從較高角度展示了其架構，取自之前的賬單結算服務：

賬單結算服務使用了運行在三臺不同主機上的Schemaless trigger，我們（簡單起見）假設每個主機只有一個工作進程。Schemaless trigger框架區將分片按工作進程區分開，因此每個工作進程只負責處理一個特定的分片。注意：工作進程1從分片1拉取數據，工作進程2從分片2和分片5拉取數據，工作進程3從分片3和分片4拉取數據。一個工作進程只處理指定分片的單元，抓取新單元、為這些分片調用注冊的回調函數。一個工作進程就是指定的leader，負責向工作進程分派片區。如果進程掛起，leader將為故障進程分配的片區重新分配給其他進程。

在一個分片中，單元都是以寫入順序來觸發。也就是說如果特定單元的trigger總是由于程序錯誤而出現故障，就會阻礙該片區的單元處理。為了避免延遲，可以配置Schemaless trigger來標記多次出錯的單元，并將它們放在單獨的隊列中。之后，Schemaless trigger就會繼續下一個單元的處理。如果標記單元的數字超過了特定閾值，trigger就會停止。通常代表著系統錯誤，需要人工修復。

通過存儲每個片區中最近一次成功觸發單元的添加ID，Schemaless trigge繼續保持追蹤。該框架將這些偏移保存到共享存儲中，比如Zookeeper或Schemaless實例自身，也就是說如果程序重啟，trigger就會繼續從存儲片區的存儲偏移開始執行。共享存儲也用在meta-info中，比如協調選出leader，探知添加或移除的工作進程。

可擴展性與容錯性

Schemaless trigger是為可擴展而設計的。在被追蹤的Schemaless實例中，對于任意客戶端程序，我們能夠添加最多與片區數量一致的工作進程（通常是4096）。此外，我們能夠在線添加或移除worker，來獨立處理Schemaless實例中其他trigger客戶端的變動負載。通過在框架中追蹤進度，我們可以為要發送數據的Schemaless實例添加盡可能多的客戶端。在服務器端并沒有邏輯來持續追蹤客戶端或者將狀態推送過去。

Schemaless trigger也是容錯的任何進程故障都可以不影響系統。

• 如果一個客戶端worker的進程出錯，leader會將這個work重新分配，確保所有片區都有進程。

• 如果Schemaless trigger節點上的一個leader出錯，會有新的節點被選成leader。在leader選舉期間，可以繼續處理單元，不過work不能執行重分配工作，也無法移除和添加進程。

• 如果分片存儲（比如ZooKeeper）出錯，單元進程持續進行。不過就像在leader選舉期間一樣，work無法執行重分配工作，而在分片存儲出錯時進程也無法變更。

最后，在Schemaless實例中，Schemaless trigger框架是不可能出現故障的。任何數據庫節點出錯都沒關系，因為Schemaless trigger可以從備份讀取。

“Schemaless的主要功能是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！