【面试】携程一面

一、自我介绍

二、用到的spring技术栈，有没有使用过springboot，springcloud，dubbo
微服务架构和SSM架构是两种不同的软件架构设计方法，它们在设计理念、应用范围和技术实现上存在一些区别。以下是具体分析：
1、设计理念： 微服务架构将功能分散到多个独立的服务中，每个服务围绕特定的业务能力构建，运行在其独立的进程中，并通过轻量级的通信机制（如HTTP RESTful API）进行交互。而SSM架构通常指的是单片应用程序架构，其中Spring用于依赖注入，SpringMVC用于web层，MyBatis用于持久层，整个系统作为一个单一的、整体的单元部署。
2、应用范围： 微服务架构适用于大型复杂系统，特别是那些需要高度可扩展性、灵活性和快速迭代的项目。它允许团队独立工作，通过更新、部署单个服务来改进整体应用，而不需要重新部署整个应用。相比之下，SSM架构更适合中小型项目，或者不需要频繁变更和维护的系统。
3、技术实现： 在微服务架构中，每个服务可以使用不同的技术栈和数据库，这为选择合适的技术解决特定问题提供了灵活性。而在SSM架构中，通常整个应用共享相同的技术栈和数据存储。
总的来说，微服务架构和SSM架构在设计理念等方面有所不同。**微服务架构提供了更高的模块化和独立性，使得系统更加灵活和可扩展，而SSM架构则适用于更简单、规模较小的应用开发。**在选择架构时，应根据项目的具体需求、团队能力和长期维护考虑来决定使用哪种架构风格。

三、接口TP99慢，从哪几个方面考虑优化？
优化接口的TP99性能指标，即提升最差99%情况下的接口响应时间，通常需要从多个角度来考虑和实施。以下是一些建议：
1、代码层面：
优化算法和数据结构： 检查处理逻辑是否存在效率低下的部分，使用更高效的算法和数据结构来改进。
减少不必要的计算： 分析接口调用过程中哪些计算是重复或不必要的，并进行移除或缓存结果以供后续使用。
异步处理： 对于耗时操作，如远程服务调用或数据库操作，可以采用异步处理方式，避免阻塞主线程。
2、数据库层面：
优化索引： 确保相关的数据库查询都已经加上合适的索引，且索引是生效的，必要时对已有索引进行重构。
调整查询语句： 优化SQL语句，减少不必要的数据加载和处理。
数据库分片： 如果单一数据库成为瓶颈，可以考虑数据库的水平拆分，通过分片分散负载。
3、系统层面：
增加硬件资源： 如果资源不足是导致响应慢的原因，可以考虑增加服务器的CPU、内存或者升级硬盘为SSD等。
负载均衡： 合理分配请求到不同的服务器，避免单点过载。
4、应用架构：
微服务拆分： 将大的复杂服务拆分成小的、专注的服务，可以独立部署和扩展。
限流策略： 针对高流量的接口采取限流措施，防止雪崩效应。
5、监控与分析：
实时监控： 对接口的性能进行实时监控，及时发现问题所在。
日志分析： 收集和分析接口的访问日志，找出性能瓶颈。
6、缓存机制：
本地缓存： 对频繁读取的数据使用本地缓存。
（扩展：MyBatis确实具有本地缓存机制，它包括一级缓存和二级缓存。
（1）一级缓存：也称为本地缓存，是MyBatis默认开启的缓存机制。一级缓存是在SqlSession层面实现的，这意味着在同一个SqlSession中执行相同的查询时，如果缓存中有数据，则直接从缓存中获取，而不会再次访问数据库。这种缓存机制适用于单机系统，可以减少对数据库的查询次数，从而提高系统性能。
（2）二级缓存：是全局性的缓存，可以跨多个SqlSession共享数据。与一级缓存不同，二级缓存需要手动在MyBatis的全局配置文件中进行配置才能启用。二级缓存适用于分布式环境，但需要注意，使用二级缓存可能会带来数据一致性问题，因此在某些情况下，可能需要扩展为分布式缓存解决方案。
总的来说，MyBatis通过一级缓存提供了本地缓存功能，这有助于提升应用程序的性能。而二级缓存则需要额外配置，以支持更广泛的数据共享场景。在使用MyBatis时，应根据具体的应用场景和需求来决定是否以及如何使用这两种缓存机制。）
分布式缓存： 使用Redis等分布式缓存系统来缓存热点数据。
7、前端优化：
减少请求次数： 合并多个请求为一个，减少网络延迟的影响。
数据压缩： 对传输的数据进行压缩，减少传输内容的大小。
8、配置调优：
调整JVM参数： 如果是Java应用，适当调整JVM的内存和垃圾回收参数。
网络优化： 优化TCP/IP参数，如调整TIME_WAIT的超时时间等。
综上所述，优化接口的TP99性能是一个系统性工程，需要结合具体的业务场景和技术栈，持续监测、分析和调整。在实际操作中，建议先从最显而易见的问题着手，例如检查是否有未加索引的查询或是否可以添加更有效的索引，逐步深入到系统设计层面的优化。同时，也要注意优化工作可能会涉及代码改动，应在测试环境中先行验证，确保不会影响现有功能的稳定性。

