多微信情况下，手机端登录微信，通过扫码登录电脑端微信后，切换手机微信，电脑端微信自动推出。如何让手机用微信A，电脑端用微信B。

一、扫码登录电脑微信

二、IOS手机打开飞行模式

三、在飞行模式下，退出微信
需要等待大概30秒，就会退出

四、退出登录后，联网直接登录另外账户即可

公司项目用的微服务架构

苦于每次需要手动改数据库表

然后我在想能不能集成一个数据库版本管理工具

调查选择flyway

因为项目是分布式的，每个服务有一个数据库

然后我的做法是创建一个共同的子工程来统一管理sql文件

然后再resources目录创建每个工程对应的文件夹

#前缀: V 代表版本变迁(Versioned Migrations), U 代表撤销变迁(Undo Migrations)， R 代表可重复变迁(Repeatable Migrations)
#版本号: 唯一的版本号，比如V1.0.1
#分隔符: __ (两个下划线)
#描述信息: 描述信息
#后缀: .sql
  flyway:
    # 是否开启flyway
    enabled: true
    encoding: utf-8
    # 是否禁用数据库清理
    clean-disabled: true
    # 若连接的数据库非空库，是否初始化
    # 当迁移时发现目标schema非空，而且带有没有元数据的表时，是否自动执行基准迁移，默认false.
    baseline-on-migrate: true
    # sql脚本文件名前缀，默认大写V
    sql-migration-prefix: V
    # sql脚本文件名称的分隔符，默认2个下划线__
    sql-migration-separator: __
    # 迁移sql脚本文件名称的后缀
    sql-migration-suffixes: .sql
    # metadata 版本控制信息表 默认 flyway_schema_history
    table: flyway_schema_history
    # 指定 baseline 的版本号,默认值为 1, 低于该版本号的 SQL 文件, migrate 时会被忽略
    baseline-version: 1

然后再每个服务的配置文件中写入

  flyway:
    # 默认存放sql脚本目录，默认为db/migration
    locations: classpath:db/migration/im

指定每个工程sql位置

即可。。。。

sql文件的命名规则如下：

前缀: V 代表版本变迁(Versioned Migrations), U 代表撤销变迁(Undo Migrations)， R 代表可重复变迁(Repeatable Migrations)

版本号: 唯一的版本号，比如V1.0.1

分隔符: __ (两个下划线)

描述信息: 描述信息

后缀: .sql

V1.0.0__create_user.sql

写了一个接口发现不能调用 一直在做尝试发现无果
偶然想起以前开始时用dubbo做注册中心传输数据时

实体类要序列化一下

浪费我三十分钟

实体类实现了implements Serializable后就可以了

。。。。。
。。。。
。。。。

Caused by: org.elasticsearch.ElasticsearchException: Elasticsearch exception [type=illegal_argument_exception, reason=Result window is too large, from + size must be less than or equal to: [5000] but was [321880]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting.]
    at org.elasticsearch.ElasticsearchException.innerFromXContent(ElasticsearchException.java:491) ~[elasticsearch-7.17.3.jar:7.17.3]
    at org.elasticsearch.ElasticsearchException.fromXContent(ElasticsearchException.java:402) ~[elasticsearch-7.17.3.jar:7.17.3]
    at org.elasticsearch.ElasticsearchException.innerFromXContent(ElasticsearchException.java:432) ~[elasticsearch-7.17.3.jar:7.17.3]
    ... 122 common frames omitted

这个异常意味着你的Elasticsearch查询尝试返回的结果数量超出了默认限制。默认情况下，Elasticsearch限制从一个搜索请求返回的文档数量为10,000。在你的情况下，你尝试返回了321,880个文档，因此触发了异常。

为了解决这个问题，你可以考虑以下几种方法：

使用滚动API：滚动API是一种更有效地处理大型数据集的方法。它允许你在多个请求之间维护一个持久的搜索上下文，并在不同的请求之间获取文档批次。这样可以避免从整个数据集中一次性获取大量文档。

调整索引级别的设置：你可以通过更改索引级别的设置来增加index.max_result_window的值，以允许更大的结果窗口。但是，这种方法可能会导致内存压力增加，因为Elasticsearch需要在内存中维护大量的搜索上下文。

优化查询：如果可能的话，尝试优化你的查询以减少返回的文档数量。你可以使用更精确的查询条件，或者利用Elasticsearch的聚合功能来汇总数据而不是一次性返回所有文档。

分页处理：如果你需要返回的文档数量仍然较大，你可以考虑分页处理结果。每次请求只返回一部分文档，并根据需要逐步获取更多的文档。

根据你的具体需求和系统配置，选择最合适的方法来解决这个问题。

调整索引级别的设置这个怎么设置
要调整索引级别的设置，你需要修改Elasticsearch中索引的参数。具体来说，你需要修改index.max_result_window参数，该参数定义了从一个搜索请求返回的最大文档数目。

你可以通过以下步骤来修改这个参数：

使用任何支持HTTP请求的工具（如curl、Postman等），向Elasticsearch发送HTTP请求。

发送一个PUT请求，指定要修改的索引名称，以及新的index.max_result_window的值。例如：

PUT /your_index_name/_settings
{
  "index.max_result_window": 50000
}

上面的示例将your_index_name索引的index.max_result_window参数值设置为50,000。你可以将该值设置为你认为合适的任何值，以满足你的需求。

发送请求后，Elasticsearch会返回一个确认响应，表示设置已经成功应用。

请注意，修改索引级别的设置可能会对系统性能产生影响，特别是当你增加了返回文档的数量时。确保在修改参数之前仔细评估系统的资源和性能需求。

处理百万级日志量的框架通常需要具备高效的日志收集、解析、存储和分析能力。以下是一些常用的Java框架和工具，可以帮助处理大规模的日志数据：

Apache Kafka：Kafka是一个分布式流处理平台，可用于高吞吐量的日志收集和传输。你可以使用Kafka作为日志的缓冲层，将日志发送到Kafka集群，然后进行后续的处理和存储。

Apache Spark：Spark是一个通用的分布式计算框架，提供了丰富的API和库，支持大规模数据的处理和分析。你可以使用Spark Streaming模块实时处理流式日志数据，或者使用Spark SQL模块进行批处理分析。

Apache Flink：Flink是另一个流处理框架，提供了低延迟、高吞吐量的流式计算能力。你可以使用Flink来处理实时日志数据，并且可以与其他存储系统集成，如Hadoop、Kafka等。

Elasticsearch：Elasticsearch是一个分布式搜索和分析引擎，特别适用于实时日志数据的存储和查询。你可以将日志数据索引到Elasticsearch中，然后使用Kibana等工具进行可视化和查询。

Logstash：Logstash是一个日志收集和处理工具，可以从多种来源收集日志数据，并且提供了丰富的过滤、转换和输出插件。你可以使用Logstash来收集、解析和转发日志数据。

Flume：Apache Flume是另一个日志收集工具，可用于将大量的日志数据从源端收集到目标端。Flume支持多种数据源和目的地，并且可以构建灵活的数据流拓扑。

以上框架和工具都有其独特的特点和适用场景，你可以根据项目需求和现有技术栈选择合适的工具组合来处理大规模的日志数据。