自我介绍

简单自我介绍

面试官自我简单介绍，介绍业务

项目

项目背景

承担任务

实现成果

服务发现

服务发现怎么做的？

在Spring Cloud中使用Nacos实现服务发现的一般步骤：

  1. 添加Nacos依赖：

    • 在Spring Boot项目的 pom.xml 文件中添加Nacos的依赖。
    1
    2
    3
    4
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>

  2. 配置Nacos连接：

    • 在应用程序的配置文件（通常是 application.yml 或 application.properties）中指定Nacos服务器的连接信息。
    1
    2
    3
    4
    5
    spring:
      cloud:
        nacos:
          discovery:
            server-addr: nacos-server-host:8848

    这里的 nacos-server-host 是您Nacos服务器的主机地址和端口。

  3. 配置服务信息：

    • 在应用程序的配置文件中指定您的服务信息，如应用程序名称。
    1
    2
    3
    spring:
      application:
        name: my-service

  4. 启用Nacos服务发现：

    • 在应用程序的主类上使用 @EnableDiscoveryClient 注解标记它作为Nacos服务发现的一部分。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    import org.springframework.cloud.client.discovery.EnableDiscoveryClient;

    @SpringBootApplication
    @EnableDiscoveryClient
    public class MyServiceApplication {
        public static void main(String[] args) {
            SpringApplication.run(MyServiceApplication.class, args);
        }
    }

  5. 启动应用程序：

    • 启动您的Spring Boot应用程序。它会自动注册到Nacos服务器上。

  6. 验证服务发现：

    • 访问Nacos的Web控制台，通常是 http://nacos-server-host:8848/nacos，您可以查看已注册的服务列表。

  7. 使用服务发现：

    • 在其他服务中，可以通过服务名来访问已注册的服务。Spring Cloud会自动处理负载均衡和服务发现。

这些步骤可以让您使用Nacos作为服务发现和注册中心，使您的微服务能够轻松地找到和访问彼此。与Eureka类似，Nacos也提供了集成Spring Cloud的功能，使得在微服务架构中实现服务注册和发现变得更加方便。

负载均衡在哪里做的？

都能做。本地缓存ribborn，nacos自身。

这样子做有什么好处？

  • 可以根据服务器的性能差异，让性能好的服务器承担更多的用户请求，提高系统的效率和稳定性。
  • 可以在服务器进行维护或升级时，通过调整权重值，实现平滑的流量切换，避免对用户造成影响。
  • 可以根据业务需求，灵活地控制不同服务的访问频率和优先级，实现更合理的资源分配

熔断降级

什么是熔断，作用

熔断（Circuit Breaker）是一种用于构建稳定和可靠分布式系统的设计模式。它的主要作用是在分布式系统中防止连锁故障，提高系统的容错性和可用性。

熔断的核心思想类似于电路中的断路器。在电路中，断路器用于在电流过大或电路故障时切断电源，防止电路元件受损。在分布式系统中，熔断器也有类似的作用。

以下是熔断的主要作用：

  1. 防止连锁故障：在分布式系统中，一个服务的故障可能会导致多个依赖该服务的其他服务也出现问题。熔断器通过监控服务的状态，当服务达到一定的故障阈值时，将服务的请求快速拒绝，而不是让请求继续失败，从而避免了连锁故障的发生。

  2. 提高系统的容错性：熔断器可以使系统更具容错性。当一个服务不可用或出现故障时，熔断器可以迅速将流量转移到备用服务或执行其他容错操作，以确保系统的可用性。

  3. 快速恢复：熔断器通常具有自动重试功能。当服务的状态改善时，熔断器可以逐渐恢复对服务的请求，而不是立即允许所有请求通过。这有助于减轻服务恢复时的压力，防止过载。

  4. 实时监控和告警：熔断器通常会记录服务的状态信息，包括成功和失败的请求数量，以及熔断器的开启和关闭状态。这些信息可用于实时监控和告警系统，帮助运维人员快速识别和解决问题。

总的来说，熔断器是一种强大的工具，用于提高分布式系统的稳定性和可用性。它允许系统快速适应故障，减少服务间的相互依赖性，防止故障蔓延，并提供实时监控和反馈机制，有助于及时发现和解决问题。

什么时候熔断，哪些服务能够熔断

熔断通常在以下情况下触发：

  1. 连续的请求失败：如果一个服务的连续请求失败达到了一定的阈值，熔断器将启动。这意味着服务不再可用，请求将被快速拒绝，而不是继续尝试失败的请求。这可以防止向不可用的服务发出大量请求。

  2. 请求超时：如果大多数请求超时，熔断器可能会启动。这可能表明服务的响应时间变得非常长，或者服务已经停止响应。熔断可以防止等待时间过长的请求拖垮系统。

  3. 异常率过高：如果服务的异常率（如HTTP 500错误）达到一定的阈值，熔断器可能会启动。这表示服务出现了内部错误，需要进行修复。

哪些服务可以使用熔断器取决于您的系统架构和需求。通常，任何可能出现故障或不可用的服务都可以受益于熔断器的使用。这包括：

  • 外部依赖的服务：如果您的应用程序依赖于外部服务（例如，第三方API、数据库、消息队列等），那么这些外部服务的故障可能会影响到您的应用程序。使用熔断器可以减轻这种风险。

  • 内部微服务：在微服务架构中，每个微服务都可能成为其他微服务的依赖。使用熔断器可以防止一个微服务的故障导致整个系统的故障。

  • 资源密集型操作：如果您的服务执行资源密集型操作（如文件上传、图像处理等），那么使用熔断器可以防止这些操作导致系统过载。

流量控制

如何管理

