介绍
BlaBlaCar的软件体系结构正受到其成长和团队组织的挑战。 从历史上看，它的后端是一个PHP巨石，在RabbitMQ代理周围有数百名异步工作者，以及一堆预定的cron作业。 为了进行扩展，从2017年初开始，我们决定升级此骨干网：将整体移植到面向服务的体系结构（SOA）。
在迁移期间，整料和SOA必须在生产中共存。 小心谨慎地逐段删除整体代码，直到将其完全由服务替换。 同时，业务显然需要保持运行，新功能和修复程序需要不断实施。 整个过程就像更换飞行器的引擎一样。
- Smashcut 365：每天拍摄一部影片-第28周
- 使用非法流媒体设备的消费者面临的风险
- Apache Pulsar —使用多租户为整个企业提供一个集群
- 2018年Hulu对阵Netflix
- Engle Studio：Du Podcast au Contenu Audio Premium
但是，我们如何保证整体和服务之间的数据一致性？ 我们如何知道服务何时以与整体相同的方式运行？ 我们何时知道服务是否准备就绪，可以依赖整体中的相关代码和数据？
为了回答所有这些问题，我们构建了可靠的变更数据捕获（CDC）堆栈，使服务可以观察MySQL整体数据库的所有数据库更改。 CDC数据可以被认为是事实的来源，因此服务可以将数据与自己的数据进行比较，并在存在任何不一致的情况下报告指标，并最终用事实来纠正错误的数据。 此外，可靠的CDC数据可用于简化我们当前的后端数据跟踪堆栈，并减少开发新功能和为商业智能收集数据之间的摩擦。
在这篇文章中，我们将解释该CDC堆栈的构建方式，并更具体地关注于我们如何使其高度可靠。
CDC和Debezium
更改数据捕获是一种软件设计模式，它记录了应用于数据库表的INSERT，UPDATE和DELETE，并提供了有关更改内容，更改时间和更改时间的记录。
Debezium是一个开源项目，为更改数据捕获（CDC）提供了低延迟的数据流平台。
这是一个Kafka源连接器，可将更改从数据库流到kafka主题。 它支持MySQL，MongoDB，PostgreSQL和Oracle。
借助Confluent的avro转换器和模式注册表，CDC数据可以立即以avro格式进行编码，从而简化了使用这些数据的服务或其他kafka连接器。
debezium捕获的数据更改的示例：
在使用消息时，重复数据删除器将计算密钥并检查它是否已存储在其键值存储中。 如果不是，它将保存数据并将其发送到另一个kafka主题（与以前相同的主题名称，但带有前缀），否则它将仅跳过该消息。
结果，重复数据删除器的输出表现为简单的debezium连接器的流。
重复数据删除器键值存储
重复数据删除器是使用Spring Boot用Java编写的简单服务，Spring Boot是BlaBlaCar服务广泛使用的框架。 为了快速证明这一概念，我们在生产中使用RocksDB部署了一个重复数据删除器实例，该实例是嵌入式键值存储，只需要在代码中声明该库，而无需构建单独的容器映像。 验证概念之后，我们注意到RocksDB不适合我们的情况：
- 重复数据删除器需要将数据持久保存在本地，这意味着实例必须在更新或重新启动时部署在同一台计算机上，而BlaBlaCar后端已完全容器化。
- 主题分配与重复数据删除器实例紧密相关，因为在不同计算机上运行的实例不共享其物理存储。 我们需要对主题进行细分，以确保相同的实例始终使用相同的主题。 如果实例死亡，相关主题将不再被消耗。 这违反了我们的高可用性意图。
Redis似乎是一个不错的候选人，但不是明智的选择。 CDC堆栈会产生大量流量，并将其存储在内存中，意味着具有较短的TTL（生存时间）以进行重复数据删除。 TTL与单个Debezium连接器的最大停机时间有关。 我们的目标大约是2天，这代表了超过100 GB的数据，并且需要一个庞大的Redis集群。
我们最终决定使用Cassandra来实现其高可用性，高性能，存储海量数据的能力以及对TTL的原生支持。 请注意，重复数据删除器在存储中的写入和读取速度非常快，为避免重复数据删除失败，要求Cassandra中具有强一致性级别（LOCAL_QUORUM级别）。 这听起来可能对性能不利，但事实证明在生产上是可以接受的。
与RocksDB不同，Cassandra可以被视为中央键值存储，而去重复器则不需要实现特定的主题分配逻辑。 如果一个重复数据删除器实例失败，则主题将重新平衡并自动重新分配给其他活动实例。
一次
重复数据消除器实现消耗过程产生模式。 从版本0.11.x开始，kafka支持使用事务的一次精确语义。 使用者仅在成功处理记录后才提交偏移量。
重复数据删除器的输出会产生一个CDC流，该CDC流可保证一次语义和消息顺序。
