【项目】仿牛客网社区开发第8章项目发布与总结 5 常见面试题

拼搏现实的明天。 2024-03-22 17:12 54阅读 0赞

### 【项目】仿牛客网社区开发 ###

#### 文章目录 ####

*   *  【项目】仿牛客网社区开发
     *   *  第8章 项目发布与总结
         *   *  5 常见面试题
             *   *  5.1 MySQL
                 *   *  5.1.1 存储引擎
                     *  5.1.2 事务
                     *  5.1.3 锁
                     *  5.1.4 索引
                 *  5.2 Redsi
                 *   *  5.2.1 数据类型
                     *  5.2.2 过期策略
                     *  5.2.3 淘汰策略
                     *  5.2.4 缓存穿透
                     *  5.2.5 缓存击穿
                     *  5.2.6 缓存雪崩
                     *  5.2.7 分布式锁
                 *  5.3 Spring
                 *   *  5.3.1 Spring IoC
                     *  5.3.2 Spring AOP
                     *  5.3.3 Spring MVC

![在这里插入图片描述][f07232b523d24e9dbbe682a8998ea441.png_pic_center]

#### 第8章 项目发布与总结 ####

##### 5 常见面试题 #####

1.  MySQL
    
    存储引擎、事务、锁、索引
2.  Redis
    
    数据类型、过期策略、淘汰策略、缓存穿透、缓存击穿、缓存雪崩、分布式锁
3.  Spring
    
    Spring IoC、Spring AOP、Spring MVC

###### 5.1 MySQL ######

###### 5.1.1 存储引擎 ######

![在这里插入图片描述][6026837c2a0444b393e1f9253f22c799.png_pic_center]

###### 5.1.2 事务 ######

**事务的特性**

*  原子性、一致性、隔离性、持久性

**事务的隔离性**

*  并发异常：第一类丢失更新、第二类丢失更新、脏读、不可重复读、幻读
 *  隔离级别：Read Uncommitted、Read Committed、Repeatable Read、Serializable

**Spring事务管理**

*  声明式事务
 *  编程式事务

###### 5.1.3 锁 ######

**范围**

*  表级锁：开销小、加锁快，发生锁冲突的概率高、并发度低，不会出现死锁。
 *  行级锁：开销大、加锁慢，发生锁冲突的概率低、并发度高，会出现死锁。

**类型（InnoDB）**

*  共享锁（S）：行级，读取一行；
 *  排他锁（X）：行级，更新一行；
 *  意向共享锁（IS）：表级，准备加共享锁；
 *  意向排他锁（IX）：表级，准备加排他锁；
 *  间隙锁（NK）：行级，使用范围条件时，
    
    对范围内不存在的记录加锁。一是为了防止幻读，二是为了满足恢复和复制的需要。

![在这里插入图片描述][32c193bb76aa40b7935be1e088a344a6.png_pic_center]

**加锁**

*  增加行级锁之前，InnoDB会自动给表加意向锁；
 *  执行DML语句时，InnoDB会自动给数据加排他锁；
 *  执行DQL语句时
    
     *  共享锁（S）：SELECT … FROM … WHERE … LOCK IN SHARE MODE;
     *  排他锁（X）：SELECT … FROM … WHERE … FOR UPDATE;
     *  间隙锁（NK）：上述SQL采用范围条件时，InnoDB对不存在的记录自动增加间隙锁。

**死锁**

*  场景
    
     *  事务1: UPDATE T SET … WHERE ID = 1; UPDATE T SET … WHERE ID = 2;
     *  事务2: UPDATE T SET … WHERE ID = 2; UPDATE T SET … WHERE ID = 1;
 *  解决方案
    
    1.  一般InnoDB会自动检测到，并使一个事务回滚，另一个事务继续；
    2.  设置超时等待参数 innodb\_lock\_wait\_timeout；
 *  避免死锁
    
    1.  不同的业务并发访问多个表时，应约定以相同的顺序来访问这些表；
    2.  以批量的方式处理数据时，应事先对数据排序，保证线程按固定的顺序来处理数据；
    3.  在事务中，如果要更新记录，应直接申请足够级别的锁，即排他锁；

**悲观锁（数据库）**

**乐观锁（自定义）**

1.  版本号机制
    
    UPDATE … SET …,VERSION=\#\{version+1\} WHERE … AND VERSION=$\{version\}
2.  CAS算法（Compare and swap） 是一种无锁的算法，该算法涉及3个操作数（内存值V、旧值A、新值B），当V等于A时， 采用原子方式用B的值更新V的值。该算法通常采用自旋操作，也叫自旋锁。它的缺点是：
    
     *  ABA问题：某线程将A该为B，再改回A，则CAS会误认为A没被修改过。
     *  自旋操作采用循环的方式实现，若加锁时间长，则会给CPU带来巨大的开销。
     *  CAS只能保证一个共享变量的原子操作。