Sentinel是一款开源的流量控制和服务保护工具，它可以帮助您管理和控制应用程序中的流量，以确保应用程序的稳定性和可用性。以下是使用Sentinel进行流量控制的一般步骤：

  1. 引入Sentinel依赖：
    首先，您需要在您的项目中引入Sentinel的依赖。这可以通过Maven或Gradle等构建工具完成。

    1
    2
    3
    4
    5
    <dependency>
        <groupId>com.alibaba.csp</groupId>
        <artifactId>sentinel-core</artifactId>
        <version>1.8.2</version>
    </dependency>

  2. 配置资源规则：
    在应用程序中，您可以配置资源规则（Resource Rules），这些规则定义了哪些资源需要进行流量控制。资源可以是方法、接口、URL等。规则可以定义每个资源的流量控制策略，如限流阈值、限流模式等。

    以下是一个示例配置文件（sentinel.yaml）：

    1
    2
    3
    4
    5
    rules:
      - resource: your-resource-name
        limitApp: default
        grade: QPS
        count: 10

    在这个示例中，我们定义了一个资源规则，指定了资源名称为your-resource-name，限制每秒的请求数（QPS）为10。

  3. 初始化Sentinel：
    在应用程序启动时，需要初始化Sentinel，以便它能够开始监控和控制流量。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    import com.alibaba.csp.sentinel.init.InitExecutor;

    public class Application {
        public static void main(String[] args) {
            // 初始化Sentinel
            InitExecutor.doInit();
            // 启动应用程序
            // ...
        }
    }

  4. 使用注解配置流量控制（可选）：
    Sentinel还支持使用注解来配置流量控制。您可以在方法上添加@SentinelResource注解来定义资源名称和流量控制策略。这允许您更灵活地控制流量，而无需在配置文件中硬编码规则。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    import com.alibaba.csp.sentinel.annotation.SentinelResource;

    @Service
    public class MyService {
        @SentinelResource("your-resource-name")
        public void doSomething() {
            // Your code here
        }
    }

  5. 监控和管理流量：
    Sentinel提供了一个可视化的仪表板，可以用于监控流量、查看规则执行情况以及手动修改规则。您可以通过访问仪表板来实时监控应用程序的流量情况。

    默认仪表板地址：http://localhost:8080（可以在配置文件中进行配置）

通过以上步骤，您可以在应用程序中使用Sentinel进行流量控制。Sentinel不仅可以限制流量，还可以实时监控流量和规则执行情况，有助于保护应用程序免受潜在的流量峰值和故障的影响。此外，Sentinel还提供了丰富的配置选项和扩展功能，以满足不同场景下的流量控制需求。

处理策略

Sentinel提供了多种流量控制策略，以满足不同应用场景的需求。以下是一些常见的Sentinel流量控制策略：

  1. **QPS (每秒请求数)**：这是最常见的流量控制策略之一。您可以限制每秒通过的请求数量。当QPS超过设定的阈值时，Sentinel将开始拒绝请求。

  2. **线程数 (并发线程数)**：这种策略限制了同时执行的线程数量。当并发线程数超过设定的阈值时，Sentinel将开始拒绝请求。

  3. 关联资源（热点参数限流）：有时候，流量控制需要考虑多个关联资源的限制。Sentinel可以根据关联资源的情况来进行限流，以确保不同资源之间的协调。

  4. 排队等待：当流量达到限制时，您可以选择将请求放入队列中等待，而不是立即拒绝请求。这可以有效平滑流量峰值。

  5. 预热限流：允许在启动时限制流量，然后逐渐放宽流量限制，以避免启动时的流量峰值。

  6. 系统自适应流量控制：Sentinel还支持基于实际系统负载情况自动调整流量控制策略。这是一种自动调整限流阈值的策略，以适应不同负载水平。

  7. 熔断降级：虽然不是传统的流量控制策略，但熔断降级策略可以在服务不稳定或出现故障时停止请求的流量，以防止流量加重问题。

  8. 热点限流：这是一种用于应对热点资源的流量控制策略。例如，在秒杀活动中，通常会有一个热门商品，它的请求量远高于其他商品。热点限流可以对热门资源进行单独的流量控制。

  9. 自定义流量控制策略：Sentinel还支持自定义流量控制策略，您可以根据特定的业务需求实现自己的限流逻辑。

请注意，不同的流量控制策略适用于不同的场景和需求。选择适当的策略取决于您的应用程序架构和性能需求。Sentinel提供了丰富的配置选项，使您能够根据具体情况来配置和定制流量控制。

拒绝策略

Sentinel提供了多种拒绝策略，用于在流量超出限制时如何处理请求。以下是一些常见的拒绝策略：

  1. 直接拒绝（Default）：这是默认的拒绝策略。当请求超出流量限制时，Sentinel将直接拒绝请求，并返回相应的错误信息。

  2. Warm Up（预热）：预热策略允许流量逐渐增加，而不是突然拒绝请求。它会在启动时限制流量，并随着时间的推移逐渐提高流量限制，直到达到设定的阈值。

  3. 排队等待（Request-Queueing）：排队等待策略会将请求放入队列中等待处理，而不是立即拒绝请求。这可以有效平滑流量峰值，但可能会导致延迟增加。

  4. 匀速排队（Reject）：这种策略会以恒定的速率拒绝请求，而不是将它们放入队列。这可以用于控制在高流量时不会有过多的排队请求。

  5. 自定义策略（Custom）：Sentinel允许您实现自定义的拒绝策略，以满足特定需求。您可以根据业务逻辑和性能需求来自定义如何拒绝请求。

这些拒绝策略允许您根据应用程序的需求来控制请求的处理方式。每种策略都有其适用的场景和权衡，您可以根据具体情况选择合适的策略。例如，如果您的应用程序需要严格的流量控制并能够快速失败，那么直接拒绝策略可能是合适的。如果您更关心平滑的流量控制和延迟增加，那么排队等待或预热策略可能更合适。自定义策略则允许您根据特定的应用场景进行更灵活的定制。

A调用B，超过限制，如何实现同步

令牌桶实现。

当服务A调用服务B并超过流量限制时，您可以实现同步调用等待策略，以确保A不会过度频繁地调用B。这可以通过使用排队等待拒绝策略来实现。

以下是实现同步调用等待策略的一般步骤：

  1. 配置排队等待策略：首先，在Sentinel的规则配置中，使用排队等待拒绝策略（Request-Queueing）来定义资源A对资源B的访问规则。您可以在配置文件或代码中进行配置。

    1
    2
    3
    4
    5
    6
    rules:
      - resource: resource-A
        limitApp: default
        grade: QPS
        count: 10
        strategy: 1  # 1表示排队等待

    在这个示例中，我们将资源A的流量限制配置为每秒10个请求，并采用排队等待策略。

  2. 在服务A中实现同步等待：在服务A的代码中，当需要调用服务B时，您可以使用类似以下的伪代码来实现同步等待：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    // 获取资源A的访问令牌
    if (entryA.blockingEnter()) {
        try {
            // 调用服务B
            response = callServiceB();
        } finally {
            // 释放资源A的访问令牌
            entryA.exit();
        }
    } else {
        // 资源A的访问令牌被拒绝，执行自定义的流量控制逻辑
        handleRateLimitExceeded();
    }

    在上述伪代码中，entryA 是资源A的访问令牌控制器。blockingEnter 方法用于尝试获取资源A的访问令牌，如果被拒绝，表示已经超过了流量限制。在成功获取令牌后，您可以调用服务B，然后在调用结束后使用 exit 方法释放令牌。

  3. 自定义流量控制逻辑：如果资源A的访问令牌被拒绝，表示已经达到流量限制，您可以根据应用程序的需求执行自定义的流量控制逻辑。这可能包括等待一段时间后重试，返回错误响应，或执行其他适当的操作。

