用 Pulsar 开发多人小游戏（五）：什么是 schema？为什么要用 schema？

本文是《用 Pulsar 开发多人在线小游戏》的第三篇，配套源码和全部文档参见我的 GitHub 仓库 play-with-pulsar 以及我的文章列表。

我推荐《数据密集型应用系统设计》这本书的第四章：编码与演化（在线阅读地址）。

编码（encoding）和演化（evolution）是两个不同的概念，我举例说明一下。

编码是把内存中的数据结构转化成某种格式的字节序列，方便传输或存储。

我们最常见的编码方式就是 JSON 了，JSON 的好处就是字符串处理起来很简单，且易于人类阅读；但问题是支持的数据类型不够丰富，且传输效率不高。为了解决 JSON 的这些问题，就出现了 XML 格式或者 protobuf 这样的二进制编码协议。

确定了编码方式，生产者就可以愉快地把数据编码成对应的格式发送进 Pulsar，消费者只要按照按照同样的协议解码，就能得到原始数据了。

但问题是，我们开发的程序是在不断变化的，所以数据本身的结构很可能发生变化，这也就是演化的概念。

比如说一开始我把这个 User 类序列化成 JSON 字符串然后发到 Pulsar 中：

class User {
    String name;
    int id;
}

但是随着业务发展，我发现用 int 类型已经无法表示用户 ID 了，需要把 id 这个字段改为字符串类型：

class User {
    String name;
    String id;
}

这种情况下，生产者依然可以把这个类序列化成 JSON 然后发到 Pulsar 中，Pulsar 不关心数据本身的内容，默认把所有数据都视为字节数组，所以会欣然接受生产者发来的消息，但消费者那边消费数据时肯定会出问题。

那你说，我同时改生产者和消费者的代码还不行吗？可以，但依然存在很多问题，比如说：

1、在复杂的业务场景中，数据处理的逻辑可以非常复杂，生产者和消费者可能横跨多个部门，协调成本很高。

2、必须先下线所有消费者，代码升级完之后才能重新上线。否则消费者突然消费到无法识别的新的数据格式，会产生不可预期的错误。

所以，让系统能够更加灵活地适应变化，就是 schema 能够给我们提供的价值。

有了 schema 来描述数据的格式，我们就可以设置数据结构的兼容性（compatibility），比方说我们可以设置数据向后兼容，即新代码可以读取旧格式的数据；或者设置向前兼容，即旧代码可以读取新格式的数据。

在 Pulsar 中使用 schema

schema 相关的官网文档：

https://pulsar.apache.org/docs/next/schema-overview/

我们可以设置 schema 的兼容性，官网文档：

https://pulsar.apache.org/docs/next/schema-understand#schema-compatibility-check-strategy

我们在创建 Pulsar 的生产者/消费者时可以指定消息的 schema：

// 指定生产者的 schema
Consumer<User> consumer = client.newConsumer(Schema.AVRO(User.class))
        .subscriptionType(SubscriptionType.Shared)
        .topic(topicName)
        .subscriptionName(subscriptionName)
        .subscribe();

// 指定消费者的 schema
Producer<User> producer = client.newProducer(Schema.AVRO(User.class))
        .topic(topicName)
        .create();

每个 topic 的 schema 演化信息都会存在 Pulsar 当中，这样当生产者使用新的 schema 时，Pulsar 会判断新的 schema 是否符合当前的兼容性设置，如果符合则更新 topic 对应的 schema，否则的话则会拒绝生产者发来的消息，这样消费者就不会收到不符合预期的数据了。

在我们的炸弹人游戏中，玩家可以产生很多不同类型的事件，这些事件应该以什么格式发送到 Pulsar 的 topic 中呢？

我的做法是创建了一个 EventMessage 结构，用 Type 字段标识事件的类型：

type EventMessage struct {
	// Event type
	Type   string `json:"type"`
	Name   string `json:"name"`
	Avatar string `json:"avatar"`
	// Comment stores extra data
	Comment string `json:"comment"`
	X       int    `json:"x"`
	Y       int    `json:"y"`
	Alive   bool   `json:"alive"`
	List    []int  `json:"list"`
}

然后用 Avro 的方式定义了一个 JSONSchema：

const eventJsonSchemaDef = `
{
  "type": "record",
  "name": "EventMessage",
  "namespace": "game",
  "fields": [
    {
      "name": "Type",
      "type": "string"
    },
    {
      "name": "Name",
      "type": "string"
    },
    {
      "name": "Avatar",
      "type": "string"
    },
    {
      "name": "Comment",
      "type": "string",
	  "default": ""
    },
    {
      "name": "X",
      "type": "int"
    },
    {
      "name": "Y",
      "type": "int"
    },
	{
      "name": "Alive",
      "type": "boolean"
    },
    {
      "name": "List",
		"type": {
			"type": "array",
			"items" : {
				"type":"int"
			}
		}
    }
  ]
}
`

// player event topicName
producer, err := client.CreateProducer(pulsar.ProducerOptions{
    Topic:           topicName,
    // use schema to confirm the structure of message
    Schema: pulsar.NewJSONSchema(eventJsonSchemaDef, nil),
})

这样一来，就可以通过 Schema 的约束避免未来可能产生的很多问题。

更多高质量干货文章，请关注我的微信公众号 labuladong 和算法博客 labuladong 的算法秘籍。