java岗位面试突击冲刺

java岗位面试突击冲刺

MySQL与mongodb和oracle的区别都有哪些

区别:
数据模型：
MySQL和Oracle使用关系型数据模型，数据以表格的形式组织，表之间建立关系。
MongoDB使用文档型数据模型，数据以类似JSON的文档形式存储，没有预定义的模式，可以存储各种类型的数据。
数据语言：
MySQL和Oracle使用结构化查询语言(SQL)来管理和查询数据。
MongoDB使用查询语言(Query Language)来进行数据查询和操作。
数据一致性：
MySQL和Oracle保证数据的一致性，支持事务处理，并且具有强一致性。
MongoDB默认情况下，是最终一致性的，在分布式环境下可能存在一定程的数据不一致，但可以通过配置来实现强一致性。
数据拓展性：
MySQL和Oracle支垂直扩展（通过增加硬件资源提高性能）和水平扩展（通过分片实现数据分布和负载均衡）。
MongoDB主要通过水平扩展来实现高性能，支持分片集群和数据分片。
数据安全性：
MySQL和Oracle提供访问控制、用户认证数据加密等安全功能来保护数据安全。
MongoDB也提供类似的安全机制，如用户认证、角色管理和加密传输等。
存储引擎：
MySQL支持多种存储引擎，包括InnoDB、MyISAM等，每存储引擎有不同的特点适用场景。
Oracle有自己的专有存储引擎。
总的来说，MySQL和Oracle更适用于传统的关系型应用，适用于企业级应用和大规模数据处理。而MongoDB则更适用于大数据处理、实时数据分析和弹性的数据模型需求

用户在下订单时异步处理如何保证数据的一致性

事务（Transaction）：使用数据库事务来确保数据的一致性。在下订单的过程中，将相关的数据库操作封装在一个事务中，只有在所有的操作都成功完成后，才将事务提交，否则将事务回滚。这样可以避免订单过程中出现数据不一致的情况。
消息队列（Message Queue）：使用消息队列来将订单信息发送到一个消息队列中，然后由异步的消费者来处理订单。在订单消息被消费前，订单数据并不会立即写入数据库，而是暂存在消息队列中。这样可以避免因为某些原因导致订单操作失败，保证了数据一致性。
事件驱动（Event-driven）：通过事件驱动的方式来处理订单。当用户下订单时，触发一个订单事件，然后由异步处理器来处理该事件。异步处理器可以进行各种操作，如创建订单、支付订单、更新库存等。这样可以将订单处理过程解耦，保证了系统的可扩展性和数据一致性。
重试机制：当异步处理发生错误或失败时，可以通过重试机来保证数据的一致性。例如，在订单处理过程中，如果出现错误，可以进行重试，直到操作成功为止。重试机制可以通过指数退避、限制重试次数等方式设置，确保系统可以自处理出现的错误并复到一致状态。
总之，异步处理下订单时需要考虑数据一致性的问题，通过事务、消息队列、事件驱动和重试机等方法，可以有效地保证数据的一致性，并确保订单处理过程的可靠性。

elasticsearch在项目中的具体运用，为什么他的查询速度比较快

实时数据搜索：Elasticsearch适用于需要实时搜索大量数据的场景。例如电商网站的商品搜索、新闻网站的文章搜索等。通过将数据索引到Elasticsearch中，可以实现高效的文搜索、关键词匹配等功能。

日志和事件处理：Elasticsearch可用于处理大规模的日志和事件数据。通过将日志数据存储在Elasticsearch中，可以使用强大的搜索和聚合功能，快速检索和分析特定的日志记录，提供实时的监控和分析。

地理位置搜索：Elasticsearch支持地理位置搜索，可以存储和搜索地理位置数据。这在地图应用、位置服务等方面非常有用，可以快速找到特定区域内的数据。

大规模数据分析：Elasticsearch与Kibana等工具的结合，可以进行大规模数据分析，探索数据的模式和趋势，并生成可视化图表和报告。

至于为何Elasticsearch具有较快的查询速度，有以下几点原因：

