应聘后有通知是好事，要不然就是“回去等通知”，就再没有消息了。

大家好，我是皇子

可是资本市场上，有消息未必都是好消息。

这不，最近阿里巴巴传来一个好消息、一个坏消息（要先听哪个？）

好消息是：7月25日下午，阿里巴巴全球速卖通（广州）跨境电商产业园签约揭牌仪式在巨大国际产业园国际会议中心举行。

坏消息是：韩国个人信息监管机构据调查，阿里巴巴全球速卖通将韩国客户的个人信息提供给其注册卖家，用于运送订购的产品。在此过程中，超过18万海外卖家（主要是中国卖家）收到了韩国消费者的个人信息。

2024年07月25日周四时，韩国个人信息监管机构对阿里巴巴旗下电商平台全球速卖通（AliExpress）处以近19.8亿韩元（约合人民币1030万元）罚款，原因是该平台在未通知韩国用户的情况下向约18万海外卖家泄露了他们的个人信息。

说巧不巧，一个好消息和一个坏消息在同一天发生。

另外据消息称，高德地图将于10月中旬左右从北苑的龙湖搬走，搬到刚刚腾空的望京阿里中心。

好了，以上是关于阿里巴巴最近资讯。

那我们下面分享一位阿里巴巴后端社招二面苦等3天后，终于收到HR通知喜提一份Offer的面经。

难度中规中矩，整个面试比较看重过去的开发经验，会对项目挖的比较深（很多工具要了解实现原理），更多的是项目的一些细节。

这里还是一样，我下面罗列了一些面经供大家参考。

Redis

系统的缓存热点问题一般怎么处理？

系统的缓存热点问题通常发生在某些非常热门的数据项被大量并发请求访问时，这可能导致缓存服务器过载或者成为瓶颈。

常用做法是：在系统启动时或者预计会出现高并发之前，提前将热点数据加载到缓存中，这叫缓存预热。

另外还可以利用分布式缓存来分摊请求负载，分布式缓存还可以提供的自动故障转移和数据冗余。

最后我们根据经验或者对热点数据进行监控后，对热点数据的访问进行限流，避免单一数据项受到过多的并发访问。

日常开发中，redis都是怎么用的？

1、缓存

我们一提到redis，自然而然就想到缓存，国内外中大型的网站都离不开缓存。合理的利用缓存，比如缓存热点数据，不仅可以提升网站的访问速度，还可以降低数据库DB的压力。并且，Redis相比于memcached，还提供了丰富的数据结构，并且提供RDB和AOF等持久化机制，强的一批。

2、分布式锁

几乎每个互联网公司中都使用了分布式部署，分布式服务下，就会遇到对同一个资源的并发访问的技术难题，如秒杀、下单减库存等场景。用java(synchronize或者reentrantlock)或者golang(sync.Mutex或者sync.RMutex或者channel实现的锁)本地锁肯定是不行的。

如果是并发量不大话，使用数据库的悲观锁、乐观锁来实现没啥问题。
但是在并发量高的场合中，利用数据库锁来控制资源的并发访问，会影响数据库的性能。实际上，可以用Redis的setnx+嵌入lua脚本执行检查和删除redis Key来实现分布式的锁。
除此之外，还可以使用官方提供的 RedLock 分布式锁实现。

3、社交网络

赞/踩、粉丝、共同好友/喜好、推送、下拉刷新等是社交网站的必备功能，由于社交网站访问量通常比较大，而且传统的关系型数据不太适保存这种类型的数据，Set 可以实现交集、并集等操作，从而实现共同好友等功能。

4、消息队列

消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。

消息队列

Kafka怎么保证消息不丢、重复发了怎么办?

这里实际考官问得是两个问题，需要拆分开来回答，一个是消息不丢失、避免消息重复。

针对消息不丢失的处理办法有：

持久化：Kafka 将消息写入磁盘上的日志文件，这意味着即使 Broker 重启，消息也不会丢失。
**生产者确认机制 (Acks)**：生产者发送消息时，可以通过配置 acks 参数来控制消息的确认机制。

acks=0: 生产者不等待任何 Broker 的确认就返回。这会导致最快的数据传输速度，但没有消息丢失保护。
acks=1: 只要 Leader 接收到消息就返回确认。如果 Leader 在确认后但 Follower 复制前失败，则消息可能丢失。
acks=all 或 acks=-1: 所有的 In-Sync Replicas (ISR) 都必须确认接收到消息才返回。这是最安全的方式，但可能会影响吞吐量。

重试机制:生产者可以配置 retries 参数来指定发送失败时的重试次数（重试机制可以用来处理暂时性的网络故障或其他短暂问题）。
幂等性：Kafka 0.10.0 版本开始支持幂等生产者，这意味着即使消息重传，Kafka 也能保证消息的顺序性和唯一性。这通过维护一个生产者 ID 和序列号来实现，Broker 会检测重复的消息并丢弃它们。

而针对避免消息重复的处理办法，可以利用上面提到的支持幂等生产者保证消息生产时不重复。

另外关于消费端也有处理办法，与其对应的是幂等性消费：在业务逻辑层面实现幂等性，即使同一消息被多次消费，也要确保业务操作只执行一次。

zk在Kafka中的应用？

1、集群管理:

Broker 注册: 当 Kafka 的 Broker 启动时，它会在 ZooKeeper 中注册自己，并且会定期发送心跳信息来表明它的存活状态。
Broker 状态跟踪: ZooKeeper 跟踪每个 Broker 的状态，包括哪些 Broker 是活动的、哪些已经失效等。
Controller 选举: Kafka 需要一个特殊的 Broker 作为 Controller，它负责管理集群的元数据变化。Controller 的选举是通过 ZooKeeper 的临时节点竞争机制完成的。