通过上述步骤，您可以实现同步等待策略，确保在服务A调用服务B时不会超过流量限制。这有助于平滑流量并减少服务B的负载。请注意，具体的代码实现可能会根据您的编程语言和框架而有所不同，但基本思路是相似的。

大众点评项目

关注的关系如何数据库存储

用户表，关注关系表

秒杀超卖问题

秒杀系统中的超卖问题是指在短时间内（通常是秒级）出现多个用户同时购买某个商品，导致商品库存减少超过了实际库存数量的问题。这种情况可能会导致用户支付成功但实际上无法获得商品，从而损害用户体验和信誉。

超卖问题通常出现在以下情况：

  1. 竞争条件：当多个用户在秒杀活动开始的瞬间尝试购买同一件商品时，由于并发访问，系统可能无法实时更新库存，导致多个用户都认为自己购买成功，而实际上库存已经不足。

  2. 库存扣减不同步：在多个请求同时到达时，库存扣减操作可能不是原子性的，如果不进行适当的同步，就可能导致库存被重复扣减。

为了解决秒杀系统中的超卖问题，可以采取以下一些策略：

  1. 乐观锁：使用乐观锁机制来保护库存数据。在用户购买时，首先查询库存，然后在更新库存时检查库存是否足够。如果库存足够，才执行库存扣减操作，否则放弃购买。

  2. 分布式锁：使用分布式锁来保护库存扣减操作，确保只有一个请求能够执行扣减操作。这可以避免多个请求同时扣减库存的问题。

  3. 预扣库存：在秒杀活动开始前，将库存预先扣减到一个足够小的值，然后在秒杀活动结束后再根据实际销量进行库存的最终扣减。这可以减小并发请求同时访问库存的机会。

  4. 限制购买频率：限制用户购买频率，例如，每个用户每秒只能购买一次。这可以减少竞争条件的出现。

  5. 队列和异步处理：将用户的购买请求放入队列中，然后使用异步处理来逐个处理请求。这可以确保每个请求都按顺序处理，避免了竞争条件。

  6. 缓存：使用缓存来存储库存信息，以减少数据库查询的压力，并确保缓存是原子性的。

以上策略可以根据具体的秒杀系统需求和架构来选择和组合使用，以确保系统在高并发情况下仍然能够保持库存的一致性，避免超卖问题。

一致性

领取成功，库存没有减。

Java基础

事务四大特性

数据库事务具有四个重要的特性，通常被称为ACID特性。这些特性确保了事务的可靠性和一致性，无论在什么情况下，事务都能够正确地执行和维护数据的完整性。

  1. 原子性（Atomicity）：原子性是指事务是一个不可分割的操作单元，要么全部执行成功，要么全部执行失败。如果事务的任何部分失败，整个事务都将被回滚到之前的状态，没有部分提交的情况。这确保了数据库的一致性。

  2. 一致性（Consistency）：一致性确保了事务将数据库从一种一致性状态转换到另一种一致性状态。这意味着事务在执行前和执行后必须满足一组事务前提条件和事务后条件。如果违反了一致性规则，事务将被回滚。

  3. 隔离性（Isolation）：隔离性定义了多个事务之间的相互影响程度。每个事务都应该在不受其他事务影响的情况下执行，以防止数据混乱和不一致。数据库系统通常使用锁定机制来实现隔离性，以确保同时运行的事务不会相互干扰。

  4. 持久性（Durability）：持久性指的是一旦事务成功提交，其结果就会永久保存在数据库中，即使在系统故障的情况下也不会丢失。持久性通过将事务的变更写入磁盘来实现，以便在数据库重启后可以恢复数据。

这些ACID特性确保了事务的可靠性和一致性。在数据库中，事务是执行更改操作（例如插入、更新、删除等）的基本单位，通过满足这些特性，数据库可以确保数据的完整性和可靠性，即使在面对故障和并发访问的情况下也能保持数据的正确性。这对于许多应用程序非常关键，特别是那些需要高度可靠性和数据一致性的应用程序。

解释原子性

要么全部成功，要么全部失败

慢查询解决思路

解决MySQL慢查询问题通常需要一系列的思路和步骤，以识别和改进数据库查询性能。以下是解决MySQL慢查询问题的一般思路：

  1. 识别慢查询：

    • 使用MySQL的慢查询日志（slow query log）来捕获慢查询语句。慢查询日志记录了执行时间超过一定阈值的查询语句。
    • 使用数据库性能监控工具来实时监测查询性能，识别潜在的性能问题。

  2. 分析查询执行计划：

    • 对于慢查询，通过EXPLAIN语句来分析查询执行计划，了解MySQL是如何执行查询的。
    • 查看EXPLAIN的输出以确定是否正确使用了索引，是否进行了全表扫描等。

  3. 优化查询语句：

    • 根据EXPLAIN的输出和查询分析结果，对查询语句进行优化。优化包括但不限于：
      • 确保查询语句中使用了正确的索引。
      • 避免使用SELECT *，只选择需要的列。
      • 使用合适的查询条件，以减少返回的行数。
      • 考虑拆分大查询为多个小查询。
      • 使用连接（JOIN）时确保连接条件有效。

  4. 索引优化：

    • 确保表上的列有适当的索引，以加速查询。
    • 避免过多的索引，因为索引也需要维护。
    • 考虑使用复合索引，以满足多个查询条件。
    • 定期重新构建索引，以优化性能。

  5. 使用缓存：

    • 使用适当的缓存技术，如查询结果缓存（Query Cache）或内存缓存，以减轻数据库的负载。
    • 使用缓存可以避免频繁查询相同的数据。

  6. 升级硬件和优化配置：

    • 考虑升级硬件，如增加内存或更快的磁盘，以提高数据库性能。
    • 优化MySQL配置参数，如innodb_buffer_pool_size、key_buffer_size等，以适应系统需求。

  7. 分析和监控工具：

    • 使用性能分析工具（如Percona Toolkit、pt-query-digest等）来帮助识别和分析慢查询。
    • 使用监控工具（如Prometheus、Zabbix等）来实时监测数据库性能，以便及时发现问题。

  8. 定期维护：

    • 定期清理无用数据，删除不再需要的索引。
    • 确保数据库统计信息是最新的，以帮助优化查询执行计划。

  9. 垂直和水平分区：

    • 考虑将大表拆分为较小的表，以减少查询的数据量。
    • 考虑水平分区，将数据分布到多个物理服务器上，以平衡负载。

  10. 数据库版本升级：

    • 考虑将MySQL数据库升级到最新版本，因为新版本通常具有更好的性能和优化。