四、系统架构或者代码逻辑混乱怎么优化？
面对系统架构或代码逻辑混乱的情况，优化的目标是提升系统的可维护性、可扩展性和性能。以下是一些建议：
1、代码重构：
识别问题代码： 通过代码审查和分析工具找出代码中的坏味道，如重复代码、过长函数、过大类等。
模块化： 将功能相关的代码组织到一起，形成模块，降低代码间的耦合度。
提取公共功能： 将重复的代码提取为公共方法或服务，减少冗余。
遵循设计模式： 合理运用设计模式来优化代码结构，如工厂模式、单例模式等。
2、架构调整：
分层架构： 确保系统有清晰的层次结构，如表现层、业务逻辑层、数据访问层等。
微服务拆分： 如果系统过于庞大，可以考虑将其拆分为微服务，每个服务负责一部分功能。
3、文档和注释：
完善文档： 编写详细的设计文档和API文档，帮助团队成员理解系统架构和代码逻辑。
添加注释： 在代码中添加必要的注释，说明代码的功能和设计思路。
4、测试和监控：
单元测试： 编写单元测试用例，确保重构后的代码仍然能够正常工作。
集成测试： 进行集成测试，确保各个模块之间能够正确协作。
性能监控： 使用性能监控工具，持续跟踪系统性能，及时发现并解决性能瓶颈。
5、持续集成/持续部署（CI/CD）：
自动化构建和部署： 建立CI/CD流程，确保代码的变更能够快速且安全地部署到生产环境。
6、技术债务管理：
制定计划： 识别系统中的技术债务，并制定计划逐步解决。
定期审查： 定期审查代码和架构，评估是否需要进一步的优化。
总的来说，优化混乱的系统架构或代码逻辑需要综合运用多种技术和方法。这通常是一个渐进的过程，需要团队的协作和长期的投入。在进行优化时，应注意保持系统的稳定性，避免引入新的问题。

五、有遇到系统中存在的一些问题吗？怎么解决的？
动态线程池组件，可以动态的去调整线程池的参数，例如：核心线程数、最大线程数、等待时间、阻塞队列。
JADE 内部线程池封装了 Guava RateLimiter 限速器，底层基于令牌桶线程执行任务前先获取令牌并等待，从而达到限速目的。