2、元数据管理:

Topic 和 Partition 信息: ZooKeeper 存储了关于 Topic 和 Partition 的元数据信息，包括每个 Topic 的分区数、每个分区的 Leader 和 Follower 等。
Partition 重新分配: 当 Broker 加入或离开集群时，ZooKeeper 可以帮助重新分配 Partition 的 Leader 和 Follower，以保持数据的可用性和冗余度。

3、一致性保证：ZooKeeper 的事务日志和快照机制保证了元数据的一致性和持久性。

4、配置管理：ZooKeeper 可以用来存储集群的一些配置信息，比如默认的 Topic 配置。

5、服务发现（Broker 发现）：Producer 和 Consumer 需要知道 Broker 的位置。ZooKeeper 提供了一种方式来发现集群中的 Broker。

网络

网络IO模型有哪些？

阻塞IO模型（BIO）
非阻塞IO模型（NIO）
IO多路复用模型（select、poll、epoll）
信号驱动IO模型
异步IO模型（AIO）

select和epoll的区别？

这里顺便把select、poll、epoll 加上，select、poll 和 epoll都可以用于实现多路复用，但它们的阻塞特性略有不同。

select

select同时监听多个fd。一旦内核数据准备好了，select就返回可读状态，这时候应用进程发起recvfrom系统调用去读数据。

select的缺点在于：

监听的IO数最多为1024个。
采用轮询的方式来监视多个文件描述符的状态，只知道有I/O准备好，却不知道是哪个IO，因此select返回可读状态后需要遍历的方式确定具体那个IO的内核数据准备好了。

poll

poll在select上进行改进，最大监听数无限，但其它相同。

epoll

epoll采用事件驱动， epoll先通过一个epoll_ctl()来注册一个fd，一旦基于某个fd就绪，操作系统就会采用回调机制，激活这个fd，调用epoll_wait()的进程便得到通知（当应用程序调用 epoll_wait 函数时，如果没有任何文件描述符准备好进行 I/O 操作，epoll_wait 函数不会阻塞，而是立即返回，应用程序可以继续执行其他任务。）。这里去掉了遍历文件fd的操作。

epoll使用内存映射mmap（共享内容），不需要将fd数据从用户空间拷贝到内核空间（内存拷贝），因此效率比select和poll高。

所以区别是：

	select	poll	epoll
底层	数组	链表	红黑树和双链表
fd获取方式	遍历	遍历	事件回调
复杂度	O(N)	O(N)	O(1)
最大监听数	1024	无限	无限
执行效率	高	高	最高
fd数据拷贝	每次调用select，需要将的数据从用户空间拷贝到内核空间	每次调用poll，需要将fd数据从用户空间拷贝到内核空间	使用内存映射mmap，不需要将fd数据从用户空间拷贝到内核空间

MySQL

存储引擎应该怎么选择

大多数情况下，使用默认的InnoDB就够了。如果要提供提交、回滚和恢复的事务安全（ACID 兼容）能力，并要求实现并发控制，InnoDB 就是比较靠前的选择了。
如果数据表主要用来插入和查询记录，则 MyISAM 存储引擎提供较高的处理效率。

说说 MySQL 的基础架构

客户端：最上层的服务并不是MySQL所独有的，大多数基于网络的客户端/服务器的工具或者服务都有类似的架构。比如连接处理、授权认证、安全等等。
Server层：大多数MySQL的核心服务功能都在这一层，包括查询解析、分析、优化、缓存以及所有的内置函数（例如，日期、时间、数学和加密函数），所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等。
存储引擎层：第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。Server层通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。

项目

项目的QPS、吞吐量如何？

根据实际情况介绍即可，对于ToB业务，系统的QPS和吞吐量一般高不到哪去，更多的是安全性、可靠性。而ToC业务的QPS和吞吐量，往往性能要求会更高。

要回答好这个问题，首先我们需要知道什么是QPS和吞吐量。

QPS: 指系统每秒钟能够处理的查询或请求的数量。
吞吐量: 通常指单位时间内系统能够处理的工作量总量，可以是请求数量、数据量等。

明白概念后，就可以正式介绍项目的背景、业务场景、性能测试工具和指标测试结果了。

关于测试工具：JMeter 依然是软件测试领域的主流，是一个开源的性能测试工具，主要用于测试静态和动态资源的性能。支持多种协议，如 HTTP, HTTPS, FTP, JDBC, JMS, LDAP, SOAP, WebSocket 等；可以模拟大量的并发用户；支持多种数据源，如 CSV 文件、数据库等；可以生成详细的测试报告。
指标测试结果：结合前面相关的上下文信息，如果能提供具体的数字那更好了。

并发量与QPS虽然存在密切关系，但是不是一个概念。

并发量关注的是系统能够同时处理多少请求。

QPS关注的是系统在单位时间内能够处理多少请求。

例如，一个高并发的系统如果处理每个请求的时间很短，那么它可以有很高的QPS；反之，如果处理请求的时间很长，那么即使并发量很高，QPS也可能不高。

过去经历中怎么应对高并发或高性能场景的？

1、介绍项目有关高并发或高性能的具体业务。

2、架构设计上介绍关于负载均衡、缓存机制、数据库优化等方面的内容。

3、具体编码（多进程、多线程、多协程）是如何实现的。

以上，觉得有用点亮【赞与在看】让我们总能披荆斩棘，挑战自我。

ITPub博客

苦等3天阿里巴巴，终于收到通知了