scrollAPI：适合一次性获取大量数据，尤其是需要处理所有数据的场景。：适合分页查询大数据量，性能较好。：不推荐用于大数据量查询，可能会导致性能问题。slice：适合并行查询大数据量。根据你的具体需求选择合适的查询方式。

fromsize：适用于小规模分页查询，但对大数据集分页查询效率差，性能会随着查询深度增加而下降。：非常适合大数据集的分页查询，通过游标优化了查询的效率，避免了深度分页的性能问题。滚动查询（Scroll）：适用于批量数据导出或长期处理数据，能够保持查询上下文，但占用资源较多，通常不用于交互式查询。

数据通过 Canal 同步到 Elasticsearch 时，延迟问题可能涉及多个方面：Canal 配置、网络性能、ES 配置、硬件瓶颈等。通过优化 Canal 配置、提高 Elasticsearch 性能、减少网络延迟、增加并发处理等方式，可以有效降低延迟问题，确保数据同步的实时性。通过实时监控和优化，不断调整配置，能够进一步提升系统的性能和可靠性。

节点数量：在生产环境中，至少有 3 个节点。分片数量：默认 5 个分片，根据数据量和查询吞吐量来调整，一般设置为 1-10 个分片。副本数量：默认每个主分片有 1 个副本，增加副本提高容错性和查询性能。这些设置需要根据具体的应用场景、数据量和查询需求来调整。

中写入一条数据的请求流程涉及多个步骤，包括客户端请求、节点处理、数据分片和副本同步等。往 Elasticsearch 中写入数据的流程涉及客户端请求、协调节点路由、主分片写入和副本分片同步。客户端 -> 协调节点 -> 主分片 -> 副本分片 -> 主分片 -> 协调节点 -> 客户端。主分片所在的节点接收到请求后，将数据写入本地存储（如 Lucene 索引）。主分片收到所有副本分片的确认后，向协

appname: order-sync-executor// 错误地使用了相同的执行器名称。appname: order-sync-executor// 应用A的执行器名称。appname: order-sync-executor// 专门处理订单同步。执行器地址: http://order-executor/// 服务名而非负载均衡地址。执行器地址: http://xxl-job-executo

特性KafkaRocketMQRabbitMQ顺序性保证分区内有序，分区间无序队列内有序，队列间无序默认不保证顺序全局顺序消费单分区主题或按 Key 分区单队列主题或按 Key 选择队列单队列单消费者或消息分组并行处理能力高（多分区）高（多队列）低（单队列单消费者）实现复杂度中等中等高（需要外部排序或分组）适用场景高吞吐量、分区顺序消费高吞吐量、队列顺序消费低吞吐量、简单顺序消费Kafka和Roc

订单中心接收MQ下发出库信息（中台接收云POS的出库信息BMS125，写到库存移动单据表）

就是除数据同步，主备之间还要有个状态传输过程，来让备机只要现在主机过得好不好，可以是主机主动推送它的状态给备机，或者是备机去索要状态。②主从延迟，读操作分配给从库，就会存在数据同步的延迟问题，比如某个人注册了账号之后，登录走的是从机，这时候数据还未从主机同步过来，那可不让人很难受了。主机的意思当然是以它为主了，读写都是主机上，而备机呢就是备用，默默的在背后吸收主机的数据，在主机还活着的情况下，备机

需求：平时在做增删改查时，创建人，创建时间，更新人，更新时间，版本号这些字段是都有的，每次都写很麻烦，现在可以通过配置就可以不用管这些字段，写入表时这些字段自动填充。jar依赖gradlecompile 'com.baomidou:mybatis-plus-boot-starter:3.1.1'maven<dependency><groupId&...