倒排索引（Inverted Index）：Elasticsearch使用倒排索引来加速搜索。倒排索引是一种将文档中的每个词映射到它出现的文档的数据结构通过这种索引方式，可以快速定位到包含关键词的文档。

分布式架构：Elasticsearch是基于分布式架构设计的，可以将数据分片存储在多个节点上。这种分片和复制机制可以提高数据的存储和查询效率，并且具备高可用性和容错性。

基于Lucene引擎：Elasticsearch基于Apache Lucene搜索引擎开发，借助Lucene的强大功能，如布尔查询、范围查询、模糊查询等，可以高效地执行各种查询操作。

内存缓存：Elasticsearch使用内存缓存来加速查询响应。它会将频繁查询的数据加载到内存中，减少了磁盘IO的开销，提升了查询性能。

综上所述，Elasticsearch在项目中应用广泛，能够快速地处理实时搜索、日志分析、地理位置搜索和大规模数据分析等场景。其快速查询的原因主要包括倒排索引、分布式架构、Lucene引擎和内存缓存机制的优化。

什么是倒排索引？
倒排索引（Inverted Index）是一种常用的数据结构，主要用于加快文本搜索的速度。它是一种将文本中的每个词映射到包含该词的文档的数据结构。
相对于传统的正向索引（Forward Index）存储方式，倒排索引将词作为索引的关键字，而文档作为索引的值。具体来说，倒排索引由两个部分组成：
词典（Dictionary）：词典是由文本中所有出现过的词构成的有序列表。每个词都会有一个唯一的标识符（Term ID）。
倒排列表（Inverted List）：倒排列表存储了每个词出现的文档列表，以及该词在每个文档中的位置信息。倒排列表可以通过词的标识符在词典中进行查找。
举个例子来说明，假设有三个文档A、B、C，它们的内容如下：
文档A：This is a document.
文档B：The document is important.
文档C：This document is about Elasticsearch.
使用倒排索引来存储这些文档，可能会得到如下的倒排列表：
词典：
This
is
a
document
The
important
about
Elasticsearch
倒排列表：
This：A(1), C(1)
is：A(2), B(2), C(3)
a：A(3)
document：A(4), B(4), C(2, 4)
The：B(1)
important：B(3)
about：C(5)
Elasticsearch：C(6)

通过倒排索引，我们可以方便地找到包含特定词的文档，并快速定位到词在文档中的位置。倒排索引的使用可以大大加速文本搜索的速度，特别是在大规模文本集上，因为它可以减少需要搜索的文档数量。

总之，倒排索引是一种通过将词映射到包含该词的文档的数据结构，用于高效地进行文本搜索。它的主要组成部分是词典和倒排列表，通过倒排索引可以快速定位到包含特定词的文档。


Elasticsearch使用一种称为倒排索引的数据结构来存储数据。

倒排索引是通过将词语映射到包含该词的文档来组织数据的索引结构，主要由两个部分组成：

倒排列表（Inverted List）：对于每个出现的词语，都会构建一个倒排列表。倒排列表包含了该词语出现的文档列表以及词语在每个文档中的位置信息。

文档词典（Document Lexicon）：文档词典是存储文档信息的数据结构，用于维护每个文档的元数据，如文档ID、文档的一些属性等。

当数据被索引时，Elasticsearch会对文本进行分词处理，将文本拆分成单个的词语，并为每个词语构建相应的倒排列表。倒排列表中存储了词语出现的文档列表，以及词语在每个文档中的位置信息。

倒排索引具有以下特点：

快速定位：倒排索引通过将词语映射到包含该词的文档，可以快速定位到具有匹配关键词的文档。

高效搜索：倒排索引结构使得搜索时只需遍历相关文档，而不是整个文档集合，因此搜索效率高。

索引更新：倒排索引支持文档的增删改操作，当文档被更新或删除时，相应的倒排列表也会进行相应的更新。

Elasticsearch将这些倒排列表存储在分片（Shards）中，每个分片都是一个独立的索引单元，可以被分布在不同的节点上进行存储和处理。这种分布式的存储和处理方式使得Elastic具备了横向扩展和高可用性的能力。

