Schema Registry爲元數據提供服務層。它爲存儲和檢索Avro schema提供了RESTful接口。它存儲所有schema的歷史版本，提供多個兼容性設置，並允許根據配置的兼容性設置進行schema演化。
Schema Registry是Avro模式的分佈式存儲層，它使用Kafka作爲底層存儲機制。下面是一些關鍵的設計決策：
（1）爲每個註冊schema分配全局唯一id。分配的id保證是單調遞增的，但不一定是連續的。
（2）Kafka提供了持久的後端。
（3）Schema Registry被設計爲分佈式的，具有單主架構，Zookeeper/Kafka協調主節點的選擇（基於配置）。
Avro Background
當通過網絡發送數據或將數據存儲在文件中時，我們需要一種將數據編碼爲字節的方法。數據序列化領域有着悠久的歷史，但在過去幾年中有了很大發展。人們開始時使用特定於編程語言的序列化方法，比如Java序列化，這使得使用其他語言的數據很不方便。然後人們轉向不依賴於語言的格式，如JSON。
然而，像JSON這樣的格式缺乏嚴格定義的格式，這有兩個明顯的缺點:
（1）數據消費者可能不理解數據生產者：8由於缺乏結構，使用這些格式的數據更具挑戰性，因爲可以任意添加或刪除字段，甚至可以損壞數據。跨組織的應用程序或團隊開始使用數據源的數量越多，這種缺陷就越嚴重。如果上游團隊可以隨意更改數據格式，那麼就很難確保所有下游消費者能夠解釋數據。缺少的是生產者和消費者之間的數據“契約”(schema，見下文)，類似於API的契約。
（2）開銷和冗餘：它們是冗餘的，因爲字段名和類型信息必須以序列化格式顯式表示，儘管所有消息都是相同的。
出現了一些跨語言的序列化庫，它們要求數據結構由某種模式定義。這些庫包括Avro、Thrift和Protocol buffer。使用模式的優點是它清楚地指定了數據的結構、類型和含義(通過文檔)。使用模式，還可以更有效地編碼數據。
Avro模式以JSON格式定義數據結構。
下面是一個示例Avro模式，它使用兩個字段指定用戶記錄:類型string的name和favorite_number以及int。
{"namespace": "example.avro",
"type": "record",
"name": "user",
"fields": [
{"name": "name", "type": "string"},
{"name": "favorite_number", "type": "int"}
]
}
例如，您可以使用這個Avro模式將Java對象(POJO)序列化爲字節，並將這些字節反序列化回Java對象。
Avro的一個有趣之處在於，它不僅在數據序列化期間需要模式，而且在數據反序列化期間也需要模式。因爲模式是在解碼時提供的，所以不必在數據中顯式編碼字段名等元數據。這使得Avro數據的二進制編碼非常緊湊。
Schema ID分配
模式ID分配總是發生在主節點中，它們確保模式ID單調地增加。
如果使用Kafka master election，模式ID總是基於寫入Kafka store的最後一個ID。
如果您正在使用ZooKeeper主選擇，/<schema. registration .zk.namespace>/schema_id_counter path將當前ID批處理的上限存儲起來，新的批處理分配將由主選擇和當前批處理結束觸發。此批處理分配有助於防止潛在的殭屍master現象。