Data Connect的消息处理机制

Data Connect Service提供同步数据到第三方。数据的change是来自数据库binlog生成的CDC (Change Data Capture)。

在系统设计中有几个挑战

• Ordering的问题。前端的service并不保证顺序。那Data Connect如何保证顺序呢？技术上来讲是不可能的。但是我们可以做到在不保证顺序的情况下依然能正确处理。方法是我们从最开始的服务开始引入了Versioning的概念。如果data connect拿到的对于某一条记录的event早于之前的event，我们就丢弃。这个逻辑我们叫stale checker。这个在sync的逻辑里是可行的。比如说我们有“Create->Update”,其实对于sync，create和update都是基于Id的upsert，如果我们拿到create晚一些，就直接丢弃。同样的“update->update”也没问题，当然前提是每次我们都是拿到整个记录的full payload，不然就会有问题。我们并没有field level的versioning。
• Duplication。Duplication其实我们并不太在意，因为我们的服务基本上是Idempotent的，也就是说同样的消息可以被处理两遍，没问题。原因是update本来就可以重新执行，create也可以，因为我们是根据id来的。还有就是我们有stale checker其实就能解决很多的问题。
• Partition. 最开始的版本没有separate topic。我们partition by billing account id。 好处有几个
  • 减少一个tenant占用所有的consumer的问题。当然side effect是某一些consumer会比较慢，如果一个tenant traffic比较多。
  • 减少row locking。
  • 控制并发。其实并发的控制我们其实可以用Resillience4j – 远程方法调用的工具箱 里面提到的同步控制机制。但是也会有负面影响。

潜在的enhance

• workers。我们不应该consumer thread里面处理所有的东西。应该用workers，这样就更容易scale out。问题是我们还是要保证worker的同步问题。如果有两个update对于同一个billing account，我们要保证scale checker依然可以工作。
• 减少tenant之间的影响。应该可以用dedicated topic来做。当然机制可能会比较复杂。我们应该还是需要common pool来出来ad-hoc traffic