总结而言，Elasticsearch使用倒排索引来存储数据，倒排索引通过将词语映射到包含该词的文档，实现了高效的搜索和快速的定位功能。这种索引结构在大规模的数据存储和处理场景中具备很高的性能和可扩展性。

redis持久化方式有哪些

Redis支持两种主要的持久化方式：RDB（Redis Database）和AOF（Append-Only File）。

RDB持久化：
RDB是Redis默认的持久化方式，它的原理是将当前内存中的数据快照(snapshot)保存到硬盘上的一个二进制文件中。RDB持久化具有以下特点：

手动或自动触发：可以手动执行SAVE或BGSAVE命令，也可以配置自动触发的条件，如设置时间间隔等。
高效：RDB持化是通过fork子进实现的，操作系统复制一个与父进程相同的内存副本，将快照数据入磁盘，因此对主进程影响较小。
数据恢复速度较快：由于RDB是通过快照保存数据的方式，当需要恢复数据时，直接加载快照文件即可。
AOF持久化：
AOF持久化将Redis服务器接到的每个写操作追加到一个文件中（Append-Only File），以保证数据的持久性。AOF持化的特点如下：

追加方式：将每个写操作以追加的方式写入AOF文件，因此文件会随着操作不断增长。
可读性强：AOF文件是文本文件，可以查看和编辑。
恢复速度较慢由于AOF文件中包含了所有写操作记录，恢复数据时需要逐条执行这些操作，因此恢速度相对较慢。
提供多种同步机制：可以配置AOF的同步方式，包括每个写操作都同步到磁盘（always）、每秒同步一次（每秒一次fsync）或者操作系统自行决定。
此外，Redis还支持RDB和AOF的混合使用，可以同时开启两种持久化方式，以提供更高的数据安全性和可恢复性。

需要注意的是，持久化机制只是Redis中的一种数据保护方式。在生产环境中，为了提高数据安全性，建议将持久化机制与Redis的主从复制结合使用，以实现数据的备份和高可用性

在项目中用到的数据库里的表是怎么设计的

概念清晰化：要先明确项目的业务需求和数据模型，理解实体及其关系，从而决定数据库表的概念和结构。
表的范式化：根据数据库的范式化理论（如第一范式、第二范式、第三范式），将数据按逻辑上的关系分解为多个表，以避免数据冗余和数据更新异常。
主键和外键：确定每个表的主键，以唯一标识该表中的每一行数据。同时，根据表与表之间的关系，使用外键来建立表与表之间的连接。
数据类型选择：选择适当的数据类型来存储数据，以节省存储空间和提高查询效率。
索引设计：根据具体的查询需求和数据访问模式，设计适当的索引以提高查询性能。
规范命名：为了提高代码的可读性和维护性，对表和列使用有意义的命名，遵循一定的命名规范。
数据的一致性和完整性：通过在表上定义约束（如唯一性约束、非空约束、外键约束等），确保数据的一致性和完整性。
性能优化：在数据库表设计中考虑性能优化，如适当的分表、分库策略，以及对频繁查询的表进行冗余设计等。

怎么分库分表

分库分表的基本思想是将数据按照一定规则分散存储到多个数据库实例或表中，以减轻单一数据库实例或表的负载压力。下面介绍一种常见的分库分表策略——基于哈希分片的分库分表方法：

分库：将数据根据某种规则（如哈希函数）分散存储到不同的数据库实例中。分库的目的是将数据分散到多个数据库中，充分利用数据库的并发处理能力。可以根据业务需求和数据访问模式，选择合适的分库规则，例如根据用户ID、订单ID等进行哈希分片。

分表：将单个表中的数据按照一定规则（如哈希函数、ID范围等）划分到多个表中。分表的目的是将单一表中的数据分散到多个表中，以提高查询性能和写入吞吐量。可以根据具体的业务需求，选择合适的分表规则，例如按照时间范围、地理位置、用户ID等进行分表。