六、线程池流程
线程池的流程涉及任务的提交、执行以及线程的管理。
首先，当有新任务提交给线程池时，线程池会进行以下判断和操作：
1、核心线程数判断： 如果当前运行的线程数量小于核心线程数（corePoolSize），则立即创建一个新的工作线程来执行该任务。
2、阻塞队列判断： 如果当前运行的线程数量等于或大于核心线程数，线程池会判断阻塞队列是否已满。如果阻塞队列未满，新提交的任务会被存储在阻塞队列中等待执行。
3、最大线程数判断： 如果阻塞队列已满，线程池会判断当前运行的线程数量是否小于最大线程数（maximumPoolSize）。如果不是，即还有剩余的工作线程位置，线程池会创建新的工作线程来处理任务。
4、饱和策略： 如果上述条件都不满足，即阻塞队列已满且线程池中的线程数量已经达到最大值，这时线程池会根据设定的饱和策略来处理这个任务。饱和策略可能包括抛出异常、丢弃任务、延迟执行等。
其次，线程池的核心实现类是ThreadPoolExecutor，它提供了execute()方法来接收并处理提交的任务。ThreadPoolExecutor类还提供了管理线程池本身的方法，如查看任务状态、停止线程池等。
最后，在任务被执行的过程中，线程池会维护一个工作线程集合，这些线程负责执行任务。每个工作线程在启动时会调用其run()方法，进而执行线程池中的runWorker(worker)方法，最终执行worker.firstTask.run()来运行具体的任务。
综上所述，线程池的流程是一个复杂的过程，涉及多个组件和策略的协同工作，以确保任务的有效执行和资源的合理利用。
5、扩展：线程池的拒绝策略：
线程池的拒绝策略是指当任务数量超过线程池的处理能力时，线程池如何处理这些额外的任务。Java中的ThreadPoolExecutor提供了以下几种拒绝策略：
AbortPolicy（默认策略）：直接抛出RejectedExecutionException异常，阻止系统正常运行。
CallerRunsPolicy：只用调用者所在线程来运行任务。如果执行器关闭，则丢弃该任务。
DiscardOldestPolicy：丢弃队列中最老的任务，然后尝试重新提交当前任务。
DiscardPolicy：不处理被拒绝的任务，直接丢弃。

七、oom怎么解决
解决OOM（内存溢出）问题通常需要根据具体情况来分析，以下是一些常见的解决方法：
1、分析报错信息： 需要查找关键报错信息，如java.lang.OutOfMemoryError: Java heap space，这通常指的是Java堆内存溢出。
2、使用分析工具： 可以使用内存映像分析工具，如Eclipse Memory Analyzer或JProfiler，对堆内存的快照进行分析，以确定是内存泄漏还是内存溢出的问题。
3、检查代码问题： 如果不存在内存泄漏，应检查代码中是否有死循环、递归、大对象、threadLocal等可能导致内存耗尽的情况。如果是内存泄漏，可以通过工具查看泄漏对象到GC Roots的引用链，并修复应用程序中的内存泄漏问题。
4、调整启动参数： 可以考虑通过JVM启动参数-Xmx来增加堆大小，以提供更多的内存空间给应用程序使用。
5、检查Direct ByteBuffer使用： 如果使用了NIO，如Netty或Jetty等，可能会涉及到Direct ByteBuffer的使用。可以通过Arthas等在线诊断工具拦截ByteBuffer.allocateDirect方法进行排查，并通过启动参数-XX:MaxDirectMemorySize调整Direct ByteBuffer的大小。
6、检查永久代或元空间设置： 如果OOM是由于永久代空间或元空间设置过小导致的，需要检查并适当增加这些区域的大小。
7、减少反射操作： 大量的反射操作可能会导致内存溢出，特别是生成了大量的代理类。可以通过MAT（Memory Analyzer Tool）等工具检查是否存在这种情况，并尽量减少反射的使用。
8、重启JVM： 在某些情况下，如果上述方法都无法解决问题，可能需要考虑重启JVM来释放占用的内存资源。
9、扩展：常见的JVM参数
JVM的常见参数包括内存配置参数、垃圾回收(GC)策略配置参数以及日志和异常信息参数等。具体如下：
（1）内存配置参数：
-Xms: 这个参数用于设置JVM启动时堆的初始大小。例如，-Xms20m表示初始堆大小为20MB。
-Xmx: 此参数指定JVM最大可用的内存大小。如-Xmx1024m或-Xmx1g分别代表最大可用内存是1024MB或1GB。
-Xmn: 用来设定新生代的大小。比如-Xmn30m意味着新生代大小为30MB。
-Xss: 设置每个线程的栈大小。例如，-Xss1m指每个线程的栈大小为1MB。
（2）垃圾回收策略配置参数：
-verbose:gc: 输出每次GC时的相关信息，有助于分析垃圾回收行为。
-XX:+UseConcMarkSweepGC: 使用CMS（并发标记清除）收集器。
-XX:+UseParallelGC: 使用并行垃圾回收器。
-XX:+UseSerialGC: 使用串行垃圾回收器。
（3）日志和异常信息参数：
-XX:ErrorFile= : 指定错误信息写入的文件路径。
-XX:HeapDumpOnOutOfMemoryError: 在发生内存溢出错误时生成堆转储快照。
-XX:HeapDumpPath= : 指定堆转储快照的路径。
此外，还有非标准参数（-X开头）和非稳定参数（-XX开头），这些参数可能会根据不同的JVM实现有所不同，并且有的参数在未来的版本中可能会被移除，所以在使用这些参数时需要谨慎。

