写Blog整整三年，虽然质量不高，但贵在坚持。

关于avro的优化

之前写了一些关于avro通用数据格式的想法，这里再补充一点，实际应用中对schema进行定义，

就意味着很高的管理成本，很多采用json或者hashmap为载体的方式可以非常灵活的增减字段，

但是缺点非常明显，性能较差、丧失类型、数据体较大等。为了解决schema灵活的问题，我的想法

是在avro的schema中定义一个int类型的字段保存schema的版本号或者hash值，在最后也增加一个

bytes类型的字段，保存schema列表。这个列表信息可以用一些压缩手段来减少体积。

schema的变更是比较低频的，所以不用每次都解析，一次解析后复用即可，在没有变更时可以忽略

对这个schema信息的反序列化。

关于背压

今年也写了好几篇文章来讲述我对背压的理解，无论是flink，还是自研的fregata。

总体的思路就是去采集和统计，上游Operator在从buffer中getEvent的costtime。

由于方法调用的耗时都很小，所以需要记录nanotime精度的耗时。

在定制flink时，是依托于其一个wait的逻辑，只有在真正发生背压的时候才进行记录。

但在fregata的自旋时间统计上有一个致命的缺陷，因为ringbuffer包装的原因，

最终只是简单的统计了getNextSeq的方法调用时间。但是这里有一个缺陷，即使没有很明显的背压，

只要调用足够频繁的话，也会累加出来一个较大的值，这会让报警的阈值非常难确定。

在做2.0时我们尝试实现taskTopology的全自动伸缩，主要依赖的指标就是背压导致的自旋时间了。

所以我一直在探索一个新的替代方案。

最近有了一些突破，从原来关注Producer的计算密度，转向对consumer。原来ringbuffer选择的

waitstrategy，由blockingtimeout改成了Lite。性能有很大的提升，减少了进入锁代码的的次数。

在Lite策略的技术上，我增加了一个waittime的回调监听。每次wait之后出发notify。

对这个waittime的累加，我们可以理解为下游消费者的繁忙程度，

离职

到这个月入职JD就满两年了，还是选择了在年前离开，这应该是我最后一次选择电商类的公司了。

来年再战，感谢各位看官。