基于哈希分片的分库分表方法的工作原理如下：
根据分库分表的规则，确定数据要存储在哪个库中，以及在库中的哪个表中。
在应用程序中，根据规则生成对应的数据库或表的连接信息，并根据数据的访问需求进行读写操作。
在查询数据时，根据分库分表的规则，从不同的库或表中查询数据，并将结果聚合返回给应用程序。
在写入数据时，根据分库分表的规则，将数据写入到相应的库或表中。
在实际的项目中，需要考虑诸多因素如数据量、查询频率、数据访问模式等来选择适合的分库分表策略，并在实施过程中保证数据的一致性和可用性。对于百万级别的数据，可以合理划分数据的划分粒度和规则，以达到更好的性能和可扩展性。此外，还需要注意分库分表带来的数据迁移、数据同步、跨库事务等技术挑战，保证整个分片系统的稳定和可靠性。

在实践中，常见的分库分表方式主要有垂直分库分表和水平分库分表两种方式。
垂直分库分表：
垂直分库：按照业务功能将不同的表拆分到不同的库中。如将用户相关表、订单相关表等拆分到不同的库中。垂直分库常用于解决单个数据库的性能瓶颈，降低数据库的负载压力。
垂直分表：按照表中字段的关系和访问模式，将一个大表拆分成多个小表。如将用户信息表中的基本信息、登录信息、个人设置等字段分散到不同的表中，以减少单表的数据量和提高查询性能。
水平分库分表：
水平分库：按照某个规则将数据划分到多个数据库中。如将用户数据根据用户ID的哈希值分散存储到不同的数据库中。水平分库常用于解决数据库容量和吞吐量的问题，提高并发访问能力。
水平分表：按照某个规则将数据划分到多个表中。如将订单数据根据订单号的哈希值分散存储到不同的表中。水平分表常用于解决单表数据量过大导致的查询性能下降和写入压力增加的问题。

在实际开发过程中用到的技术是由你决定的还是统一决定的

技术的选择是由开发团队来决定的。具体的技术选择、开发流程、工具使用等都是由开发团队根据项目需求和实际情况来制定的。开发团队会根据项目的目标、预算、人力资源等因素综合考虑，并选择适合的技术和工具进行开发。
前端
1.使用RN（React和React Native）
2.前端项目通过dubbo+nginx+react native实现
后端
1.技术选型Java技术进行
a.基础的语法是必须的
2.数据库采用MySQL
a.数据库的SQL语法是必须的
b.存储过程
c.定时任务执行
3.框架使用SpringBoot作为基础框架
a.项目使用三套环境开发服，测试服，生产服
b.在实体类上采用lombok依赖提高开发效率，减少getter/setter及构造函数编写
4.在框架基础上使用JPA与MySQL进行数据库的交互操作，当然其他项目也使用Mybatis来与数据库进行交互，两种交互方式在业务场景不同时各有千秋
5.通过redis来实现缓存
6.通过dubbo来实现服务的提供与消费
a.各中心以提供者与消费者方式实现
b.提供者为其他中心以dubbo方式提供服务
c.消费者调用dubbo提供者以web服务形式提供接口给前端使用
7.消息中间件使用RabbitMQ
8.通过Docker生成镜像后，推到阿里云镜像仓库
9.使用linux服务器,centos
10.通过shell脚本实现本地镜像打包并推送到私有镜像仓库
11.业务上使用jwt生成token
12.dubbo注册服务到zookeeper，使用zookeeper服务
a.本地zookeeper服务，通过docker镜像实现
b.测试服zookeeper服务，通过安装zookeeper来提供服务
c.生产服务器使用镜像实现
13.接口文件以swagger2形式展示，接口支持http及https

rabbitmq在项目中的实际用途有哪些

RabbitMQ是一个开源的消息代理软件，它实现了高级消息队列协议（AMQP）并提供了可靠的消息传递机制。在项目中，RabbitMQ可以用于以下几个方面：