八、数据库索引类型
1、聚簇索引和非聚簇索引
聚簇索引和非聚簇索引的数据结构都是基于B+树实现的。
聚簇索引的特点是数据行实际上存储在索引的叶子节点中。这意味着，当查询使用聚簇索引时，找到索引的同时也就找到了相应的数据行。在MySQL的InnoDB存储引擎中，主键索引就是聚簇索引，因此表数据按照主键的顺序物理存储。如果表没有显式定义主键，InnoDB会选择一个唯一非空索引作为聚簇索引，如果这样的索引也不存在，则会隐式定义一个。
非聚簇索引的数据行和索引是分开存储的。非聚簇索引的叶子节点包含指向数据行的指针，而不是直接包含数据行。这意味着当查询使用非聚簇索引时，首先找到索引，然后需要根据索引中的指针去查找实际的数据行。在InnoDB中，非聚簇索引也被称为二级索引或辅助索引。
总的来说，聚簇索引和非聚簇索引都是基于B+树的数据结构，但它们的存储方式和叶子节点的内容不同，这影响了它们在数据检索时的性能和特性。
参考文档：https://mp.weixin.qq.com/s?__biz=MzAxMjY5NDU2Ng==&mid=2651861539&idx=1&sn=77e036f27b300dfddc979842f3255b30&chksm=8049776ab73efe7cdc3c777e6c499bfcd92538d97210e8b745e7402d2e1068367a9877f8dca4&scene=27

2、非聚簇索引中的回表
回表是数据库查询过程中的一个术语，它通常发生在使用非聚集索引进行查询时。
当通过非聚集索引查找数据时，如果索引中不包含查询所需的所有列数据，数据库需要先通过索引找到对应的主键或聚集索引的值，然后根据这个值回到原始的数据表中获取剩余的列数据。这个过程就被称为“回表”。
回表操作的性能通常较低，因为它涉及到额外的磁盘I/O操作。为了提高查询效率，数据库管理员和开发人员会尽量避免回表操作。
避免回表的方法包括：
使用覆盖索引：如果查询所需的所有列数据都包含在索引中，那么就不需要回表，因为索引本身就是查询结果的完整表示。这种索引被称为覆盖索引。
索引下推： 这是一种优化技术，它在索引扫描过程中就能推断出其他列的值，从而避免了回表的需要。
总的来说，理解回表的概念对于优化数据库查询性能是非常重要的。在实际的数据库设计和维护中，合理地使用索引，尽量减少回表操作，可以显著提高查询效率和整体的系统性能。

• 扩展：索引下推是什么？

九、事务的特性
事务在数据库系统中是一系列操作的集合，这些操作要么全部成功，要么在出现错误时全部失败并回滚到初始状态，事务的特性通常被简称为ACID特性：
原子性（Atomicity）：确保事务是不可分割的最小工作单位。在事务中的所有操作必须全部完成，如果中途有任何操作失败，则整个事务会回滚，以保证不会处于部分完成的状态。
一致性（Consistency）：保证事务执行前后数据的一致性。即事务的执行结果必须使数据库从一个一致性状态转变为另一个一致性状态，数据的整体完整性规则必须得到遵守。
隔离性（Isolation）：确保并发执行的事务之间互不干扰，每个事务都感觉像是在独立地执行一样。隔离性防止了事务之间的交互直到它们完成执行，避免了不同事务之间的中间状态对彼此造成影响。
持久性（Durability）：一旦事务被提交，其对数据库的修改就应该是永久的。即使在提交后发生系统故障，数据库也能够恢复到事务提交时的状态。
综上所述，这四个特性共同构成了事务处理的基础，使得数据库能够可靠地处理复杂的并发操作，维护数据的准确性和稳定性。