###### 5.1.4 索引 ######

B+Tree（InnoDB）

*  数据分块存储，每一块称为一页；
 *  所有的值都是按顺序存储的，并且每一个叶子到根的距离相同；
 *  非叶节点存储数据的边界，叶子节点存储指向数据行的指针；
 *  通过边界缩小数据的范围，从而避免全表扫描，加快了查找的速度。

![在这里插入图片描述][6ad2d090904843d29ebca49291bbcc8b.png_pic_center]

###### 5.2 Redsi ######

###### 5.2.1 数据类型 ######

![在这里插入图片描述][786c5e5478e049a4bad6668e77e6414b.png_pic_center]

###### 5.2.2 过期策略 ######

Redis会把设置了过期时间的key放入一个独立的字典里，在key过期时并不会立刻删除它。

Redis会通过如下两种策略，来删除过期的key：

*  惰性删除
    
    客户端访问某个key时，Redis会检查该key是否过期，若过期则删除。
 *  定期扫描
    
    Redis默认每秒执行10次过期扫描（配置hz选项），扫描策略如下：
    
    1.  从过期字典中随机选择20个key；
    2.  删除这20个key中已过期的key；
    3.  如果过期的key的比例超过25%，则重复步骤1；

###### 5.2.3 淘汰策略 ######

当Redis占用内存超出最大限制（maxmemory）时，可采用如下策略（maxmemory-policy）， 让Redis淘汰一些数据，以腾出空间继续提供读写服务：

*  noeviction：对可能导致增大内存的命令返回错误（大多数写命令，DEL除外）；
 *  volatile-ttl：在设置了过期时间的key中，选择剩余寿命（TTL）最短的key，将其淘汰；
 *  volatile-lru：在设置了过期时间的key中，选择最少使用的key（LRU），将其淘汰；
 *  volatile-random：在设置了过期时间的key中，随机选择一些key，将其淘汰；
 *  allkeys-lru：在所有的key中，选择最少使用的key（LRU），将其淘汰；
 *  allkeys-random：在所有的key中，随机选择一些key，将其淘汰；

![在这里插入图片描述][9fb3e378d1e7427f81d498a7dd85e9c3.png_pic_center]

**LRU算法**

*  维护一个链表，用于顺序存储被访问过的key。
 *  在访问数据时，最新访问过的key将被移动到表头，
 *  即最近访问的key在表头，最少访问的key在表尾。

**近似LRU算法（Redis）**

*  给每个key维护一个时间戳，淘汰时随机采样5个key， 从中淘汰掉最旧的key。如果还是超出内存限制，则 继续随机采样淘汰。
 *  优点：比LRU算法节约内存，却可以取得非常近似的效果。

###### 5.2.4 缓存穿透 ######

![在这里插入图片描述][3534053fae3247c8a4b8fe7c75b5c95f.png_pic_center]

*  场景
    
     *  查询根本不存在的数据，使得请求直达存储层， 导致其负载过大，甚至宕机。
 *  解决方案
    
    1.  缓存空对象
        
        存储层未命中后，仍然将空值存入缓存层。 再次访问该数据时，缓存层会直接返回空值。
    2.  布隆过滤器
        
        将所有存在的key提前存入布隆过滤器，在访问缓存层之前， 先通过过滤器拦截，若请求的是不存在的key，则直接返回空值。

###### 5.2.5 缓存击穿 ######

*  场景
    
    一份热点数据，它的访问量非常大。在其缓存失效瞬间，大量请求直达存储层，导致服务崩溃。
 *  解决方案
    
    1.  加互斥锁
        
        对数据的访问加互斥锁，当一个线程访问该数据时，其他线程只能等待。
        
        这个线程访问过后，缓存中的数据将被重建，届时其他线程就可以直接从缓存取值。
    2.  永不过期
        
        不设置过期时间，所以不会出现上述问题，这是“物理”上的不过期。
        
        为每个value设置逻辑过期时间，当发现该值逻辑过期时，使用单独的线程重建缓存。

###### 5.2.6 缓存雪崩 ######

*  场景
    
    由于某些原因，缓存层不能提供服务，导致所有的请求直达存储层，造成存储层宕机。
 *  解决方案
    
    1.  避免同时过期 设置过期时间时，附加一个随机数，避免大量的key同时过期。
    2.  构建高可用的Redis缓存 部署多个Redis实例，个别节点宕机，依然可以保持服务的整体可用。
    3.  构建多级缓存 增加本地缓存，在存储层前面多加一级屏障，降低请求直达存储层的几率。
    4.  启用限流和降级措施 对存储层增加限流措施，当请求超出限制时，对其提供降级服务。