异步任务处理：通过将任务发送到RabbitMQ的消息队列中，可以实现异步任务的处理。例如，在一个Web应用中，可以将耗时较长的任务（如邮件发送、图像处理等）放入队列中，在后台进行处理，提高系统的响应速度和并发能力。

解耦系统组件：在一个分布式系统中，不同的组件之间可能存在耦合关系。通过使用RabbitMQ，可以将消息发送到消息队列中，各个组件可以异步地接收和处理消息，减少组件之间的直接依赖关系，提高系统的灵活性和可扩展性。

数据同步：在多个系统之间需要进行数据同步的场景下，可以使用RabbitMQ来实现数据的异步传输和同步。例如，在微服务架构中，可以使用消息队列来进行不同服务之间的数据同步，从而实现系统之间的解耦和数据的一致性。

日志收集与分发：通过将日志消息发送到RabbitMQ中的消息队列，可以收集和聚合不同系统的日志信息，并根据需要将日志分发到不同的消费者进行处理或存储。
事件驱动架构：RabbitMQ可以作为事件驱动架构的核心组件，用于发布和订阅事件。系统中的不同模块可以根据订阅的事件类型来响应和处理相关事件，实现高度解耦的系统架构。

超时未支付除了使用mq中的延时队列解决还有什么方法能解决

除了使用消息队列中的延时队列来解决超时未支付的问题外，还可以考虑以下几种方法：

定时任务：可以使用定时任务来检查订单的支付状态，并在一定时间内未支付的订单进行处理。例如，可以使用定时任务框架如Quartz或Celery来定期检查订单的支付状态，一旦超时未支付，则触发相关的操作，如取消订单或发送提醒消息。

缓存和定时失效：将订单信息存储在缓存中，并设置相应的过期。在用户提交订单后，记录订单的创建时间和过期时间，定期扫描缓存中的订单，将超过过期时间还没有支付的订单进行处理。

Webhook回调机制：在用户提交订单的同时生成一个唯一的支付链接，并设定支付超时时间。当用户支付时，通过Webhook调机制接收支付结果通知，如果超过支付超时时间还未收到通知，则视为超时未支付。

前端定时器：在前端页面中使用JavaScript定时器来检查订单的支付状态。在用户提交订单后，启动一个定时器，在一定时间内未支付的订单触发相应的操作，如取消订单或提示用户支付。

Mysq分库分表如果让你 设计怎么设计

设计 MySQL 的分库分表方案需要考虑多个因素，包括数据量、负载均衡、维护成本等。下面是一个基本的分库分表设计方案：

分库：按照业务逻辑将数据分散存储多个数据库中，每个数据库独立运行。可以按照以下几种方式进行库：

按照数据的业务进行分库，例如订单、用户、商品等独立分库。
按照数据的地理位置进行分库，例如按照不同地区或不同城市进行分库。
按照数据量进行分库，例如按照逻辑上的数据范围进行分库。
在分库同时，需要考虑跨库查询、事务处理和同步等问题。

分表：将每个数据库中的表按照某个规则进行分割存储，使得每个表只包含部分数据。可以按照以下几种方式进行分表：

按照数据的时间进行分表，例如每个月或每年一个。
按照数据的某个字段进行分表，例如按照用户ID或商品ID分表。
按照数据量进行分表，按照表的大小分表。
在分表的同时，需要考虑跨表查询、数据迁移数据维护等问题。

使用分布式数据库中间件：为了方便管理和操作分库分表的，可以使用分布式数据库中件，如MySQL Proxy、MyCat、TDDL等。些中间件可以隐藏分库分表的细节，提供统一的数据库接口负责路由、负载均衡和故障切换等操作。

Oom是什么

"OOM"是内存溢出（Out of Memory）的缩写。它是指在计算机程序运行时，申请的内存超过了系统的可用内存资源，导致程序无法继续正常运行的情况。

当程序需要申请大量的内存来存储数据或执行操作时，如果系统的可用内存不足以满足这个需求，就会发生内存溢出。这可能导致程序异常终止、崩溃或出现错误信息。

内存溢出通常是由以下几种原因引起的：