十、数据库的一致性怎么保证
保证数据库一致性涉及到多个层面的措施，包括数据库本身的设计、事务管理以及应用层的控制。以下是一些关键的方法：
1、事务的ACID属性： 数据库通过实现事务的原子性（Atomicity）、隔离性（Isolation）和持久性（Durability）来保证一致性（Consistency）。原子性确保事务中的操作要么全部成功，要么全部失败；隔离性确保并发执行的事务不会相互干扰；持久性保证一旦事务提交，其效果就会永久保存在数据库中。
2、数据库引擎的支持：例如，MySQL的InnoDB引擎支持事务处理，它通过使用undo log来实现原子性，确保在出现错误时可以回滚到事务开始前的状态。
3、正确的应用程序逻辑： 即使在数据库层面实现了ACID属性，如果应用程序在事务中执行的逻辑本身就存在问题，比如故意不执行某些必要的操作，那么一致性仍然无法得到保证。因此，应用程序需要正确实现业务逻辑，确保数据的一致性。
4、缓存一致性： 在使用缓存的系统中，为了保证缓存和数据库之间的一致性，通常采用“先更新数据库，再删除缓存”的策略，并结合消息队列或订阅变更日志的方式来同步数据。
5、数据库约束： 数据库系统内部通过设置各种约束（如唯一性约束、外键约束等）来确保数据的一致性。这些约束帮助数据库拒绝不符合规则的数据操作，从而维护数据的完整性。
6、合理的数据库设计： 合理的数据库设计也是保证一致性的关键。这包括规范化的表结构设计、合理的索引策略以及有效的查询优化等。
7、监控和审计： 定期监控数据库的性能和健康状况，审计数据操作，可以帮助及时发现和解决可能导致数据不一致的问题。
8、备份和恢复策略： 即使采取了上述所有措施，也无法完全避免数据不一致的风险。因此，建立有效的数据备份和恢复策略是必要的，以便在发生问题时能够迅速恢复到一致的状态。
综上所述，保证数据库一致性是一个复杂的过程，需要从多个角度综合考虑和实施措施。通过数据库的设计、事务管理、应用逻辑的控制以及监控和审计等手段，可以有效地确保数据库的一致性。

十一、rabbitmq的优点以及支持的数据量级
RabbitMQ作为一个流行的开源消息代理软件，具有以下几个主要优点：
异步通信： 它允许系统进行异步处理，这意味着发送者和接收者不需要同时在线。这提高了系统的响应速度和吞吐量。
服务解耦： 通过使用RabbitMQ，服务之间不再直接通信，而是通过消息队列进行交互。这种解耦可以减少服务之间的依赖，提高系统整体的稳定性和可扩展性。
削峰填谷： 在面对突发流量时，RabbitMQ可以帮助系统以有限的资源稳定运行。它通过缓存请求来分摊瞬时压力，从而避免系统过载。
可靠性： RabbitMQ确保了消息的可靠传递，采用了消息确认机制。生产者发送消息后会收到确认，消费者处理完消息也会发送确认，如果消息发送或处理失败，RabbitMQ会重新发送消息直到确认为止。
灵活性： RabbitMQ支持多种消息传递模式，包括点对点、发布/订阅和路由等，这使得它能够适应多种不同的应用场景。
高性能： 由于Erlang语言的特性，RabbitMQ在高并发场景下表现出色，吞吐量可以达到万级别。
功能完备： RabbitMQ提供了丰富的功能，包括死信队列、持久化、优先级队列等，满足企业级应用的需求。
多语言支持： 它支持多种编程语言，如Java、Python、Ruby等，这为不同技术栈的开发者提供了便利。
易用性： RabbitMQ提供了简单的API和丰富的文档，使得开发者可以快速上手并实现复杂的消息传递模式。
社区支持： 作为一个开源项目，RabbitMQ拥有活跃的社区和大量的用户，这意味着在遇到问题时可以获得来自社区的帮助。
集群能力： RabbitMQ支持集群部署，可以通过增加节点来提高消息处理的能力和系统的可用性。
管理界面： 它提供了一个方便的管理界面，使得管理员可以轻松监控和管理消息队列的状态。
综上所述，RabbitMQ的优点包括异步通信、服务解耦、削峰填谷、可靠性、灵活性、高性能、功能完备、多语言支持、易用性、社区支持、集群能力和管理界面。这些优点使得RabbitMQ成为构建可靠、高性能和可扩展系统的理想选择。