JVM内存结构

Java虚拟机（JVM）的内存结构是一个关键概念，它有助于理解Java程序在运行时如何管理内存。JVM的内存结构通常被分为以下几个主要部分：

  1. 方法区（Method Area）：

    • 方法区是一块用于存储类信息、常量、静态变量和编译后的代码的内存区域。
    • 每个加载的类都有一个对应的类信息在方法区中存储，包括类的字段、方法、构造函数等信息。
    • 方法区也包括运行时常量池，用于存储编译时生成的字面量和符号引用。

  2. 堆（Heap）：

    • 堆是Java应用程序中的主要内存区域，用于存储对象实例。
    • 所有的对象都在堆中分配内存。
    • 堆内存由垃圾回收器（Garbage Collector）管理，自动回收不再被引用的对象，以释放内存空间。

  3. Java栈（Java Stack）：

    • 每个线程都有一个私有的Java栈，用于存储方法调用和本地变量。
    • 每个方法在被调用时会创建一个栈帧，栈帧中包含方法的局部变量、操作数栈、方法出口等信息。
    • 栈帧在方法调用结束时被销毁，保证了局部变量的生命周期与方法的调用周期一致。

  4. 本地方法栈（Native Method Stack）：

    • 本地方法栈与Java栈类似，但用于执行本地（非Java）方法的调用。
    • 本地方法栈中的栈帧包含了本地方法的信息。

  5. 程序计数器（Program Counter Register）：

    • 每个线程都有一个程序计数器，用于存储当前线程执行的字节码指令地址。
    • 程序计数器在线程之间切换时保持线程独立。

  6. 直接内存（Direct Memory）：

    • 直接内存不是JVM的一部分，但是它与JVM密切相关，用于支持NIO（New I/O）操作。
    • 直接内存通过ByteBuffer来使用，允许Java程序直接与本地内存交互，提高了I/O操作的性能。

需要注意的是，JVM的内存结构在不同的JVM实现中可能会有所不同，也可以通过命令行参数来配置内存区域的大小。例如，可以通过-Xmx和-Xms参数来设置堆内存的最大和初始大小。

栈和堆

堆（Heap）和栈（Stack）是计算机内存中的两个主要区域，用于存储不同类型的数据和执行不同类型的操作。它们在数据存储、生命周期、访问速度和用途等方面有明显的区别和联系。

以下是堆和栈的区别与联系：

区别：

  1. 数据类型：

    • 堆：主要用于存储动态分配的数据，如对象、数组等。堆中的数据的大小和生命周期不固定，可以在运行时分配和释放。
    • 栈：主要用于存储程序执行过程中的局部变量和方法调用的信息。栈中的数据通常是具有固定大小和生命周期的。

  2. 生命周期：

    • 堆：数据的生命周期由程序员显式控制或垃圾回收器自动管理。数据在不再被引用时可以被回收。
    • 栈：数据的生命周期与其所在的方法或作用域的执行周期相同。当方法执行完毕或作用域结束时，栈上的数据被自动销毁。

  3. 访问速度：

    • 堆：堆上的数据访问通常较慢，因为需要动态分配和释放内存。
    • 栈：栈上的数据访问通常较快，因为数据的大小和位置是固定的，可以直接通过栈指针访问。

  4. 内存管理：

    • 堆：需要手动分配和释放内存，如果不正确使用可能导致内存泄漏或内存溢出。
    • 栈：内存管理是自动的，无需手动分配或释放内存。栈上的数据在作用域结束时自动销毁。

联系：

  1. 两者都是内存区域：堆和栈都是计算机内存的一部分，用于存储数据。

  2. 支持数据存储：无论是堆还是栈，都用于存储数据。堆用于存储动态分配的数据，而栈用于存储局部变量和方法调用的信息。

  3. 内存管理：堆和栈的内存管理方式不同，堆需要手动管理内存分配和释放，而栈的内存管理是自动的。

  4. 生命周期管理：堆和栈中的数据具有不同的生命周期，堆中的数据生命周期由程序员或垃圾回收器管理，而栈中的数据的生命周期与其所在的方法或作用域相关。

如何创造OOM

在Java编程中，可以通过不正确的内存管理或者分配大量内存来制造OutOfMemoryError（OOM）异常。OOM异常表示应用程序已经耗尽了可用的内存资源，无法继续执行。

以下是一些制造OOM异常的常见方法：

  1. 无限循环分配对象：编写一个循环，在每次迭代中创建一个大对象，并不断引用这些对象，直到内存耗尽。例如：

    1
    2
    3
    4
    5
    List<byte[]> list = new ArrayList<>();
    while (true) {
        byte[] data = new byte[1024 * 1024]; // 分配1MB的内存
        list.add(data);
    }

  2. 递归调用：编写一个递归函数，使其不断调用自身，直到堆栈溢出。这通常导致StackOverflowError异常，但也可能导致OOM异常，因为堆栈也是一种内存资源。

    1
    2
    3
    public void recursiveMethod() {
        recursiveMethod();
    }

  3. 多线程内存泄漏：在多线程应用程序中，如果线程不正确地管理内存，可能会导致内存泄漏。例如，如果线程创建了大量的对象并没有正确释放它们，将最终导致OOM异常。

  4. 大数据集合：如果你在内存中加载了大型数据集合，如大型列表或映射，并且没有释放其中的对象，也可能导致OOM异常。

  5. 不断增加堆内存：通过将Java虚拟机的最大堆内存参数（-Xmx）设置为一个极大的值，然后不断分配大对象，也可以制造OOM异常。

需要注意的是，制造OOM异常通常是为了测试应用程序在内存不足情况下的行为，以及确保应用程序能够适当地处理内存不足的情况。在实际的应用程序中，应该尽量避免OOM异常，通过合理的内存管理和优化来确保应用程序的稳定性和性能。

垃圾回收器

