每日一面 day03
Q：介绍一下MySQL的三种日志（redo，undo，bin）
Redo Log 和 Undo Log 是存储引擎 InnoDB 层面实现的，Bin Log 是 MySQL 层面实现的。
下面是三种日志的简要介绍：
-
Redo Log：保证事务的持久性（Durability）。Redo Log 记录了已提交事务的所有更改，以便在发生故障时可以恢复数据。
- Redo Log 是一种顺序写入的日志，写入速度比随机写入要快。
- 当事务对数据库进行修改时，首先将更改写入 Redo Log，而不是直接写入数据文件。这样，即使系统崩溃，也可以使用 Redo Log 中的记录来恢复数据。
- Redo Log 在 MySQL 中以“日志组”的形式存在，通常在 InnoDB 存储引擎中使用。
特点：
- Redo Log 是物理日志，记录的是数据页的物理变化。
- 在数据库崩溃后进行恢复时非常重要，确保已提交事务的数据不会丢失。
-
Undo Log：支持事务的原子性（Atomicity）和一致性（Consistency），以及实现 MVCC（多版本并发控制）。
- Undo Log 记录了事务对数据的所有修改的反向操作，以便在事务回滚时能够恢复到事务开始前的状态。
- 当一个事务执行更新操作时，系统会在 Undo Log 中记录下修改前的值，这样在需要回滚时就可以使用这些信息恢复数据。
- Undo Log 是逻辑日志，记录的是对数据的逻辑变化。
特点：
- Undo Log 使得 MySQL 能够实现事务的回滚，确保在发生错误时能够恢复到一致性状态
- 在实现 MVCC 时，Undo Log 允许读取未提交数据的事务在特定条件下读取数据的历史版本
-
Bin Log：用于数据的复制和恢复。Binlog 记录了所有对数据库的更改操作（包括 DDL 和 DML 语句），而不是数据的实际内容
- 当执行任何更新操作时，MySQL 会将该操作以事件的形式记录在 Binlog 中。这样可以将这些操作应用到其他数据库实例，实现数据复制。
- Binlog 可以配置为不同的格式，如 Statement、Row 和 Mixed 模式，决定了日志中记录的信息类型。
- Binlog 是主从复制的基础，主库会将 Binlog 发送给从库
特点：
- Binlog 是逻辑日志，记录的是 SQL 语句及其变更，而不是具体的物理数据
- 在数据恢复中，Binlog 可以用来重放操作，将数据库恢复到某个特定时间点
- Binlog 的存在使得 MySQL 支持数据的备份和恢复，以及高可用性集群的实现
Q：介绍一下Spring 中的 @Autowired和@Resource
**@Resource和@Autowired**的对比：
-
都是用来自动装配的，都可以作用在属性字段或方法上
-
@Autowired：- 默认通过**类型（byType）**进行注入。
- 如果找到多个同类型的 bean，会抛出
NoUniqueBeanDefinitionException。 - 如果使用了
@Qualifier或@Primary注解，可以明确指定要注入的具体 bean，从而帮助解决歧义。@Qualifier可以用来基于名称选择特定 bean，但不会在byType后尝试byName。
-
@Resource：-
默认先通过**名称（byName）**查找对应的 bean。
-
如果找不到匹配的名称，则根据**类型（byType）**进行查找。
-
如果
byType找到多个同类型的 bean，会抛出NoUniqueBeanDefinitionException。 -
如果在名称和类型查找后都没有找到 bean，抛出
NoSuchBeanDefinitionException。
-
Q：Spring 中用到了那些设计模式？
- 工厂模式：如
BeanFactory和AppicationContext，通过工厂模式创建和管理Bean对象 - 单例模式：Bean的默认作用域。
- 代理模式：AOP 和 一些动态代理的实现，如JDK接口实现动态代理，CIGLIB继承实现动态代理，以及
@Transcational也会使用代理模式创建代理对象。 - 模板方法：如
JdbcTemplate、RedisTemplate以及Mybaytis - Spring 整合的sqlSessionTemplate等 - 观察者模式：Spring的事件驱动模型
- 策略模式：Spring的
Resource接口的实现，允许根据不同的资源类型（系统、url、类路径）来加载 - 适配器模式：Spring MVC的
HandlerAdapter允许不同类型的处理器（如Controller或HttpRequestHandler）能够处理 HTTP 请求 - 装饰器模式：Spring 的
BeanPostProcessor允许在Bean初始化前后进行一些额外的逻辑处理
Q：你了解java是怎么实现代理模式的吗？（jdk原生和cglib）
对于动态代理， JDK 动态代理 vs CGLIB 动态代理
| 特性 | JDK 动态代理 | CGLIB 动态代理 |
|---|---|---|
| 代理对象 | 只能代理实现了InvocationHandler接口的类 | 可以代理没有实现接口的类 |
| 实现方式 | 基于反射和接口 | 基于继承和字节码生成 |
| 性能 | 对于接口的代理，性能较好 | 生成代理类需要更多资源，但一次生成后性能更优 |
| 使用场景 | 适用于接口代理 | 适用于没有接口的类的代理 |
| 限制 | 只能代理接口 | 目标类不能是 final，方法不能是 final |
CGLIB动态代理 原理：通过继承生成代理类，使用字节码生成库（如 ASM）来动态生成目标类的子类，并在子类中覆盖目标类的方法。代理对象实际上是目标对象的子类，所有对代理对象方法的调用都会被重定向到代理逻辑。
JDK原生动态代理原理：通过接口代理对象，当通过代理对象调用方法时，JDK 实际上会执行 InvocationHandler 中的 invoke() 方法。在该方法中，您可以添加自定义逻辑（如记录日志、权限检查等），并最终调用目标对象的方法。代理对象会在执行目标方法时调用该方法。