对于做过数据处理，使用过消息队列的小伙伴 ，Kafka可以算是老朋友了，但是最近一个场景下，新的用法，让其变为了MongoDB的新搭档。
开始
从一个问题开始，熟悉MongoDB的小伙伴，可能使用过changeStream。
changeStream：允许应用程序实时订阅和处理数据库中的数据变化，即当MongoDB Client使用changeStream来订阅某个表的时候，表中的实时数据有变化，则会被MongoDB Client端近乎实时监控并获取到。但是这种实时的数据监控获取背后，隐藏着很大的成本。
沉重的changeStream
看过MongoDB Client源码的伙伴，可以发现对于changeStream的实现 ，MongoDB Client的实现，是一个不关闭的cursor， 不断的查询(对于数据库的操作符: getmore)，是否有新的符合要求的数据产生。这样对于数据库每秒轮询的次数 ，取决于网络io耗时，假设每次查询耗时10ms，则1s内 可以查询，数据库 1000/10 ⇒ 100次。
这还是开启了一个changeStream，如果一个MongoDB Client开启了多个changeStream，而整个服务又有多个MongoDB Client，那么对于MongoDB Server来说，是很消耗资源的，所以changeStream 对于MongoDB Server 来说，比较重。
搭配Kafka，优化一下
优化后，搭配Kafka，结构变为了 MongoDB → kafaka → kafaka client，如下
再前后对比一下 ，
可以看到的changeStream 减少了，只和kafka交互， MongoDB Server压力小了很多 ，此外随着订阅者的增多，请求与交互的增多，这种结构还有额外的优势，
- 订阅数量：Kafka 单实例支持最大订阅数的能力还是更多的。
- 横向扩容：虽然MongoDB也支持横向扩容 ，但是相对来说 ，Kafka的横向扩容相较于MongoDB更轻松些。
同时由于单个Kafka实例就可以支持较高的订阅数，扩少部分的实例，就可以获得更多的并发订阅能力。
Kafka - MongoDB 二者关系
搭配Kafka，MongoDB 有两种使用关系，
关系1 ：AS source - MongoDB 作为数据源
这种就是上面提到的，结构 ：MongoDB → Kafka → APP (Kafka Client)
MongoDB作为数据的提供者，Kafka 做数据扩散。
作为数据扩散服务，扇形结构，类似的服务很多，还有之前写过的SNS 【一文搞懂 AWS-SNS 服务】），也是可以做扇形数据扩散。
关系2：AS sink - MongoDB 作为接收者
结构：Kafka → MongoDB → APP (MongoDB Client)
MongoDB作为数据接受者，接收来Kafka的数据，存储数据并提供给下游更高效的查询能力。
最后
MongoDB配合Kakfa，在有些场景下，十分有益。但这种做法其实优缺点也比较明显，
- 优点 ，减轻数据库负担，订阅容量增大， 横向扩容能力变强 。
- 缺点，也显而易见，新增一个Kafka服务，维护成本也会变大。
所以，如何选择，要根据实际场景，实际的数据量，订阅量来决定是否搭配Kafka。