###### 5.2.7 分布式锁 ######

**场景**

修改时，经常需要先将数据读取到内存，在内存中修改后再存回去。在分布式应用中，可能多个进程 同时执行上述操作，而读取和修改非原子操作，所以会产生冲突。增加分布式锁，可以解决此类问题。

**基本原理**

*  同步锁：在多个线程都能访问到的地方，做一个标记，标识该数据的访问权限。
 *  分布式锁：在多个进程都能访问到的地方，做一个标记，标识该数据的访问权限。

**实现方式**

1.  基于数据库实现分布式锁；
2.  基于Redis实现分布式锁；
3.  基于Zookeeper实现分布式锁；

**Redis实现分布式锁的原则**

1.  安全属性：独享。在任一时刻，只有一个客户端持有锁。
2.  活性A：无死锁。即便持有锁的客户端崩溃或者网络被分裂，锁仍然可以被获取。
3.  活性B：容错。只要大部分Redis节点都活着，客户端就可以获取和释放锁。

**单Redis实例实现分布式锁**

1.  获取锁使用命令：
    
        SET resource_name my_random_value NX PX 30000
    
    NX：仅在key不存在时才执行成功。PX：设置锁的自动过期时间。
2.  通过Lua脚本释放锁：
    
        if redis.call(“get”,KEYS[1]) == ARGV[1] then 
            return redis.call(“del”, KEYS[1]) 
        else return 0 end
    
    可以避免删除别的客户端获取成功的锁: A加锁 -> A阻塞 -> 因超时释放锁 -> B加锁 -> A恢复 -> 释放

**多Redis实例实现分布式锁**

Redlock算法，该算法有现成的实现，其Java版本的库为Redisson。

1.  获取当前Unix时间，以毫秒为单位。
2.  依次尝试从N个实例，使用相同的key和随机值获取锁，并设置响应超时时间。如果服务器没有在 规定时间内响应，客户端应该尽快尝试另外一个Redis实例。
3.  客户端使用当前时间减去开始获取锁的时间，得到获取锁使用的时间。当且仅当大多数的Redis节 点都取到锁，并且使用的时间小于锁失效时间时，锁才算取得成功。
4.  如果取到了锁，key的真正有效时间等于有效时间减去获取锁使用的时间。
5.  如果获取锁失败，客户端应该在所有的Redis实例上进行解锁。

###### 5.3 Spring ######

###### 5.3.1 Spring IoC ######

Bean的作用域

![在这里插入图片描述][8285da0c765f48c0a71d96cdc4039323.png_pic_center]

###### 5.3.2 Spring AOP ######

AOP的术语  
![在这里插入图片描述][b886d983c4d7464b9b920df2dd0c0223.png_pic_center]

###### 5.3.3 Spring MVC ######

![在这里插入图片描述][ea4288b202804e0dae325edd94064c88.png_pic_center]

完结撒花，感谢老师！

![在这里插入图片描述][3d4f0a904afe4244b78c18e993395256.png_pic_center]

[f07232b523d24e9dbbe682a8998ea441.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/63e0a9dfae9a4d7394e7c0f5ce7121cc.png
[6026837c2a0444b393e1f9253f22c799.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/79bd298667834ad0b5051e4f9ef73b51.png
[32c193bb76aa40b7935be1e088a344a6.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/cdea1b54bb6e48c8a628dd8b43e592db.png
[6ad2d090904843d29ebca49291bbcc8b.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/e77177a425fd44bcb00cd690e5cca84e.png
[786c5e5478e049a4bad6668e77e6414b.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/8b72a83e1e024ddc914ae1b22b3618aa.png
[9fb3e378d1e7427f81d498a7dd85e9c3.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/83d8641325c04ec189814ebec16a8a14.png
[3534053fae3247c8a4b8fe7c75b5c95f.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/2a11e57374ad437ab52ebeb1878eaf70.png
[8285da0c765f48c0a71d96cdc4039323.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/3c58cc997064460f9040944a5a0f308c.png
[b886d983c4d7464b9b920df2dd0c0223.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/c34ce2ec32254deab87430bb5aa95d28.png
[ea4288b202804e0dae325edd94064c88.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/996bc838dc754ad08eb79238f3a2345c.png
[3d4f0a904afe4244b78c18e993395256.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/a043a829ccb94b0ebaadac7d66953c5c.png