Java拥有多种垃圾回收器（Garbage Collector），每种回收器都有不同的特点和适用场景。以下是一些常见的Java垃圾回收器：

  1. Serial Garbage Collector：
    • 也称为Serial Collector。
    • 单线程的回收器，适用于单线程应用或小型应用。
    • 使用“标记-复制”算法。
  2. Parallel Garbage Collector：
    • 也称为Parallel Collector。
    • 多线程的回收器，适用于多核处理器和中型应用。
    • 使用“标记-复制”算法。
  3. Parallel Old Garbage Collector：
    • Parallel Collector的老年代版本，主要用于老年代的回收。
    • 适用于多核处理器和大型应用。
    • 使用“标记-整理”算法。
  4. Concurrent Mark-Sweep (CMS) Garbage Collector：
    • 也称为CMS Collector。
    • 多线程的回收器，主要用于降低停顿时间的需求。
    • 使用“标记-清除”算法。
  5. G1 Garbage Collector：
    • 也称为G1 Collector。
    • 多线程的回收器，设计用于大堆和低停顿时间。
    • 使用“标记-整理”算法。
    • 将堆分为多个区域，通过优先回收具有垃圾最多的区域来实现低停顿。
  6. Z Garbage Collector：
    • 也称为ZGC。
    • 多线程的回收器，设计用于大堆和低停顿时间。
    • 使用“标记-整理”算法。
    • 目标是实现极低的停顿时间，适用于内存敏感的应用。
  7. Shenandoah Garbage Collector：
    • 多线程的回收器，设计用于极低的停顿时间。
    • 使用“标记-整理”算法。
    • 适用于大型堆和对低延迟要求严格的应用。

每种垃圾回收器都有不同的特点和权衡，选择合适的回收器取决于应用程序的需求和硬件环境。通常，可以通过命令行参数来选择垃圾回收器，例如，使用-XX:+UseSerialGC来选择Serial Garbage Collector。优化垃圾回收器的配置和选择对于实现良好的Java应用程序性能至关重要。

什么对象应该被回收

在Java中，垃圾回收器（Garbage Collector）负责回收不再被引用的对象，以释放内存资源。对象应该被回收的条件通常是：

  1. 不再被引用：对象不再被任何活动的引用引用。这意味着没有指向该对象的引用变量，或者所有引用该对象的引用变量都已经超出了作用域。
  2. 无法通过引用链访问：对象无法通过任何引用链（从根对象开始的引用链）访问到。这意味着对象不再是可达的。
  3. 可达性分析：垃圾回收器通常使用可达性分析算法来确定哪些对象是可达的。从根对象（如线程栈帧中的局部变量、静态变量等）出发，垃圾回收器会追踪引用链，找出所有可达对象。不可达的对象会被标记为可回收。
  4. 内存不足：当Java虚拟机检测到内存不足时，会触发垃圾回收。在这种情况下，垃圾回收器会回收那些不再被引用的对象，以释放内存。

内存担保机制

img

内存分配是在JVM在内存分配的时候，新生代内存不足时，把新生代的存活的对象搬到老生代，然后新生代腾出来的空间用于为分配给最新的对象。这里老生代是担保人。在不同的GC机制下，也就是不同垃圾回收器组合下，担保机制也略有不同。在Serial+Serial Old的情况下，发现放不下就直接启动担保机制；在Parallel Scavenge+Serial Old的情况下，却是先要去判断一下要分配的内存是不是**>=Eden区大小的一半**，如果是那么直接把该对象放入老生代，否则才会启动担保机制。

image-20230908101355875

多线程

线程有哪些状态

线程在Java中有多种状态，这些状态反映了线程在不同时间点的行为和状态。Java线程的状态通常包括以下几种：

  1. 新建状态（New）：

    • 线程对象被创建后，处于新建状态。此时线程还没有被启动。
    • 可以通过创建一个Thread对象或其子类对象来进入新建状态。

  2. 就绪状态（Runnable）：

    • 线程被创建并启动后，进入就绪状态。此时线程已经准备好执行，但还没有分配到CPU时间片。
    • 处于就绪状态的线程可能正在等待CPU资源，等待调度器将其放入运行状态。

  3. 运行状态（Running）：

    • 当线程获得CPU时间片并开始执行时，处于运行状态。
    • 在某个时间点，只能有一个线程处于运行状态（单核处理器），或者有多个线程处于运行状态（多核处理器）。

  4. 阻塞状态（Blocked）：

    • 阻塞状态表示线程被暂停执行，通常是因为等待某个条件的满足或者在执行阻塞式I/O操作。
    • 当条件满足或I/O操作完成，线程将返回到就绪状态等待重新调度。

  5. 等待状态（Waiting）：

    • 等待状态表示线程主动地等待某个条件的满足，例如等待其他线程的通知。
    • 等待状态的线程可以通过wait()方法或类似的方法进入等待状态，只有其他线程的通知才能唤醒它。

  6. 计时等待状态（Timed Waiting）：

    • 类似于等待状态，但有一个超时时间。线程会在超时时间到达或者等待条件满足时被唤醒。
    • 例如，可以通过sleep()方法或带有超时参数的wait()方法使线程进入计时等待状态。

  7. 终止状态（Terminated）：

    • 终止状态表示线程执行完毕或者因异常而终止。
    • 一旦线程的run()方法执行完成，线程将进入终止状态。

这些线程状态反映了线程在不同阶段的行为和状态转换。线程的状态会随着时间的推移而变化，由Java虚拟机和操作系统的线程调度器来管理。程序员可以使用Java的多线程API来操作和控制线程的状态。

等待和阻塞区别

“阻塞”和”等待”是两个不同的线程状态，它们在多线程编程中有着不同的含义和用途：

  1. 阻塞（Blocked）：

    • 阻塞状态表示线程被暂停执行，通常是因为线程正在等待某个外部事件的发生，例如等待文件I/O、网络I/O、锁的释放等。
    • 在阻塞状态下，线程不会占用CPU资源，因为它不会被调度执行，直到等待的条件满足或者外部事件发生。

  2. 等待（Waiting）：

    • 等待状态表示线程主动地等待某个条件的满足，例如等待其他线程的通知。
    • 等待状态的线程通常通过调用wait()方法或类似的方法进入等待状态，它们会放弃CPU的执行权并等待被唤醒。
    • 线程通常在等待条件满足时被唤醒，然后返回到就绪状态等待被调度执行。

关键区别：

  • 原因：阻塞是由于外部事件或条件导致的，线程被暂停执行；等待是线程主动等待某个条件的满足，线程自愿进入等待状态。

  • 触发方式：阻塞通常由线程尝试获取锁或等待I/O等外部事件触发；等待通常由线程显式调用wait()等方法进入等待状态。

  • 返回条件：阻塞线程通常会在外部事件发生后或锁可用后被唤醒；等待线程通常在其他线程调用相应的notify()或notifyAll()方法来唤醒它们。

  • 用途：阻塞通常用于同步操作，例如等待锁的释放或等待I/O操作完成；等待通常用于线程间的协调和通信，等待某个线程通知其他线程可以继续执行。