内存泄漏：当程序中申请的内存空间没有被正确释放，导致内存占用不断增加，最终耗尽系统的可用内存。

内存申请过大：当程序需要大量的内存空间来存储数据或执行某些操作（如加载大型文件、处理大数据集），但系统的可用内存无法满足需求时，就会发生内存溢出。

程序设计问题：程序中存在设计缺陷或错误，导致内存使用不当，使内存占用过高，从而引发内存溢出。

为避免内存溢出问题，可以采取以下一些措施：

合理管理内存：在程序中及时释放不再使用的内存空间，避免内存泄漏。

控制内存申请：在程序设计中，合理估计内存需求，避免申请过大的内存空。

进行内存优化：优化算法和数据结构设计，减少内存占用。

使用内存管理工具和性能分析工具：使用内存管理工具定位内存泄漏问题，使用性能分析工具检测内存使用情况与性能瓶颈。

如果用户支付失败你是怎么做去判断这条订单是否成功，做了哪些操作

当用户的支付失败时，判断订单是否成功主要依赖于支付接口的返回结果和状态。以下是一般的操作步骤：

检查支付接口的返回结果：支付接口通常会返回一个支付结果的反馈信息，这可以是一个状态码、错误码、或者成功/失败的标识。

根据支付接口返回的结果判断支付是否成功：一般情况下，支付接口会提供特定的状态码或标识来表示支付成功或失败。你可以对这些状态码进行判断，例如成功的状态码为1或支付成功的标识为"success"等。

根据支付接口返回结果更新订单状态：如果支付成功，将订单状态更新为支付成功状态，并可以执行相应的后续操作，例如发送电子票、发货等。如果支付失败，可以将订单状态更新为支付失败状态，同时可能需要通知用户支付失败的信息。

记录支付失败的原因：如果支付失败，建议记录失败的原因，以便后续排查和处理。可能的原包括支付账户余额不足、支付密码错误、银行卡问题等。

发送通知给用户：根据支付结果，向用户发送相应的支付成功或失败的通知，以及可能的后续操作指引。

数据迁移权重是怎么设计的

数据重要性：根据数据的重要程度给予不同的权重。对于重要的数据，可以赋予更高的权重，以保证其在迁移过程中的完整性和准确性。

数据量和大小：考虑数据的大小和数量，对于大量且庞大的数据，可以给予更高的权重，以便优先迁。

业务影响度：评估数据迁移对业务的影响程度。对于影响较大的业务数据，可以赋予更高的权重，以确保其尽快迁移完成。

迁移时间窗口：考虑迁移时间窗口的限制和可用性要求对于需要在限定时间内完成迁移的数据，可以赋予更高的权重，以确保及时完成迁移。

数据关联性：考虑之间的关联性和依赖关系。对于相互关联的数据，可以根据其关联程度给予不同的权重，以确保相关数据能够一起被迁移。

迁移难度和复杂性：评估数据迁移的难度和复杂性。对于难度较大的数据迁移任务，可以给予更高的权重，以确保足够的资源和注意力用于解决这些难题。
--------------------------------------------------
提高迁移效率
大任务拆分为小任务
对外接口和单个商家的迁移设计好之后，下面就是考虑如何迁移全量数据的问题。迁移全量数据有什么问题呢？直接一个循环，把所有的商家都遍历一遍就好了。但是，商家数有70w之多。把全量数据一次性查出，要不数据库出问题，要不业务机器出问题。数据量太大了，所以需要考虑将大任务拆分为小任务。拆分方式很简单，将70w商家500一批的方式拆分为多个批次。一个批次执行完后执行下一个批次。因为商家的数据涉及到很多外部服务和网络消耗，迁移一个商家的数据大概需要3s。如果单线程执行任务的话，完成数据迁移任务需要583个小时。用脚后跟思考，这个耗时也是不可接受的。

多线程处理
所以，自然而然的想到使用多线程的方式来提高迁移效率。每500个商家作为一个任务提交给线程池处理，通过增加并发的方式，效率有一定的提升。但是毕竟数据量很大，单机很快也遇到了瓶颈。

