Pulsar Schema简介

当前消息队列整体系统可用性趋于稳定，但是在使用过程中，上下游数据的安全性还没有得到有效保障，举个栗子：

type TestCodeGenMsg struct {
-	Orderid int64 `json:"orderid"`
+ Orderid string `json:"orderid"`
	Uid int64 `json:"uid"`
	Flowid string `json:"flowid"`
}

这种“不兼容”的格式将破坏大多数下游服务，因为他们期望数字类型但现在得到一个字符串。我们不可能提前知道会造成多少损害。例子中，人们很容易将责任归咎于“沟通不畅”或“缺乏适当的流程”。
我们期望基于简单的兼容策略管理 Schema 的变化，让数据安全地演进，解耦团队并允许他们独立快速行动开发。这就是我们为什么需要 Schema 管理。

Pulsar Schema跟其他消息队列产品的Schema类似，通过生产者注入到topic中，以元数据的形式保存在服务端

可以通过pulsar-admin来获取、查看：

./pulsar-admin schemas get "persistent://pulsar-a885p5p452k2/at_ns_reserved/tp_1-partition-43"

按道理来讲，第一个使用schema生产、消费topic的客户端就会导致服务端生成并保存schema
但是在使用过程中，发现了Pulsar2.7.2版本的一个问题：
无schema的生产者已建立连接，pulsar服务端也没有schema的情况下，带有schema的消费者尝试消费时会报错topic does not have schema to check

topic-does-not-have-schema

此时只能停止所有生产者，再让带有schema的消费者尝试消费就可以在服务端建立schema元数据了

Pulsar Schema 定义了一些兼容性规则，这些规则涉及我们可以在不破坏消费者的情况下对Schema 进行哪些更改，以及如何处理不同类型 Schema 更改的升级。具体怎么做呢？我们需要首先在 broker 上确认我们是否支持自动演进和当前 namespace 下的 schema 兼容策略，其中兼容策略有参考如下表格：

strategy

Schema 作为 Pulsar Topic 的元数据可以提供给 Pulsar SQL 进行使用，Pulsar SQL 存储层实现了 Presto connector 的接口，Schema 会作为 Presto payload 的元数据在 SQL 层进行展示，大大方便了我们查看消息，数据分析等工作，以上同我补充中所说的就是我们需要 Schema 管理的理由。感谢阅读。

Pulsar Schema简介

Pulsar Schema简介

FEATURED TAGS