闲聊kafka

在南京时，公司的boss系统（电信的短信系统）要与第三系统对接，第三方用的是php，并非java技术栈。分布式系统当时还没有这么吃香。那时能想到的最好解决方案就是共用同一数据库。
当BOSS统接收到一条短信时，向短信表中插入一条数据。而第三方系统利用另一张表，记录最后他们处理短信的id，因为id是递增的，所以第三方系统就可以获取增量数据了。

这种通过共享数据实现的系统现在看起来虽然有那么点……。但在当时也算是比较普遍的方案。

其实kafka和我上面的模型很相似，同样用到了递增特性，同样设制一个offset指针。只是实现的方式不同，kafka的offset用zookeeper保存，并且kafka允行多个消费者拥有不同的offset,就相当于在指针处理表里多加几条记录。
如果明白了以上机制，我们可以推断出，可以对kafka做些什么，比如可以手动控制offset的指向。或让多个消费者共用同一个offset。也可以绕过offset，直接读取kafka里的数据。

除了offset之外，kafka会把数据分派到不同的region中去，region相当于上面的短信表，如果有多个短信表，多个短信处理表，每个短信会保存到其中一张表中去，那我们就没法保证全局的顺序性。但我们能保证每张表中的数据是递增的。若能把同一个人发送的信息路由到同一张表中，我们在业务上也能保证局部顺序性。

以上提到的region概念也常用在nosql中，不过有些数据库的专业术语叫shardding(数据分片),mogodb和ES中应该都叫shardding，Hbase与kafka管它叫region。 番茄与西红杮同一个东西的两种叫法而已。

此外kafka与nosql的相似之处还在于它的数据写入方式，nosql数据库中为了减少磁盘IO次数，往往将数据暂存于内存之中（一般是以树的数据结构存储）。Hbase为了提高可靠性还要异步写一个日志文件（我曾在一个存证平台的技术选型中重点关注这块）。这样kafka与所有nosql一样，都存在丢数据的风险。也可以选择实时存储，那么性能就会下降了。

如果有人火冒三丈地来问我：明明是说kafka，为什么又扯到数据库呢？我会用天真无邪无的大眼睛盯着他，然后会傻傻地问：“kafka不是数据库么？”

最后我要说：
没有什么问题不可以用数据去解决的，如果一个数据库不够，那么就来两个。