難易度：完全同期と増分同期には、連絡先の調整の問題があります。
解決策：インクリメンタル同期が最初に開始され（変更されたデータはKafkaにミラーリングされますが、コンシューマースレッドはデータをプルしません）、次に完全同期（クエリデータが特定のしきい値未満の場合、SQLクエリを介した直接データ同期）が考慮されます完全な同期が終了すると、コンシューマスレッドは、メッセージキューからデータをプルして、増分同期を開始するように求められます。このように、増分同期と完全同期は接続セグメントで重複しますが、データの同期はミラーリングされ、べき等に準拠するため、データの最終的な整合性を実現できます。
すべての同期タスクを管理する最初のスレッドプール
core size: 10
max size:100
存活时间：10ms
阻塞队列：LinkedBlockingQueue,容量为50
拒绝策略:拒绝策略为抛出异常
线程工厂：实现了ThreadFactory接口，为线程个性化命名，方便排除bug
データ消費スレッドを管理する2番目のスレッドプール
core size: 0
max size:50
存活时间：0
阻塞队列：LinkedBlockingQueue,容量为0,这个无所谓但是容量要为0
拒绝策略:拒绝策略为抛出异常
线程工厂：实现了ThreadFactory接口，为线程个性化命名，方便排除bug
完全同期
建立搜索模型，进行全量同步，记录当前同步的id，当捞出的数据量小于
一个阈值，全量同步结束，同时通知对应的搜索模型可以发给消息队列数据
増分同期
一个topic 多个partition
模型id作为key存入partition,一个消费者对应一个partition，主动拉
取数据并进行消费。
问题：为什么不采取一个线程进行数据拉取，将数据存入共享队列中，多个线程共同消费队列中的数据方案？上述方案可能会发生消费者线程不断空拉取数据的清形，浪费性能，问如何解决？
答案：1.这种方案不好控制数据最终落库的顺序，解决方法可能较为复
杂。2. 可以模拟指数回退方法
問題：
- 水平方向の拡張をサポートする方法は？メッセージの順序を確認するにはどうすればよいですか？
Partitionerインターフェイスをカスタマイズし、モデルIDの間隔に従ってメッセージをパーティションに配布します。 - データ消費スレッドを動的に削除/増加させる方法は？
スレッドの削除：スレッド終了メソッド、揮発性+ループ検出（スレッドプール設定コア== 0のため）
スレッドの追加：スレッドをスレッドプールにスローします
。さらに、各スレッドに対応するモデルID間隔を再調整する必要があります。調整、一時停止コンシューマースレッドによる（共有変数を介した）データ配布のプロセスは、調整を待機し、元のデータがすべて消費された後にプロセスを再開します。
1つのコンシューマーの複数のパーティションは、メッセージ消費の順序を保証できません