需要注意的是，虽然阻塞和等待都暂停了线程的执行，但它们的使用场景和机制不同。了解这些状态的区别对于多线程编程非常重要，以确保正确地实现线程间的协作和同步。

限时等待和无线等待

“等待”和”限时等待”是两种不同的线程等待机制，它们在多线程编程中有着不同的用途和行为：

  1. 等待（Waiting）：

    • “等待”是一种线程等待机制，通常通过调用wait()方法或类似的方法来实现。
    • 在等待状态下，线程会进入无限期等待，直到其他线程显式地调用notify()或notifyAll()方法来唤醒它。
    • 等待通常用于线程间的协作和通信，一个线程等待其他线程的通知，以便执行特定的操作。

  2. 限时等待（Timed Waiting）：

    • “限时等待”是一种具有超时限制的等待机制，通常通过调用带有超时参数的方法来实现，例如wait(long timeout)、sleep(long millis)等。
    • 在限时等待状态下，线程会等待一段指定的时间，如果超过了超时时间，线程会自动唤醒并返回到就绪状态，继续执行后续操作。
    • 限时等待通常用于需要等待一段时间但不想无限期等待的情况，例如等待某个条件满足或等待一段时间后执行某个操作。

关键区别：

  • 等待是一种无限期等待的机制，线程会一直等待，直到其他线程显式唤醒它。
  • 限时等待是一种具有超时限制的等待机制，线程会等待一段时间，如果超过了指定的超时时间，线程会自动返回到就绪状态。
  • 限时等待通常用于需要等待一段时间或者希望设置最大等待时间的情况，以避免线程永久地阻塞。

Redis

Redis数据结构

Redis是一款内存数据库，支持多种数据结构，每种结构都有不同的用途和优势。以下是Redis支持的主要数据结构：

  1. 字符串（String）：字符串是最简单的数据结构，可以存储文本、整数或二进制数据。Redis的字符串是动态的，可以执行一系列的字符串操作，如拼接、截取、追加等。常用于缓存、计数器等场景。

  2. 哈希表（Hash）：哈希表是键值对的集合，类似于关联数组。每个哈希表可以存储多个字段和与之关联的值。适用于存储对象的属性或配置。

  3. 列表（List）：列表是一个有序的字符串元素集合，可以从两端进行插入和删除操作。适用于队列、消息队列等场景。

  4. 集合（Set）：集合是无序、唯一的字符串元素的集合，支持集合操作（交集、并集、差集等）。适用于存储不重复的元素。

  5. 有序集合（Sorted Set）：有序集合类似于集合，但每个元素都有一个分数，根据分数进行排序。适用于排行榜、范围查找等场景。

  6. 位图（Bitmap）：位图是一种特殊的字符串，它可以表示位的状态（0或1）。适用于记录用户在线状态、统计等。

  7. 超级日志（HyperLogLog）：超级日志是一种概率性的数据结构，用于估计一个集合中不重复元素的数量，而不需要存储每个元素。适用于基数统计场景。

  8. 地理位置（Geospatial）：Redis支持地理位置数据结构，可以存储地理坐标，并执行地理位置相关的操作，如计算距离、查找附近的位置等。

除了上述主要数据结构，Redis还支持一些其他数据结构和命令，如：

  • Bitfield：用于位操作的数据结构。
  • Stream：用于消息流处理的数据结构，支持消费者组、ACK等功能。
  • Lua脚本：Redis支持执行Lua脚本，可以在服务器端执行一系列操作。

这些数据结构的多样性使得Redis非常灵活，适用于各种不同的应用场景，从缓存到计数器，再到消息队列和地理位置服务。开发人员可以根据需求选择适当的数据结构来存储和操作数据。

ZSet底层实现

在Redis中，有序集合（Sorted Set，通常简称为ZSet）是一种特殊的数据结构，它具有以下特点：

  1. 每个元素都有一个分数（score）。
  2. 元素是唯一的，不允许重复。
  3. 元素根据分数进行排序。

ZSet的底层实现是通过使用跳表（Skip List）和哈希表（Hash Table）相结合的方式来实现的。这种设计使得ZSet在执行插入、删除、查找等操作时能够在O(log N)的复杂度内完成，同时允许高效地按分数进行排序。

下面是ZSet底层实现的简要描述：

  1. 跳表（Skip List）：跳表是一种有序数据结构，类似于链表，但具有多级索引。每个节点包含一个元素和多个指向下一级的指针。跳表允许快速查找、插入和删除元素，同时保持元素有序。在ZSet中，跳表用于存储元素，并根据元素的分数进行排序。

  2. 哈希表（Hash Table）：哈希表用于存储元素到分数的映射关系。它允许通过元素快速查找其对应的分数。在Redis的ZSet中，哈希表通常不会包含所有元素的映射，而是存储了一个部分元素的映射。这是为了节省内存，因为对于大型ZSet来说，不需要为每个元素都存储映射关系。

  3. 多级索引：跳表的多级索引允许高效地执行按分数排序的操作。通过跳表的索引，可以快速定位到某个分数范围内的元素，而无需遍历整个有序集合。

  4. 维护数据结构一致性：Redis通过在插入、删除、更新元素时同时更新跳表和哈希表来保持数据结构的一致性。这确保了ZSet的正确排序和快速查找。

总的来说，Redis的ZSet底层实现是一种高效的有序数据结构，它将跳表和哈希表结合在一起，以实现按分数有序存储元素，并支持高效的插入、删除和按分数范围查找操作。这使得ZSet非常适用于需要有序数据集合的场景，如排行榜、范围查找等。

Redis大key问题

Redis中的“大key问题”指的是存储了大量数据的单个键（key）。这个问题可能会导致多种性能和管理上的挑战，包括：

  1. 内存占用问题：大key占用大量内存。如果一个键的值非常大，那么在Redis中存储它会占用大量内存资源。这可能会导致内存不足，影响其他数据的存储和性能。

  2. 持久化问题：大key的持久化（如RDB快照或AOF日志）可能需要较长的时间，因为需要序列化和写入大量数据。这可能会影响Redis的快照备份和恢复性能。

  3. 数据传输问题：如果需要将数据从一个Redis实例传输到另一个实例（例如，进行数据迁移或复制），大key会导致传输过程变得更加耗时。

  4. 命令执行问题：对于大key的一些操作，如GET，可能会导致较长的延迟，因为Redis需要花费更多的时间来处理大的值。

