之前做的几个项目陆续上线了，碰到了不少稀奇古怪的问题，还有一些运营的问题，这里总结一下。

mysql字段类型

之前binlog测试都还算顺利，上线后发现了一些不常用的字段类型没有覆盖到，导致了一些数据异常。

Bit

mysql的bit类型字段在binlog中解析出来默认是bitset，按照默认逻辑tostring的话会输出{0,1}。

canal的处理是把bitset转成long型，也就是把bitset转为long就可以了。

enum

mysql的enum类型之前我是从来没有用过的，这次也碰到了。enum类型的字段在JDBC中是char，

所以需要在char类型中做一下区分。

监控kafka consumer

消费kafka都需要关注积压情况，以此来判断是否需要扩分区或者是消费者。

普遍的做法是关注生产的offset和消费者的offset差，有不少开源的监控工具都是这样做的。

然后根据经验设定一个阈值，超过了就告警。

但是这个阈值的设定非常繁琐，阈值的大小与业务量的大小有关，跟提交offset的频率有关，

跟监控程序扫描的频率有关，大多数阈值设定都非常大，灵敏度不高。

我新上线的几个系统都是使用消费延迟时间来做告警的，在数据写入kafka（0.10以上的版本）的时候，

将timestamp设定为当前时间，或者是一个业务时间。消费kafka的consumer，按照Partition做一个统计，

consumer端将消费的数据时间戳和当前时间进行比对，来判断是否延迟，如果连续几分钟监控的延迟都

大于10分钟，那么就认定程序当前消费能力不足，需要增加副本数来解决。

如果你使用的kafka是0.8.2的话，没有timestamp的位置，可以通过key来传递。