分布式处理
所以，又很自然的想到通过水平扩展的方式来提高迁移效率。任务能够水平扩展的前提是任务可以被拆分为独立的子任务。刚好，在这个业务场景下可以将大人物拆分为一级子任务，一级子任务又可以再拆分为二级子任务分配给线程去处理。扩容后，手动将拆分后的子任务分配到不同的机器上。效率的问题得到解决。

遇到的问题
线程池参数配置错误

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-L5iPf2G9-1687961856025)(C:\Users\86188\AppData\Roaming\Typora\typora-user-images\image-20230628220129607.png)]

当把缓冲队列设置为无限队列时，最大线程数这个参数就是失效的，无论你设置多大。
数据库压力大
并发数上去后，后端数据库压力逐渐增大，cpu使用率居高不下。当cpu使用率急速上升时，大概率是慢sql导致的。果不其然，发现任务执行的sql为命中索引，导致全表扫描导致cpu资源被大量占用。慢sql问题通过创建索引的方式得到解决，创建索引是典型的通过空间换时间的行为，收益很高。

哪些可以改进
手动分配任务
在这个方案中，分布式和并行化的方式是通过自己手搓代码实现的。其实有更好的解决方案，这个任务完全可以通过schedulex的map-reduce任务来完成。框架已经完成了任务分发、并行处理、重试、reduce等功能，具有更佳的可靠性和水平扩展性。后续的任务应该采取更成熟的方案。

数据一致性的校验
数据迁移任务最重要的是要保证迁移前后的数据要一致。本次任务采取了抽样的方式来校验数据一致性，不够严谨。对于更敏感的数据，应该需要更可靠的数据校验任务来实现。

对于高并发可以做哪些优化

场景举例:京东双11主会场,上架了部分商品,这部分商品都是在会场开始上架的时候直接写入redis中的,当上架完成之后,通过异步消息写入到mysql中。面向c端的查询都是直接读redis,而不是数据库.而b端的查询,可以走数据库去查询。这部分流量不是很高,数据库绝对可以抵挡的住。

还是需要日志来记录程序的数据.但是在高流量的场景中,如果全量打印日志对于线上来说就是一种灾难,有以下缺点①严重占用磁盘,估算以下,如果接口的qps在20万左右,日志一秒就几千兆,一天下来就是上千GB ②大量的日志需要输出,占用了程序IO,增加了接口的RT(响应时间) 如果需要解决这个问题,①我们可以利用限流组件来实现一个基于限流的日志组件,令牌桶算法可以限制打印日志的流量,比如一秒只允许打印一条日志 ②基于白名单的日志打印,线上配置了白名单用户才可以打印出来,节省了大量了无效日志输出

在做线程池线程池的参数 怎么去设计

核心线程数（corePoolSize）：表示线程池中的常驻线程数量。根据系统的负载情况和并发需求，确定核心线程数的大小。通常需要根据系统的并发量、CPU核数和任务类型来进行调整。

最大线程数（maximumPoolSize）：表示线程池中允许存在的最大线程。根据系统负载、服务器资源和任务类型等因素进行调整。需要根据具体情况确定最大线程数的合理大小，避免线程数量过多导致系统资源耗尽。

空闲线程存活时间（keepAliveTime）：表示当线程池中的线程空闲一定时间后，会被销毁。根据任务类型和频率，设置合理的存活时间，避免长时间闲置的线程占用资源。

阻塞队列（BlockingQueue）：用于存放等待执行的任务。根据系统的特点和需求，选择适当的阻塞队列类型和容量。常见的阻塞队列有LinkedBlockingQueue、ArrayBlockingQueue等。

拒绝策略（RejectedExecutionHandler）：当线程池无法继续接收新任务时，决定如何处理新任务的策略。常见的拒绝策略有AbortPolicy、CallerRunsPolicy、DiscardPolicy等。

线程工厂（ThreadFactory）：用于创建新线程的工厂类，可自定义线程的创建方式，如命名、优先级等。