十二、redis缓存穿透和缓存雪崩
1、缓存穿透是一种常见的缓存问题，指的是用户查询的数据在缓存和数据库中都不存在，导致每次请求都会直达数据库，可能对数据库造成压力。
以下是一些防止缓存穿透的措施：
布隆过滤器（Bloom Filter）：可以在缓存之前使用布隆过滤器来拦截那些不存在的数据请求，减少不必要的数据库访问。
缓存空值： 对于查询结果为空的请求，可以将空值也缓存起来，并设置一个较短的过期时间，这样即使有大量相同的查询请求，也可以直接在缓存中返回空值，而不会访问数据库。
**异步加载：**对于某些预期会频繁查询但暂时不存在的数据，可以采用异步加载的方式预先加载到缓存或数据库中，避免用户实时查询时造成的穿透。
**限流策略：**对于异常高频的请求，可以采取限流措施，如限制IP的访问频率等，以防止恶意攻击导致的缓存穿透问题。
**优化查询逻辑：**确保应用程序的查询逻辑正确高效，避免因错误的查询条件而导致缓存穿透。
综上所述，缓存穿透问题的解决需要综合考虑缓存策略、数据查询逻辑以及系统的整体架构。通过合理设计和配置，可以有效降低缓存穿透对数据库的影响，保证系统的稳定运行。
2、缓存雪崩是指在某个时间段内，大量缓存数据同时失效，导致请求直接打向数据库，从而对数据库造成极大的负载压力，严重时可能导致系统崩溃。
以下是一些防止缓存雪崩的措施：
设置不同的过期时间： 为缓存数据设置随机的过期时间，避免所有数据在同一时间失效。
缓存预热： 在缓存服务器启动时，预先加载热点数据到缓存中，减少对数据库的直接访问。
缓存分片： 将缓存数据分散到不同的缓存服务器上，即使某一部分服务器宕机，也能保证其他服务器上的缓存数据可用。
使用熔断器模式： 当检测到异常流量时，暂时关闭某些服务，防止系统过载。
服务隔离： 确保不同的服务之间相互独立，一个服务的崩溃不会影响到其他服务。
限流策略： 对于流量进行限制，防止突发的高流量对系统造成冲击。
监控预警： 建立有效的监控系统，及时发现并处理潜在的雪崩风险。
数据备份和快速恢复： 确保有备份机制，一旦发生雪崩，可以快速恢复数据。
使用互斥锁： 在更新缓存时使用互斥锁，防止同时写入相同数据导致的冲突。
定时刷新： 对于重要的数据，可以设置定时刷新机制，保证缓存中的数据始终是最新的。
程序加锁： 在读取数据时，通过程序逻辑加锁，避免多线程同时操作同一数据。
综上所述，防止缓存雪崩需要综合考虑系统的设计和运维策略，通过多种措施确保系统的高可用性和稳定性。
3、缓存击穿(Hotspot Invalid)
缓存击穿，就是说某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。
不同场景下的解决方式可如下：
若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期。
若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下，则可以采用基于 Redis、zookeeper 等分布式中间件的分布式互斥锁，或者本地互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余线程则在锁释放后能访问到新缓存。
若缓存的数据更新频繁或者在缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动地重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。

