链接题目来自牛客

我的每日一套面试题专栏，每天更新一起打卡

7.详细的说说Redis的数据类型

String 计数器 Set 集合交并差 共同关注 List 消息队列 ZSet 班级排名 Hash 对象

Stream 消息队列 GEO 查看附近的位置 HyperLogLog 以固定的较少内存实现不精确的去重计数，如网站UV统计 BitMap 位图，二值，签到，用户状态

8.说说Redis的持久化策略。

我的博客详解

Redis提供两种持久化策略：RDB和AOF。 AOF记录的是操作命令。如果要做恢复。得有执行命令的过程。 如果用RDB，那么直接把他读入内存就可以。所以RDB更快 RDB通过定时生成数据快照实现，适合快速恢复但可能丢失部分数据；AOF记录所有写操作命令，数据完整性更高但文件较大。此外，Redis支持混合持久化模式（AOF+RDB），结合两者优势实现高效备份与恢复。

9.讲一下乐观锁和悲观锁

我的博客详解

1. 思想： “乐观锁和悲观锁是解决并发数据竞争的两种不同思路，核心区别在于它们对冲突可能性的预期不同。”

2. 分别阐述：

   • 悲观锁： 先讲思想（“总是假设最坏的情况”），再讲实现（Java的synchronized、Lock；数据库的for update），然后说优缺点和场景。
   • 乐观锁： 先讲思想（“总是假设最好的情况”），再讲实现（版本号机制、CAS），然后说优缺点（一定要提到ABA问题及其解决方案）和场景。

3. 对比总结（画龙点睛）：

   特性	悲观锁	乐观锁
   核心思想	防患于未然	亡羊补牢
   实现方式	synchronized, Lock	版本号，CAS
   开销	大（上下文切换）	小（无阻塞，但冲突高时重试开销大）
   适用场景	写多读少，临界区大	读多写少
   数据库类比	SELECT ... FOR UPDATE	使用version字段

4. 结合实际（加分项）：

   • “比如在电商系统中，扣减商品库存这个操作，如果是个秒杀场景，写操作非常密集，用悲观锁可能更合适，因为冲突概率极高。如果是普通商品，浏览多购买少，用乐观锁性能会更好。”
   • “在Java的java.util.concurrent包中，很多并发容器（如ConcurrentHashMap）在实现时都大量使用了CAS这种乐观锁技术来保证线程安全的同时提升性能。”

10.从「敲下一个 URL」到「页面出现在屏幕」整条链路全景

DNS 主机到本地域名服务器递归查询，本地域名服务器，为了完成对客户端的递归查询承诺，向根、顶级、权限域名服务器发起查询，并接收来自它们的迭代查询响应，最终拿到域名对应的IP。

ARP协议，由目的IP得到目的MAC（路由器的MAC）

TCP三次握手建立连接

应用层：生成 HTTP 请求 传输层：TCP 分段，添加端口号 网络层：IP 封装，添加 IP 地址 数据链路层：添加 MAC 地址，形成帧 物理层：转换为比特流传输

由IP协议指路到达服务器

服务器再一层层拆开，拆到应用层，解析，响应经过HTTP应用层，TCP传输层，IP网络层，网络接口层等封装，返回客户端

浏览器解析渲染

TCP四次挥手断开连接 （连接管理：根据 HTTP 版本和头信息决定是否保持连接或关闭，现代HTTP/1.1默认长连接，可能不会立即断开）

11.如何在 UDP 之上实现可靠传输？

小林(QUIC)

12.消息队列如何保证顺序消费？

消息队列通过生产者按顺序发送至同一分区/队列，消费者单线程顺序处理实现。需确保同一业务标识的消息路由到相同分区，并限制分区仅被一个消费者消费。部分中间件支持全局顺序或局部顺序控制，同时需处理异常重试机制防止乱序。