一、业务背景
数据同步，就是让数据通过一定的传输介质，从一个地点到达另一个地点，从而实现数据的同步或复制，来满足应用需求。在本人的上一份工作中，随着业务量及数据量的的大幅增长，公司不得不对现有的微服务再度细化（拆分）。公司采用的是基于领域驱动设计的微服务体系，每个领域在需求日益增加的同时，必然会愈来愈大，考虑到业务内聚、系统性能等诸多因素不得不把某些大的领域中心拆分成多个服务。这个过程就是系统重构。
系统拆分如何让用户无感知呢？上线时通过分流策略将部分用户引流到新的服务中，要求新老系统并行运行一段时间来支撑新服务的试运行到完全落地，从而最大化减小生产故障。为了让新服务数据能够与旧系统服务中的数据实时一致，就需要同步数据。随着数据量大幅增长，要加快查询速度，可以将数据复制到 ES（ElasticSearch）中，提高查询速率。
综上总结：如何实现增量数据实时同步？
二、业务选型
市场上有相关的开源数据同步产品和商业版数据通道工具，不需要人工任何接入即可实现双边的数据同步复制。但在系统重构时时可能会发生一些表结构的变动以及表对象的一些变动，此时就无法兼容商业的数据同步，当然也可以采纳其中的部分解决方案但还是需要开发人员介入进行相关处理，所以最终，我们采用了 Maxwell + Pulsar 的自研解决方案：使用 Maxwell 读取 binlog（也可以使用 canal ，maxwell实现较简单点），Pulsar 进行数据传输。Maxwell + Pulsar 实现上层的数据读取，下游业务方实现对应的数据同步逻辑。比如，针对系统重构拆分的数据同步业务场景，以及读写分离，将数据复制同步到类似 ElasticSearch 搜索引擎中的业务场景。
三、为何会选择Pulsar?
无状态
微服务架构体系中，对于一些中间件的当然是无状态的最好。启动快，可以随时替换并且可以实现无缝的伸缩，弹性扩展。就拿同等量级的 Kafka 来说吧，它并不是无状态的，每个 Broker 都包含了分区所有的日志，如若一个 Broker 宕机，并非任意一个 Broker 可以来接管，也不能随意添加 Broker 来分担，Broker 之间必须进行状态同步。但Pulsar 架构中，数据是从 Broker 剥离的，存储在共享储存内部；上层是无状态 Broker ，复制消息分发和服务（计算），下层则是持久化的存储层（ Bookie ）。所以数据计算和存储相互独立，可以实现数据的独立扩展和快速恢复。既支持流式处理也具备传统的消息队列
弹性扩展，良好的云原生支持，且支持跨地域复制
支持分区
高吞吐、低延时
开源社区活跃，良好的技术支持
四、数据同步数据链路模型（部分）
该图主要展示核心的数据链路，隐藏日志记录、链路追踪等一些微服务体系中所含有的组件。
五、Pulsar 在分布式消费过程中如何保证顺序
Pulsar 有四种消费模式：exclusive 模式（独占模式）、failover 模式 （故障转移模式）、Shared 模式 （共享模式）以及 Key_Shared 模式。
Exclusive 模式只有一个 Consumer，接收一个 Topic 所有的消息。
Failover 模式，同一时刻只有一个有效的 Consumer，其余的 Consumer 作为备用节点，在Master Consumer 不可用后进行替代（该模式适用于数据量小，且解决单点故障的场景）。
起初我们采用 Shared 消费模式，因为其有着良好的分布式消费能力，消费速度快。Shared 模式的优点在于随机消费，在共享或循环模式下，多个 client 可以连接到同一订阅主题。消息以轮询的方式分布在各个 client 之间，任何给定的消息仅传递给一个 client。但在生产过程中发现源数据库数据与同步的目标库（ES、MySQL）频繁出现数据偏差和数据不一致的问题。经排查发现，问题出现在消费顺序错乱，当用户频繁操作某条数据产生了多条 MQ 消息时，Shared 模式下分布式的并行消费了。
经查阅官网，Pulsar 在 2.4.0 版本基于 Shared 模式下推出了 Key_Shared 模式。在 Key_Shared 模式下，多个消费者可以附加到同一订阅。消息在各个使用者之间进行分发，并且具有相同密钥或相同订购密钥的消息仅投递给一位消费者，且不管消息重新发送多少次，它都会被发送到同一使用者。当消费者连接或断开连接时，服务的消费者会更改某些消息 Key（密匙）。Key_Shared 模式保证在 Shared 模式下同一个 Key 的消息会发送到同一个 Consumer，在并发的同时保证了顺序性。
顺序问题是分布式消费过程中常见的问题，Pulsar 如何保证客户端的有序消费呢？数据同步场景对消息的顺序要求非常高。例如，当用户不断更新某条数据时，数据库表中对应的记录也在不断更新。数据量大高并发时，需要保证用户变更数据产生的消息顺序与其操作顺序一致，否则会出现同步的该条数据与源数据不一致，产生系统故障。
★ 分布式场景下利用 Pulsar 如何实现顺序消费 ？
① 采用 Key_Shared 订阅模式
Key_Shared 模式是 shared 订阅模式拓展，一个分区可以有几个消费者并行消费消息，但具有相同 key 的消息只会路由给一个消费者。其原理则是通过哈希来确定目标的使用者。每个消费端提供固定范围的哈希值，当然散列值的整个范围可以覆盖所有的消费端。
② 生产消息时指定 key，形成闭环。具体原理及用法可以参考 Pulsar 官网 。
经上所述，对于数据同步的场景，我们将key指定为下面的示例，就可以实现有序的存放至指定的分区以及消息有序的消费啦！
key ：{"database":"you_db_name","table":"you_table_name","pk.id":"you_table_Primary key"}
六、为何会产生重复消息?
消息的传输保障一般有三种：At least once、At most once 和 Exactly once。
At least once：每条消息会进行多次传输尝试，至少成功一次，即消息可能重复但不会丢失;
At most once：每条消息最多传输一次，消息可能会丢失；
Exactly once：每条消息只传输一次，消息传输既不会丢失也不会重复。
在数据同步场景下，要最大化的保证消息的可达性，可以运用 Maxwell 的 At least once 模式，尽可能保证消息传输。在网络不理想时，消息可能已经投递至目标，但接收到超时响应或者未接收成功，Pulsar 会再次投递，从而产生了我们认为的“重复消息”。
任何事物都是有双面性的，所以针对于这点，见上文四给出的数据链路图不难发现有个过滤器，设置其目的如此，过滤一些重复、无效的消息，当然也有可能是重试的消息，所以此时在实现过滤器时需要考虑到适合自身业务的各种场景，指定完善的过滤逻辑，以择之。