为了解决大key问题，可以考虑以下策略：

  1. 拆分数据：将大key拆分为多个较小的键值对。例如，如果您有一个包含大量子元素的集合，可以将它分为多个小集合，并使用命名约定来管理它们。

  2. 分页查询：如果可能的话，考虑将数据分为多个页面或块，以便按需加载和查询。这对于大型列表或有序集合很有用。

  3. 压缩数据：如果数据是文本或可压缩的二进制数据，您可以考虑使用压缩算法来减小数据的大小。Redis支持对值进行压缩，以减少内存占用。

  4. 数据迁移：如果大key导致性能问题，可以考虑将大key的数据迁移到一个单独的Redis实例中，以隔离性能问题。

  5. 定期清理：如果不再需要大key，定期清理它们以释放内存和减少持久化时间。但请谨慎操作，以免意外删除重要数据。

总之，解决大key问题需要综合考虑性能、内存占用和数据管理的需求。适当的数据拆分、压缩和迁移策略可以帮助有效地管理大数据。

为什么redis根据key能快速定位value

Redis之所以能够根据键（key）快速定位到值（value），是因为它使用了一种高效的数据结构，即哈希表（Hash Table）。

哈希表是一种非常常见的数据结构，它通过将键映射到一个固定大小的数组索引来存储数据。在Redis中，哈希表的实现被称为字典（Dictionary），每个键都被映射到字典的一个槽位（slot），这使得对于大多数操作，Redis能够在O(1)的时间复杂度内执行，即常数时间复杂度。

以下是Redis如何根据键快速定位值的简要工作原理：

  1. 键的哈希计算：当您存储一个键值对时，Redis会首先计算键的哈希值。这个哈希值是一个整数，它唯一地标识了该键。

  2. 哈希表索引：Redis将计算出的哈希值映射到哈希表（字典）的一个槽位，该槽位是一个固定大小的数组的索引。哈希表的每个槽位都存储了一个指向键值对的指针。

  3. 定位值：一旦Redis知道了槽位的索引，它可以在O(1)的时间内访问该槽位并获取对应的键值对。这就是为什么Redis能够根据键快速定位值的原因。

需要注意的是，虽然大多数情况下哈希表提供了常数时间复杂度的性能，但在某些情况下，哈希冲突可能会导致性能下降。哈希冲突是指多个键计算出相同的哈希值，因此它们会映射到同一个槽位。为了解决冲突，Redis使用了一种开放地址法（open addressing）的技术，即将多个键值对存储在同一个槽位中的链表中。在处理冲突时，Redis会遍历链表以查找特定的键。

总之，Redis之所以能够根据键快速定位值，是因为它使用了高效的哈希表数据结构，该结构将键映射到内存中的特定位置，从而实现了快速的读取和存储操作。

如何用Redis实现热门数据排行榜

使用Redis实现热门数据排行榜是一个常见的应用场景，Redis的有序集合（Sorted Set）数据结构非常适合这个任务。以下是实现热门数据排行榜的基本步骤：

  1. 数据结构设计：

    • 创建一个有序集合（Sorted Set）用于存储排行榜数据。
    • 每个元素表示一个数据项，分数（score）表示该数据项的热度或排名，可以是浏览次数、点赞数等。
    • 有序集合中的元素是唯一的，通常使用一个唯一标识符（如文章ID、商品ID）作为元素的成员。

  2. 添加数据：

    • 当有新的数据项需要记录时，使用ZADD命令将数据项添加到有序集合中，指定数据项的分数。
    • 例如，如果有一篇文章被浏览了100次，可以使用ZADD将文章ID添加到有序集合中，并将分数设置为100。

  3. 查询排行榜：

    • 要查询排行榜，使用ZREVRANGE命令按分数从高到低获取有序集合中的元素。
    • 你可以指定要获取的排名范围，例如，获取前10名的数据项。

  4. 更新数据：

    • 当数据项的热度发生变化时，可以使用ZINCRBY命令来增加或减少数据项的分数。
    • 例如，每次有新的浏览或点赞时，使用ZINCRBY增加分数。

  5. 定时清理：

    • 为了保持排行榜的大小，可以定期使用ZREMRANGEBYRANK或ZREMRANGEBYSCORE命令删除排名较低的数据项。
    • 你可以设置一个阈值，例如，只保留前100名的数据项。

  6. 缓存数据（可选）：

    • 为了提高性能，可以将排行榜数据缓存在Redis中，定期更新缓存。
    • 这可以减轻数据库的负载，提供更快的响应时间。

这些步骤可以让你在Redis中轻松实现热门数据排行榜。排行榜可以用于展示热门文章、商品、用户等，是许多应用程序中常见的功能。使用Redis的有序集合，你可以高效地处理排行榜数据，并根据分数来实时排序和更新排名。

什么场景下使用Redis

高速读写，高可用。

Redis是一款高性能的开源内存数据库，它被广泛用于各种应用场景，包括但不限于以下情况：

  1. 缓存：

    • Redis最常见的用途是作为缓存层，用于存储频繁访问的数据，以减轻数据库负载。
    • 它支持设置过期时间，自动淘汰过期数据，并提供了快速的读写操作，使其成为理想的缓存解决方案。

  2. 会话管理：

    • Redis可以用于存储用户会话数据，以实现分布式会话管理。这对于构建具有横向扩展能力的Web应用程序非常有用。

  3. 队列和消息中间件：

    • Redis的列表数据结构非常适合用作队列，可以实现任务队列、消息队列等。
    • 发布/订阅模式可以用于构建消息中间件，支持实时事件处理。

  4. 计数器和排行榜：

    • Redis支持原子操作，因此可以用于实现计数器，例如统计网站的访问次数。
    • 它还可以用于构建排行榜，跟踪热门文章、商品等。

  5. 分布式锁：

    • Redis可以用于实现分布式锁，确保多个进程或线程在分布式环境下互斥地访问共享资源。

  6. 实时分析：

    • Redis的有序集合和位图等数据结构可以用于实时数据分析和统计。

  7. 地理空间应用：

    • Redis支持地理空间数据，可以用于构建地理位置相关的应用，如附近的商家查找、地图应用等。

  8. 缓存击穿和雪崩的防止：

    • 通过设置合适的过期时间和使用互斥锁，Redis可以用于防止缓存击穿和雪崩问题。

  9. 实时计时器：

    • Redis可以用于构建实时计时器，如游戏中的倒计时、秒杀活动等。

  10. 持久化：

    • Redis支持多种持久化方式，可以将数据持久化到磁盘，以防止数据丢失。

  11. 分布式系统协调：

    • Redis的分布式锁和发布/订阅功能可以用于分布式系统中的协调和通信。

  12. 实时缓存数据同步：

    • Redis可以用于实时将数据从主数据库同步到多个从数据库，以保持多个数据副本的一致性。

