1、实习介绍，看机会原因，项目。2、redis常用的数据结构，项目中用过哪几种，业务中使用的场景3、redis的hash怎么实现的，rehash过程讲一下 和JavaHashMap的rehash有什么区别？redis cluster怎么做到高可用的？4、redis集群和哨兵机制有什么区别？redis的持久化机制了解吗？遇到过redis的hotkey吗？怎么处理的？5、redis是单线程的吗？单线程为什么还这么快？讲一讲redis的内存模型？6、简单说一下RabbitMQ的工作原理？如何保证消息的顺序执行？7、卡夫卡了解吗？和RabbitMQ有什么区别？8、tcp/udp简单说下两者的区别？tcp为什么要三次握手和四次挥手？两次握手可以不？会有什么问题？tcp怎么保证有序传输的9、讲下tcp的快速重传和拥塞机制，知不知道time_wait状态，这个状态出现在什么地方，有什么用？10、http与https区别？https是怎么做到安全的？11、有没有了解过协程？说下协程和线程的区别？用过哪些linux命令？如查看内存使用、网络情况？12、你了解哪些设计模式啊。挑一个熟悉的讲讲？（除了单例模式）在项目中有用过设计模式吗？讲讲你怎么用的？简单说一下适配器模式和装饰器模式？13、索引的常见实现方式有哪些，有哪些区别?14、MySQL的存储引擎有哪些，有哪些区别？InnoDB使用的是什么方式实现索引，怎么实现的？说下聚簇索引和非聚簇索引的区别？15、raft算法的基本流程？raft算法里面如果出现脑裂怎么处理？16、paxos和zookeeper的zab算法，他们之前有啥区别？17、如果我是想一个人的姓名一样就认为他们equal，能现场写下我们怎么重写equals吗？如果两个对象，一个是cat，一个是dog，我们认为他们的name属性一样就一样，怎么重写equals18、还有点时间，写个题吧leetcode406.根据身高重建队列假设有打乱顺序的一群人站成一个队列。每个人由一个整数对(h, k)表示，其中h是这个人的身高，k是排在这个人前面且身高大于或等于h的人数。 编写一个算法来重建这个队列。注意：总人数少于1100人。示例输入:[[7,0], [4,4], [7,1], [5,0], [6,1], [5,2]]输出:[[5,0], [7,0], [5,2], [6,1], [4,4], [7,1]]

国企硬件小厂卖AP、AC的，中午通知面试下午就面试...比较简单，所以大家应该都答得上，我学历大概也许可能是最低的因为是非IT专业在职，基本是裸考，应该是寄了。1.自我介绍 介绍了一下读的嵌入式相关专业，在电信工作懂一点AP、AC，采集器在自己的项目里面写的很多2.在电信做什么项目 网络维护、小程序小工具之类的轻量开发（其实根本没有开发，纯牛马）3.在实习公司用的什么技术栈、工作产出4.那其实Golang写的东西还是不多嘛？ 表示自己以前写java，go也写了7-8个东西了，下班之后自己写的5.TCP/IP 四层协议，以及每一层在硬件的应用和常用协议 半年没背面试题了，答成OSI七层协议了.....

1.消息队列（RabbitMQ）保证消息顺序性 如何保证同一订单的消息有序消费？2.单线程消费 vs 多线程消费（如何提升吞吐量仍保证顺序）？3.分片（Hash到同一队列）是否可行？4.Redis数据结构应用 项目中使用了哪些Redis数据结构（如Hash、Set、ZSet）？5.购物车数据存储：Hash vs String（JSON）的选择依据？6.String的不可变性优势场景？7.线程池参数设计 微服务场景下（如Tomcat），如何设置线程池参数（核心线程数、最8.大线程数、队列容量、拒绝策略）？9.参考因素：CPU核心数、请求响应时间（200ms）、QPS预估？10.拒绝策略：丢弃最老任务时，客户端收到的HTTP状态码11.MySQL优化（EXPLAIN分析） 影响查询性能的关键因素（全表扫描、索引覆盖、索引失效、回表、索引下推）？12.多线程与锁 ConcurrentHashMap如何保证线程安全（分段锁/CAS）？13.线程安全的定义：为什么HashMap线程不安全？ConcurrentHashMap如何解决？14.多线程put冲突时（如同时写8和10），最终结果如何？15.JVM/集合 无直接提问，但涉及线程池和集合的线程安全实现。16.Redis高可用 集群模式（哨兵、分片）？主节点宕机后从节点如何接管（优先级、同步延迟）？17.故障检测机制（哨兵 vs 分片集群）？18.Linux命令 查看CPU占用最高的进程（top）？19.查看端口占用（netstat/ss）？20.日志搜索（grep）？21.中间件22.消息队列对比 RabbitMQ vs Kafka的适用场景？算法题：未排序数组中第K大元素

一、Redis 热 key：互联网平台的 “流量噩梦”在电商秒杀、爆款商品上线等场景中，海量用户请求会瞬间集中涌向存储对应信息的单个 Redis 节点，这就是 Redis 热 key 问题。就像一座设计合理的桥梁，某一车道突然涌入 100 万辆车，不仅会导致该车道瘫痪，还可能引发整座桥梁坍塌 —— 热 key 带来的连锁反应远比想象中严重：数据层面：承载热 key 的 Redis 节点因过载被打挂后，其负责的缓存数据全部丢失，进而引发可怕的缓存雪崩；应用层面：用户持续刷新却无法加载页面，服务直接陷入不可用状态，严重影响用户体验与业务连续性。很多人会误以为 “简单扩容就能解决问题”，但实际这是一...