confluent Schama版本检查异常

1. Connect 对Schema的处理过程

写个精简版流程:
Step1. 根据ID 获取Schema defination;

• 如果有缓存，从缓存中获取对象实例；
• 如果没有，从Schema Registry中根绝ID获取；

Step2. 根据Scham defination和 subject检查版本号；
Step3. 用schema defination做序列化处理。

2. 扒一扒：

说明一下对处理过程的理解和不理解：
1. Connect对Schema有缓存，了解，为了效率；
2. 不觉明厉的Schema版本，硬编码，如果你是结合hive的方案，一定会去检查的。这个我就不是很理解了，后面再专门说下这个schema版本控制；
3. Step1中进行了缓存，理解, 可是在Step2之后改变了这个缓存对象。加了个字段“schema.registry.schema.version“，这种处理直接倒吸一口凉气。

3.坑在哪里？

Image这样一个场景：两个Topic有相同的Schema定义，还是很常见的。这里有两个隐藏点：
1. connect要求subject名称和topic名称是关联的；
2. 如果schema的定义相同，ID一致；
依次处理Topic1和Topic2的数据：
1. Topic1开始写数据，Step1中，从Schema Registry拿Schema Defination，缓存；
2. Topic1 顺利通过Step2，然后，修改了Schema的缓存（见前面第3点）
3. Topic2 在Step1中，根据ID会从缓存中取到之前缓存的数据；
4. Topic2 在Step2中就呵呵了，schama已经被改写了，检查不通过。

4. 怎么规避

说下不是办法的办法：
1. 在schema defination中就定义”schema.registry.schema.version“
这个字段，大部分场景下，这是不可以接受的，因为需要在kafka中增加一列数据，如果结合HIVE，还会在HIVE表中增加一个列。
2. 避免两个topic用相同的schema定义；
3. 等着Confluent改掉，这个是issue:https://github.com/confluentinc/schema-registry/issues/343#issuecomment-228213654 请自觉屏蔽那个英文很丑的。