监控与调优：可以通过监控线程池的运行状态，包括线程数、任务列长度、拒绝的任务数等指标，来进行性能调优和问题排查。

设计线程池的参数需要综合考虑以下几个因素：

并发需求：根据系统的并发需求确定核心线程数（corePoolSize）和最大线程数（maximumPoolSize）。如果系统需要同时处理大量任务，则可以适当增加核心线程数和最大线程数。

资源限制：考虑服务器的资源限制，包括CPU核数、内存、带宽等，以避免线程数过多导致资源耗尽。合理设置线程池的最大线程数和合适的阻塞队列，以平衡并发能力与资源消耗之间的关系。

任务类型与执行时间：根据任务类型和执行时间长短，选择合适的阻塞队类型和容量。对于短时任务，可以选择无界队列（如LinkedBlockingQueue），对于长时任务或大量任务的情况，可以选择有界队列（如ArrayBlockingQueue）或自定义的队列。

响应时间需求：根据系统对响应时间的要求，设置适当的存活时间（keepAliveTime）。过长的存活时间可能导线程池中的线程长时间处于空闲状态，浪费资源；过短的存活时间则可能频繁创建和销毁线，造成额外的开销。

异常处理策略：根据系统的特点和需求选择合适的拒绝策略（RejectedExecutionHandler）。常见的拒绝策略有丢弃任务、抛出异常、调用线程自己执行等。需要考虑任务的重要性和业务场景，选择适当的处理方式。

程命名和设置线程优先级：使用自定义的线程工厂（ThreadFactory）来创建线程，并为线程设置有意义的名称和优先级，以便于系统监控和调优。

对于sql 优化你有什么见解

使用索引：合理创建和使用索引是提高SQL查询性能的重要手段。通过对经常用于查询的列创建索引，可以加快数据检索的速度。但需要注意避免创建过多或不必的索引，因为过多的索引可能会增加数据写入的成本。

减少查询返回的数据量：仅查询所需的列，避免使用SELECT *。避免一次性返回大量数据，可以使用分页查询或限制返回记录数。

优化查询语句：合理编写SQL语句，避免使用不必要的子查询、多层嵌套、重复的JOIN操作和复杂的条件表达式。可以使用EXPLAIN或其他查询分析工具来分析查询语句的执行计划，查找潜在的性能问题。

避免全表扫描：尽量通过索引来筛选数据，避免全扫描造成的性能问题。可以通过分析查询语句和表结构，优化索引或调整查询条件等方式来避免全表扫描。

合理拆分大查询：对于需要处理大量数据的查询，可以通过拆分成多个小查询来减少次查询的数据量。同时，可以考虑使用数据区和分布式数据库等技术来提高查询效率。

数据库结构优化：根据实际业务需求，合设计数据库表结构和关联关系，使得数据的存储和查询更加高效。避免设计过多的冗余字段、重复的数据和大量的空值。

定期进行数据库维护：定期进行数据库的优化与维护作，包括表的碎片整理、索引的重建、计信息的更新等。这样可以保持数据库的性能稳定，并且能够及时发现和解决潜在的问题。

：合理编写SQL语句，避免使用不必要的子查询、多层嵌套、重复的JOIN操作和复杂的条件表达式。可以使用EXPLAIN或其他查询分析工具来分析查询语句的执行计划，查找潜在的性能问题。

避免全表扫描：尽量通过索引来筛选数据，避免全扫描造成的性能问题。可以通过分析查询语句和表结构，优化索引或调整查询条件等方式来避免全表扫描。

合理拆分大查询：对于需要处理大量数据的查询，可以通过拆分成多个小查询来减少次查询的数据量。同时，可以考虑使用数据区和分布式数据库等技术来提高查询效率。

数据库结构优化：根据实际业务需求，合设计数据库表结构和关联关系，使得数据的存储和查询更加高效。避免设计过多的冗余字段、重复的数据和大量的空值。

定期进行数据库维护：定期进行数据库的优化与维护作，包括表的碎片整理、索引的重建、计信息的更新等。这样可以保持数据库的性能稳定，并且能够及时发现和解决潜在的问题。