需要注意的是，虽然Redis在这些场景下非常有用，但它并不是通用数据库，不适合所有类型的数据存储需求。在选择Redis时，需要根据具体的应用需求和性能要求来决定是否合适。此外，Redis是一个内存数据库，数据大小受限于可用内存，因此需要合理规划内存资源。

AOF和RDB之间有何区别

AOF（Append-Only File）和RDB（Redis Database Backup）是Redis持久性选项，用于将数据写入磁盘以便持久化。它们有不同的工作原理和用途，以下是它们之间的主要区别：

  1. 工作原理：

    • AOF：AOF持久性通过将每个写操作追加到一个日志文件中来工作。这个日志文件包含了一系列的写操作，以文本格式记录。Redis重启时，会重新执行AOF文件中的写操作以还原数据状态。
    • RDB：RDB持久性通过周期性地将整个数据集保存到磁盘上的二进制文件中来工作。这个文件包含了数据的快照，以二进制格式存储。Redis可以使用这个文件在需要时完全还原数据状态。

  2. 文件格式：

    • AOF：AOF文件以文本格式记录写操作，这使得它对人类可读，并且可以用于恢复数据。但它通常比RDB文件更大。
    • RDB：RDB文件以二进制格式存储数据，它更加紧凑且占用更少的磁盘空间。

  3. 性能和恢复速度：

    • AOF：AOF持久性通常对于读写混合工作负载的性能影响较小。但在恢复大型AOF文件时，恢复速度可能会比较慢。
    • RDB：RDB持久性通常对于写工作负载的性能影响较小。而在恢复时，RDB文件通常比AOF文件恢复得更快，因为它是一个快照。

  4. 粒度：

    • AOF：AOF记录每个写操作，因此可以更细粒度地还原数据更改，但文件可能较大。
    • RDB：RDB文件是在固定时间间隔内保存的整个数据集的快照，因此恢复时只能恢复到最后一个快照的状态。

  5. 配置选项：

    • AOF：Redis允许配置不同的AOF持久性选项，包括将写操作同步到磁盘的频率（always、everysec等）。
    • RDB：RDB持久性通常是通过定期执行快照来配置的。

  6. 恢复点：

    • AOF：AOF文件通常具有更多的恢复点，因为它记录了每个写操作。
    • RDB：RDB文件通常只有最后一个快照的恢复点。

在实际应用中，通常会根据性能需求、恢复速度需求、磁盘空间等因素来选择AOF还是RDB，或者同时使用它们两者以充分发挥各自的优势。例如，可以使用AOF来实现持久性，同时定期创建RDB快照以提供更快的恢复速度。

RDB快照时间

Redis默认的RDB快照保存频率在配置文件（通常是redis.conf）中如下所示：

1
2
3
save 900 1
save 300 10
save 60 10000

这些配置表示：

  • save 900 1：如果在900秒（15分钟）内至少有1个键被修改，则执行RDB快照。
  • save 300 10：如果在300秒（5分钟）内至少有10个键被修改，则执行RDB快照。
  • save 60 10000：如果在60秒内至少有10000个键被修改，则执行RDB快照。

这是Redis的默认设置，它们的目的是在不同时间尺度上创建RDB快照，以便在不同的情况下进行数据恢复。根据你的应用需求和系统负载，你可以根据上述方法动态更改这些默认设置。

为什么Redis替代不了MySQL

关系型数据库和非关系型

事务，联表，索引。

Redis和MySQL各自有其特点和优势，但也存在一些限制和不足之处，这些限制通常会导致Redis不能完全替代MySQL的情况。以下是一些导致Redis不能替代MySQL的主要原因：

  1. 数据结构和复杂性：

    • Redis主要是一个键值存储系统，支持简单的数据结构，如字符串、哈希、列表等。但它不支持复杂的关系型数据结构，如表、外键、索引等，这在某些应用场景中是必需的。

  2. 数据持久性：

    • Redis通常将数据存储在内存中，虽然可以配置为支持持久性，但它的持久性不如MySQL稳定。MySQL是一个成熟的关系型数据库，提供可靠的数据持久性支持。

  3. 复杂查询：

    • Redis的查询能力相对有限，它不支持SQL查询，无法执行复杂的查询操作。MySQL提供强大的SQL查询功能，适用于复杂的数据分析和报告。

  4. 事务支持：

    • Redis支持事务，但是使用的是乐观锁机制，不支持复杂的事务处理和回滚。MySQL提供强大的ACID事务支持。

  5. 数据容量：

    • Redis的数据容量通常受限于可用的内存大小，而MySQL可以处理更大容量的数据，适用于大规模数据存储。

  6. 复制和高可用性：

    • MySQL具有成熟的复制和高可用性机制，可以实现主从复制、集群等复杂的架构。Redis在这方面的支持相对较弱，需要额外的工作来实现高可用性。

  7. 数据一致性：

    • Redis通常使用异步复制，可能会在网络分区或故障发生时出现数据不一致的情况。MySQL提供更强的数据一致性保证。

  8. 复杂性和成本：

    • Redis通常用于特定的用例，如缓存、计数器、实时消息等，而MySQL是一个通用的关系型数据库，适用于多种应用场景。在一些场景下，引入Redis会增加系统复杂性和成本。

虽然Redis在一些特定用例下非常有价值，但它并不是通用数据库，不能完全替代MySQL。在设计应用架构时，通常会根据具体需求和场景，合理选择和配置Redis和MySQL，以充分利用它们各自的优势。在很多应用中，Redis和MySQL是共存的，各司其职，共同构建高效和可靠的系统。

笔试

leetcode公共祖先 稍加修改，最深节点变成为指定两个节点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class Solution {
    public TreeNode lcaDeepestLeaves(TreeNode root) {
        return f(root).getKey();
    }

    private Pair<TreeNode, Integer> f(TreeNode root) {
        if (root == null) {
            return new Pair<>(root, 0);
        }

        Pair<TreeNode, Integer> left = f(root.left);
        Pair<TreeNode, Integer> right = f(root.right);

        if (left.getValue() > right.getValue()) {
            return new Pair<>(left.getKey(), left.getValue() + 1);
        }
        if (left.getValue() < right.getValue()) {
            return new Pair<>(right.getKey(), right.getValue() + 1);
        }
        return new Pair<>(root, left.getValue() + 1);
    }
}