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()
方法。在该方法中,您可以添加自定义逻辑(如记录日志、权限检查等),并最终调用目标对象的方法。代理对象会在执行目标方法时调用该方法。