十三、redis持久化的方案
Redis 提供了两种主要的持久化机制来保证数据的安全性和可恢复性：
1、快照（RDB：Redis DataBase）：
RDB 持久化是通过在指定的时间间隔内生成数据集的时间点快照来工作的。
它会创建当前所有数据的二进制文件，并保存到磁盘上。
RDB 非常适合于灾难恢复，因为它提供了一个紧凑的文件，可以快速加载到 Redis 中。
缺点是，如果发生故障，可能会丢失最后一次快照之后的所有数据。
RDB 的触发机制可以是时间间隔（如每小时），也可以是特定数量的写操作。
2、只追加文件（AOF:Append Of File）：
AOF 持久化记录了所有的写操作命令，每个写操作都会被追加到一个日志文件中。
这种方式提供了更高的数据安全性，因为即使遇到系统崩溃，也可以通过重放日志文件来恢复到最近的写操作。
AOF 的缺点是，随着操作的增加，日志文件的大小可能会变得很大。
AOF 可以通过设置不同的写入策略来控制性能和安全性，包括每次写操作后立即同步（always）、每秒同步一次（everysec）和依赖操作系统的缓存机制（nosync）。
在选择持久化方案时，需要根据应用场景的需求来权衡。例如，**对于需要高性能的场景，可能更倾向于使用 RDB；而对于需要高数据安全性的应用，AOF 可能是更好的选择。**此外，也可以同时使用 RDB 和 AOF，以便结合两者的优点。
参考：https://blog.csdn.net/weixin_43888891/article/details/131031003

十四、spring ioc和aop
Spring框架的IoC（控制反转）和AOP（面向切面编程）是两个核心特性，它们共同促进了代码的解耦和扩展性。以下是对这两个概念的具体介绍：
**1、IoC：**控制反转是一种设计思想，它将对象的创建、配置和管理从程序员手中转移到了外部容器。这样，对象不需要自己创建它们的依赖项，而是由IoC容器负责。这样做的好处是降低了组件之间的耦合度，提高了系统的灵活性和可维护性。在Spring中，IoC容器就是BeanFactory，它通过XML解析、工厂模式和反射机制来实现IoC原理。
**2、AOP：**面向切面编程是一种编程范式，它允许开发人员将横切关注点（如日志记录、事务管理等）从业务逻辑中分离出来，从而实现关注点的模块化。AOP通过在编译或运行时动态地将横切代码插入到指定位置来实现这一目的。使用AOP可以提高代码的重用性，减少重复代码，并提高系统的整体架构设计。
总的来说，IoC和AOP是Spring框架中的两个重要概念，它们帮助开发者编写更加清晰、灵活且易于维护的代码。

十五、工作中遇到的有挑战性的事情
ES集群数据迁移，需要保证新老集群数据的一致性。

十六、整数反转算法怎么实现
整数反转算法的目的是将一个给定的32位有符号整数中的每一位数字进行反转。以下是实现整数反转的基本步骤：
1、方法一：取模运算
初始化：定义一个变量用于存储反转后的结果，通常初始化为0。
取余和除法操作：通过循环结构，每次迭代中，使用取余操作（%）得到原整数的最后一位数字，并将其乘以10后加到结果变量上。然后使用除法操作（/）去掉原整数的最后一位。
边界条件处理：在循环过程中，需要检查反转后的结果是否会超出32位有符号整数的范围。如果超出范围，通常会返回错误或特定的标志值，例如0或者INT_MAX/INT_MIN。
特殊情况处理：对于负数输入，可以先将其转换为正数进行处理，然后在最后再添加负号。
2、方法二：字符串reverse方法
转换方法：另一种方法是将整数转换为字符串，然后将字符串转换为字符数组，反向遍历字符数组并将元素存储到新数组中，最后将新数组转换成字符串，再转换为整数输出。
优化：在某些情况下，可以利用long类型的范围特点来避免溢出的问题，但这可能不符合题目要求只能使用32位整数的限制。
综上所述，整数反转算法的关键在于逐步提取原始整数的每一位数字，并将其按逆序构建成新的整数。需要注意的是，由于整数反转可能会导致数值溢出，因此在实现时要考虑边界情况的处理。