面试第三期

面试题第三期

1.为什么选用redis代替session

在分布式环境下，用户的请求可能会被负载均衡到其他的服务器，从而导致无法获取之前的session，要在多台服务器上共享session实现数据同步，会增加系统的复杂性，此时考虑使用redis会更好
在项目中我采用了hash的类型来存储token，此时token作为外部键的一部分，用户信息作为值，设置了过期时间为30分中。同时利用拦截器对过期时间进行续期。
redis的读取速率要高于session适合高频访问的业务场景，而我的项目中有优惠劵的秒杀业务就很适合。

2.Transactional失效的场景

Transactional只适用于public方法
自调用，没有通过spring代理绕过了事务拦截器，解决方法有通过依赖注入自身来解决，或者获取代理对象
抛出除了 RuntimeException 和 Error的其他异常，此时可以通过给transactional注解配置异常类型来解决
未启用事务注解或者数据库存在多数据源
在内部捕获了异常却没有抛出

3.你知道redisson的那几种锁

可重入锁，同一个线程可以多次获取同一把锁，不会造成自己把自己锁到外面的情形
红锁，同时向多个redis节点申请锁，只有超过半数的锁被释放才会真正的释放，可以利用redis集群来实现
联锁，红锁的低配版，只有所有的锁被释放才算真正的释放
公平锁，先到的线程会先拿到锁

4.redisson的看门狗

你可以把它看成一个锁的保镖，假如现在你有一个业务需要执行40秒，锁默认30秒的过期时间，此时看门狗每隔过期时间的1/3时间会检查一次，如果锁还被持有就会续期，直到释放锁。要想看门狗生效不能设置固定的过期时间，当锁释放或者线程结束时看门狗也会自动生效。

Cookie 是存储在用户浏览器端的一个小型数据文件，用于跟踪和保存用户的状态信息。

主要用于保持用户登录状态、跟踪用户行为、存储用户偏好等。

存储在浏览器端。

Session：

Session 是服务器端保存用户状态的机制，每个用户会话都有一个唯一的 Session ID。

主要用于跟踪用户在服务器上的状态信息，例如登录状态和购物车内容。

存储在服务器端，然后对应的 Session ID 通过 Cookie 保存在客户端浏览器中。

Token：

Token 本质是一种加密的字符串，用于身份验证和授权，可以包含用户信息和权限，用于验证用户身份或授权访问资源。

认证后，后端服务会返回 Token，存储在客户端（浏览器或移动应用中），后续客户端访问服务端需要带上这个 Token。

它们之间使用场景区别：

Cookie：主要用于客户端状态的简单存储和追踪。
Session：用于服务器端的复杂状态管理，特别是在需要存储大量会话数据时。
Token：用于无状态的认证和授权，特别是在分布式和跨域环境下。

简单来说，Cookie 和Session 更适合用于单次会话的认证和状态管理，而 Token 更适合用于跨会话的认证和状态管理。

6.跳表

现在有一个十分长的链表，你想要查询某个数据，你需要遍历来查找它，此时时间花费会很大，聪明的你想到了如果链表已经有序了，我们在众多节点里边挑选几个作为类似索引的东西，每当你查询时我们比对一下就可以缩小区间来加快速度。此时聪明的你又又又想到了，如果我查找的数据特别靠后，抽取的节点还是太多怎么办，这时候我们将原来抽取的节点再进行一次抽取，形成一个更广泛的索引便可迅速定位到对应区间。

7.为什么 Redis Zset 用跳表实现而不是红黑树？B+树？

1）相比红黑树而言实现简单

跳表基于多层链表实现，通过概率算法动态生成索引层级，没有左旋右旋等操作，逻辑理解上更为简单。而红黑树需要复杂的平衡操作（旋转）来维护结构，代码实现复杂度较高，理解门槛更高。

2）范围查询更高效

范围查询跳表可以通过 O(logn) 的时间复杂度定位起点，然后在原始的链表中往后遍历即可。

红黑树从结构上不支持范围查询。

3）结构更灵活

跳表的层数和节点结构是动态的，可以基于概率分布调整层数，灵活的适应不同的数据量（数据量大层级可以多一些，小的话层级少一些）。

红黑树则无法调整。

8.mvcc

MVCC（Multi-Version Concurrency Control，多版本并发控制）是一种并发控制机制，允许多个事务同时读取和写入数据库，而无需互相等待，从而提高数据库的并发性能。

在 MVCC 中，数据库为每个事务创建一个数据快照。每当数据被修改时，MySQL 不会立即覆盖原有数据，而是生成新版本的记录。每个记录都保留了对应的版本号或时间戳。

多版本之间串联起来就形成了一条版本链，这样不同时刻启动的事务可以无锁地获得不同版本的数据(普通读)。此时读(普通读)写操作不会阻塞。

写操作可以继续写，无非就是会创建新的数据版本（但只有在事务提交后，新版本才会对其他事务可见。未提交的事务修改不会影响其他事务的读取），历史版本记录可供已经启动的事务读取。