1、讲解一下Redis 中的内存淘汰机制、有哪些内存淘汰策略？
Redis是一个高性能的内存数据库，但是内存是有限的资源，当redis中的内存占用达到预设值，淘汰机制是就会剔除一些键值对，以释放内存空间。
noeviction 策略：当 Redis 的内存空间达到最大限制时，直接返回错误，不做任何淘汰操作。这种策略下，如果出现内存不足的情况，Redis 会停止接受写操作，直到有足够的内存空间可用。
volatile-lru 策略：该策略会优先淘汰设置了过期时间的 key 中最近最少使用（Least Recently Used）的 key，以腾出空间。如果没有过期的 key，就转而使用 LRU 策略淘汰最近最少使用的 key。
volatile-ttl 策略：该策略会优先淘汰设置了过期时间的 key 中 TTL（Time To Live）值较小的 key，以腾出空间。
volatile-random 策略：该策略会在设置了过期时间的 key 中，随机选择一个 key 进行淘汰。
allkeys-lru 策略：该策略会优先淘汰最近最少使用的 key，包括所有类型的 key（包括已过期的和未过期的）。
allkeys-random 策略：该策略会在所有 key 中，随机选择一个 key 进行淘汰。
其中，volatile-lru 和 volatile-ttl 策略主要用于处理缓存数据，而 allkeys-lru 和 allkeys-random 策略则主要用于处理持久化数据。
Redis中的内存淘汰机制是用来处理内存不足时需要剔除一些键值对，以释放内存空间。具体而言，Redis内存淘汰机制使用了以下两个策略：
主动淘汰策略
主动淘汰策略是指当Redis预设的内存限制被达到时，就会触发主动淘汰策略。常见的主动淘汰策略有以下几种：
volatile-lru：从已设置过期时间的数据集（即带有 TTL 过期时间（Time To Live） 的 key）中挑选最近最少使用的数据淘汰。
volatile-ttl：从已设置过期时间的数据集（即带有 TTL 的 key）中挑选即将过期的数据淘汰。
volatile-random：从已设置过期时间的数据集（即带有 TTL 的 key）中任意选择数据淘汰。
allkeys-lru：从所有数据集中挑选最近最少使用的数据淘汰。
allkeys-random：从所有数据集中任意选择数据淘汰。
，volatile-lru 和 volatile-ttl 策略主要用于处理缓存数据
被动淘汰策略
被动淘汰策略是指当Redis在执行某些读写操作时，发现该操作会导致Redis的内存超出预设的内存限制时，则会自动触发被动淘汰策略。被动淘汰策略与主动淘汰策略相似，只是策略的触发条件不同。常见的被动淘汰策略有以下几种：
noeviction：不允许淘汰数据，直接返回错误信息。
allkeys-lru：从所有数据集中挑选最近最少使用的数据淘汰。
allkeys-random：从所有数据集中任意选择数据淘汰。
allkeys-lru 和 allkeys-random 策略则主要用于处理持久化数据。
总的来说，Redis提供多种内存淘汰策略，但主要的目的是为了在内存占用过高的情况下，尽量保持Redis的正常运行。
2、Spring 中的 BeanFactory 和 ApplicationContext 有什么区别和联系？
在 Spring 中，BeanFactory 和 ApplicationContext 都是 Spring 容器的实现。它们都是 Spring 框架中的核心部分，用于管理和创建对象的实例。以下是它们的区别和联系：
区别：
BeanFactory 是 Spring 容器的基础接口，定义了 Spring 容器最基本的功能，即 Bean 的实例化、配置、定位和管理等。它是 Spring 框架中 IoC 的核心接口，提供了最基本的 IoC 功能。
ApplicationContext 是 BeanFactory 的子接口，它继承了 BeanFactory 的所有功能，并且还提供了其他的一些高级特性，如事件传播、国际化、资源加载、AOP 等。
加载方式：BeanFactory是延迟加载（Lazy Load：懒加载）的，只有在第一次使用Bean时才会进行初始化，而ApplicationContext是预先加载（Pre-load）的，当容器启动时就会进行初始化并实例化所有的单例Bean。
容器级别：BeanFactory是IoC容器的基础设施，用于管理和配置Bean，而ApplicationContext是高级容器，相对于BeanFactory来说更加完善，提供了更多的功能和扩展性。
联系：
BeanFactory 和 ApplicationContext 都是 Spring 容器的实现，它们的主要功能都是管理和创建 Bean 实例。
ApplicationContext 继承了 BeanFactory 的所有功能，因此 ApplicationContext 具备了 BeanFactory 的所有功能。
ApplicationContext 还提供了其他的一些高级特性，如事件传播、国际化、资源加载、AOP 等，这些功能都是在 BeanFactory 基础上进行扩展的。
在实际应用中，ApplicationContext 是最常用的 Spring 容器接口，因为它提供了更多的功能和扩展性，可以更好地满足企业级应用的需求。
在使用过程中，通常我们更倾向于使用ApplicationContext，因为ApplicationContext提供了更加丰富的功能，并且在应用启动时会自动进行初始化并预加载所有的单例Bean，可以避免在第一次使用Bean时造成的延迟加载（懒加载）带来的性能问题。
总的来说，BeanFactory 是 Spring IoC 容器的基础接口，提供了最基本的 IoC 功能；而 ApplicationContext 是 BeanFactory 的子接口，提供了更多的高级特性和扩展功能，是企业级应用的理想选择。
3、MySQL 支持哪些存储引擎？默认使用哪个？MyISAM 和 InnoDB 引擎有什么区别，如何选择？
MySQL 支持多种不同的存储引擎，每种存储引擎都有其特定的优缺点和适用场景。以下是 MySQL 支持的一些存储引擎：
InnoDB：MySQL 5.5 版本及以后的默认存储引擎，支持事务、行级锁、外键约束、崩溃恢复和数据一致性等特性，适合高并发和事务性的应用场景。
MyISAM：MySQL 5.5 版本及以前的默认存储引擎，不支持事务、行级锁和外键约束等特性，适合读密集、写少的应用场景。
MEMORY：将表数据存储在内存中，数据读取速度快，但容易出现内存溢出问题，适合临时表和缓存表等应用场景。
NDB Cluster：支持分布式存储和高可用性，适合高并发和高可靠性的应用场景。
Archive：支持高压缩比的存储，适合存储历史数据和归档数据等应用场景。
CSV：以纯文本格式存储数据，适合存储数据量较小的数据集。
MySQL 默认使用的存储引擎是 InnoDB。
MyISAM 和 InnoDB 引擎的主要区别在于特性和性能：
MyISAM 不支持事务，只支持表级锁，因此不适合多用户并发写入的场景，但是读取速度很快，适合于读密集型的应用场景。而 InnoDB 支持事务和行级锁，能够保证数据的一致性和高并发性能，适合于高并发和事务性应用场景。
MyISAM 不支持外键，而 InnoDB 支持外键约束，能够保证数据的完整性和一致性。
MyISAM 表的存储格式为非聚簇索引，因此不支持主键的聚集，而 InnoDB 则支持聚簇索引，因此可以提高查询性能。
MyISAM 不支持崩溃恢复，而 InnoDB 支持崩溃恢复和数据一致性。
综上所述，如果应用场景需要支持事务、行级锁、外键约束、崩溃恢复和数据一致性等特性，那么选择 InnoDB 存储引擎更为适合；如果应用场景是读密集型的应用，可以选择 MyISAM 存储引擎。但需要注意，MySQL 5.5 版本以后默认使用的存储引擎是 InnoDB。
