面试官：面阿里P7是吧？消息队列这些我必问！

点击“开发者技术前线”&＃xff0c;选择“星标????”

在看|星标|留言,  真爱

回复“666”&＃xff0c;获取一份专属大礼包

作者&＃xff1a;mousycoder

segmentfault.com/a/1190000021054802

消息队列连环炮

1. 项目里怎么样使用 MQ 的&＃xff1f;

2. 为什么要使用消息队列&＃xff1f;

3. 消息队列有什么优点和缺点&＃xff1f;

4. kafka,activemq,rabbitmq,rocketmq 都有什么去呗&＃xff1f;

5. 如何保证消息队列高可用&＃xff1f;

6. 如何保证消息不被重复消费&＃xff1f;

7. 如何保证消息的可靠性传输&＃xff1f;

8. 如何保证消息的顺序性&＃xff1f;

9. 写一个消息队列架构设计&＃xff1f;

消息队列技术选型

解决的问题&＃xff1a;

• 解耦

• 异步

• 削峰

不用 MQ 系统耦合场景

A 系统产生了一个比较关键的数据&＃xff0c;很多系统需要 A 系统将数据发过来&＃xff0c;强耦合&＃xff08;B,C,D,E 系统可能参数不一样、一会需要一会不需要数据&＃xff0c;A 系统要不断修改代码维护&＃xff09;

A 系统还要考虑 B、C、D、E 系统是否挂了&＃xff0c;是否访问超时&＃xff1f;是否重试&＃xff1f;

使用 MQ 系统解耦场景

1. 维护这个代码&＃xff0c;不需要考虑人家是否调用成功&＃xff0c;失败超时

2. 如果新系统需要数据&＃xff0c;直接从 MQ 里消费即可&＃xff0c;如果某个系统不需要这条数据就取消对 MQ 消息的消费即可。

总结&＃xff1a;通过一个 MQ 的发布订阅消息模型&＃xff08;Pub/Sub&＃xff09;, 系统 A 跟其他系统就彻底解耦了。

不用 MQ 同步高延迟请求场景

一般互联网类的企业&＃xff0c;对用户的直接操作&＃xff0c;一般要求每个请求都必须在 200ms以内&＃xff0c;对用户几乎是无感知的。

使用 MQ 进行异步化之后的接口性能优化

提高高延时接口

没有用 MQ 时高峰期系统被打死的场景

高峰期每秒 5000 个请求&＃xff0c;每秒对 MySQL 执行 5000 条 SQL&＃xff08;一般MySQL每秒 2000 个请求差不多了&＃xff09;&＃xff0c;如果MySQL被打死&＃xff0c;然后整个系统就崩溃&＃xff0c;用户就没办法使用系统了。但是高峰期过了之后&＃xff0c;每秒钟可能就 50 个请求&＃xff0c;对整个系统没有任何压力。

使用 MQ 进行削峰的场景

5000 个请求写入到 MQ 里面&＃xff0c;系统 A 每秒钟最多只能处理 2000 个请求&＃xff08;MySQL 每秒钟最多处理 2000 个请求&＃xff09;&＃xff0c;系统 A 从 MQ 里慢慢拉取请求&＃xff0c;每秒钟拉取 2000 个请求。MQ&＃xff0c;每秒钟 5000 个请求进来&＃xff0c;结果只有 2000 个请求出去&＃xff0c;结果导致在高峰期&＃xff08;21小时&＃xff09;&＃xff0c;可能有几十万甚至几百万的请求积压在 MQ 中&＃xff0c;这个是正常的&＃xff0c;因为过了高峰期之后&＃xff0c;每秒钟就 50 个请求&＃xff0c;但是系统 A 还是会按照每秒 2000 个该请求的速度去处理。只要高峰期一过&＃xff0c;系统 A 就会快速的将积压的消息给解决掉。

算一笔账&＃xff0c;每秒积压在 MQ 里消息有 3000 条&＃xff0c;一分钟就会积压 18W 条消息&＃xff0c;一个小时就会积压 1000 万条消息。等高峰期一过&＃xff0c;差不多需要 1 个多小时就可以把 1000W 条积压的消息给处理掉

架构中引入 MQ 后存在的问题

• 系统可用性降低

MQ 可能挂掉&＃xff0c;导致整个系统崩溃

• 系统复杂性变高

可能发重复消息&＃xff0c;导致插入重复数据&＃xff1b;消息丢了&＃xff1b;消息顺序乱了&＃xff1b;系统 B,C,D 挂了&＃xff0c;导致 MQ 消息积累&＃xff0c;磁盘满了&＃xff1b;

• 一致性问题

本来应该A,B,C,D 都执行成功了再返回&＃xff0c;结果A,B,C 执行成功 D 失败

Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点

建议&＃xff1a;中小型公司 RabbitMQ 大公司&＃xff1a;RocketMQ 大数据实时计算&＃xff1a;Kafka

消息队列高可用

RabbtitMQ 高可用

RabbitMQ有三种模式&＃xff1a;单机模式 、普通集群模式、镜像集群模式

• 单机模式

demo级

• 普通集群模式&＃xff08;非高可用&＃xff09;

队列的元数据存在于多个实例中&＃xff0c;但是消息不存在多个实例中&＃xff0c;每次多台机器上启动多个 rabbitmq 实例&＃xff0c;每个机器启动一个。

• 优点&＃xff1a;可以多个机器消费消息&＃xff0c;可以提高消费的吞吐量

• 缺点&＃xff1a;可能会在 rabbitmq 内部产生大量的数据传输 &＃xff1b;可用性基本没保障&＃xff0c;queue 所在机器宕机&＃xff0c;就没办法消费了

没有高可用性可言

• 镜像集群模式&＃xff08;高可用&＃xff0c;非分布式&＃xff09;

队列的元数据和消息都会存在于多个实例中&＃xff0c;每次写消息到 queue的时候&＃xff0c;都会自动把消息到多个实例的 queue 里进行消息同步。也就 是每个节点上都有这个 queue 的一个完整镜像&＃xff08;这个 queue的全部数据&＃xff09;。任何一个节点宕机了&＃xff0c;其他节点还包含这个 queue的完整数据&＃xff0c;其他 consumer 都可以到其他活着的节点上去消费数据都是 OK 的。

缺点&＃xff1a;不是分布式的&＃xff0c;如果这个 queue的数据量很大&＃xff0c;大到这个机器上的容量无法容纳 。

开启镜像集群模式方法&＃xff1a;管理控制台&＃xff0c;Admin页面下&＃xff0c;新增一个镜像集群模式的策略&＃xff0c;指定的时候可以要求数据同步到所有节点&＃xff0c;也可以要求同步到指定数量的节点&＃xff0c;然后你再次创建 queue 的时候 &＃xff0c;应用这个策略&＃xff0c;就 会自动将数据同步到其他的节点上去。

• Kafka 高可用架构

broker进程就是kafka在每台机器上启动的自己的一个进程。每台机器&＃43;机器上的broker进程&＃xff0c;就可以认为是 kafka集群中的一个节点。

你创建一个 topic,这个topic可以划分为多个 partition,每个 partition 可以存在于不同的 broker 上&＃xff0c;每个 partition就存放一部分数据。

这就是天然的分布式消息队列&＃xff0c;也就是说一个 topic的数据&＃xff0c;是分散放在 多个机器上的&＃xff0c;每个机器就放一部分数据。

分布式的真正含义是每个节点只放一部分数据&＃xff0c;而不是完整数据&＃xff08;完整数据就是HA、集群机制&＃xff09;
Kafka 0.8版本之前是没有 HA 机制的&＃xff0c;任何一个 broker 宕机了&＃xff0c;那么就缺失一部分数据。

Kafka 0.8以后&＃xff0c;提供了 HA 机制&＃xff0c;就是 replica 副本机制。

每个 partition的数据都会同步到其他机器上&＃xff0c;形成自己的多个 replica 副本。然后所有 replica 会选举一个 leader。那么生产者、消费者都会和这个 leader 打交道&＃xff0c;然后其他 replica 就是 follow。写的时候&＃xff0c;leader 负责把数据同步到所有 follower上去&＃xff0c;读的时候就直接读 leader 上的数据即可。

如果某个 broker宕机了&＃xff0c;刚好也是 partition的leader&＃xff0c;那么此时会选举一个新的 leader出来&＃xff0c;大家继续读写那个新的 leader即可&＃xff0c;这个就 是所谓的高可用性。

leader和follower的同步机制&＃xff1a;

写数据的时候&＃xff0c;生产者就写 leader&＃xff0c;然后 leader将数据落地写本地磁盘&＃xff0c;接着其他 follower 自己主动从 leader来pull数据。一旦所有 follower同步好数据了&＃xff0c;就会发送 ack给 leader&＃xff0c;leader收到所有 follower的 ack之后&＃xff0c;就会返回写成功的消息给生产者。

消费的时候&＃xff0c;只会从 leader去读&＃xff0c;但是只有一个消息已经被所有 follower都同步成功返回 ack的时候&＃xff0c;这个消息才会被消费者读到。

消息队列重复数据

MQ 只能保证消息不丢&＃xff0c;不能保证重复发送

Kafka 消费端可能出现的重复消费问题

每条消息都有一个 offset 代表 了这个消息的顺序的序号&＃xff0c;按照数据进入 kafka的顺序&＃xff0c;kafka会给每条数据分配一个 offset,代表了这个是数据的序号&＃xff0c;消费者从 kafka去消费的时候&＃xff0c;按照这个顺序去消费&＃xff0c;消费者会去提交 offset&＃xff0c;就是告诉 kafka已经消费到 offset&＃61;153这条数据了 &＃xff1b;zk里面就记录了消费者当前消费到了 offset &＃61;几的那条消息&＃xff1b;假如此时消费者系统被重启&＃xff0c;重启之后&＃xff0c;消费者会找kafka&＃xff0c;让kafka把上次我消费到的那个地方后面的数据继续给我传递过来。

在这里&＃xff0c;我为大家准备了一份2020年最新最全的《Java面试题及答案V3.0》&＃xff0c;这套电子书涵盖了诸多后端技术栈的面试题和答案&＃xff0c;相信可以帮助大家在最短的时间内复习Java后端的大多数面试题&＃xff0c;从而拿到自己心仪的offer。

截了张图&＃xff0c;大家可以仔细查看左边的菜单栏&＃xff0c;覆盖的知识面真的很广&＃xff0c;而且质量都很不错。

资料获取方法

1. 扫描下方二维码

2. 后台回复关键词&＃xff1a;Java核心整理

重复消息原因&＃xff1a;&＃xff08;主要发生在消费者重启后&＃xff09;

消费者不是说消费完一条数据就立马提交 offset的&＃xff0c;而是定时定期提交一次 offset。消费者如果再准备提交 offset&＃xff0c;但是还没提交 offset的时候&＃xff0c;消费者进程重启了&＃xff0c;那么此时已经消费过的消息的 offset并没有提交&＃xff0c;kafka也就不知道你已经消费了 offset&＃61; 153那条数据&＃xff0c;这个时候kafka会给你发offset&＃61;152,153,154的数据&＃xff0c;此时 offset &＃61; 152,153的消息重复消费了

保证 MQ 重复消费幂等性

幂等&＃xff1a;一个数据或者一个请求&＃xff0c;给你重复来多次&＃xff0c;你得确保对应的数据是不会改变的&＃xff0c;不能出错。
思路&＃xff1a;

• 拿数据要写库&＃xff0c;首先检查下主键&＃xff0c;如果有数据&＃xff0c;则不插入&＃xff0c;进行一次update

• 如果是写 redis&＃xff0c;就没问题&＃xff0c;反正每次都是 set &＃xff0c;天然幂等性

• 生产者发送消息的时候带上一个全局唯一的id,消费者拿到消息后&＃xff0c;先根据这个id去 redis里查一下&＃xff0c;之前有没消费过&＃xff0c;没有消费过就处理&＃xff0c;并且写入这个 id 到 redis&＃xff0c;如果消费过了&＃xff0c;则不处理。

• 基于数据库的唯一键

保证 MQ 消息不丢

MQ 传递非常核心的消息&＃xff0c;比如&＃xff1a;广告计费系统&＃xff0c;用户点击一次广告&＃xff0c;扣费一块钱&＃xff0c;如果扣费的时候消息丢了&＃xff0c;则会不断少钱&＃xff0c;积少成多&＃xff0c;对公司是一个很大的损失。

RabbitMQ可能存在的数据丢失问题

• 生产者写消息的过程中&＃xff0c;消息都没有到 rabbitmq&＃xff0c;在网络传输过程中就丢了。或者消息到了 rabbitmq&＃xff0c;但是人家内部出错了没保存下来。

• RabbitMQ 接收到消息之后先暂存在主机的内存里&＃xff0c;结果消费者还没来得及消费&＃xff0c;RabbitMQ自己挂掉了&＃xff0c;就导致暂存在内存里的数据给搞丢了。

• 消费者消费到了这个消费&＃xff0c;但是还没来得及处理&＃xff0c;自己就挂掉了&＃xff0c;RabbitMQ 以为这个消费者已经处理完了。

问题 1解决方案&＃xff1a;

事务机制&＃xff1a;&＃xff08;一般不采用&＃xff0c;同步的&＃xff0c;生产者发送消息会同步阻塞卡住等待你是成功还是失败。会导致生产者发送消息的吞吐量降下来&＃xff09;

    channel.txSelect
try {//发送消息
} catch(Exception e){channel.txRollback;//再次重试发送这条消息
} channel.txCommit;


confirm机制&＃xff1a;&＃xff08;一般采用这种机制&＃xff0c;异步的模式&＃xff0c;不会阻塞&＃xff0c;吞吐量会比较高&＃xff09;

• 先把 channel 设置成 confirm 模式

• 发送一个消息到 rabbitmq

• 发送完消息后就不用管了

• rabbitmq 如果接收到了这条消息&＃xff0c;就会回调你生产者本地的一个接口&＃xff0c;通知你说这条消息我已经收到了

• rabbitmq 如果在接收消息的时候报错了&＃xff0c;就会回调你的接口&＃xff0c;告诉你这个消息接收失败了&＃xff0c;你可以再次重发。

public void ack(String messageId){}public void nack(String messageId){//再次重发一次这个消息
}


问题 2 解决方案&＃xff1a;

持久化到磁盘

• 创建queue的时候将其设置为持久化的&＃xff0c;这样就可以保证 rabbitmq持久化queue的元数据&＃xff0c;但是不会持久化queue里的数据

• 发送消息的时候将 deliveryMode 设置为 2&＃xff0c;将消息设置为持久化的&＃xff0c;此时 rabbitmq就会将消息持久化到磁盘上去。必须同时设置 2 个持久化才行。

• 持久化可以跟生产者那边的 confirm机制配合起来&＃xff0c;只有消息被持久化到磁盘之后&＃xff0c;才会通知生产者 ack了 &＃xff0c;所以哪怕是在持久化到磁盘之前 &＃xff0c;rabbitmq挂了&＃xff0c;数据丢了&＃xff0c;生产者收不到 ack&＃xff0c;你也可以自己重发。

缺点&＃xff1a;可能会有一点点丢失数据的可能&＃xff0c;消息刚好写到了 rabbitmq中&＃xff0c;但是还没来得及持久化到磁盘上&＃xff0c;结果不巧&＃xff0c; rabbitmq挂了&＃xff0c;会导致内存里的一点点数据会丢失。更多面试题&＃xff1a;面试鹅厂&＃xff0c;我被虐的体无完肤

问题 3 解决方案&＃xff1a;

原因&＃xff1a;消费者打开了 autoAck机制&＃xff08;消费到一条消息&＃xff0c;还在处理中&＃xff0c;还没处理完&＃xff0c;此时消费者自动 autoAck了&＃xff0c;通知 rabbitmq说这条消息已经消费了&＃xff0c;此时不巧&＃xff0c;消费者系统宕机了&＃xff0c;那条消息丢失了&＃xff0c;还没处理完&＃xff0c;而且 rabbitmq还以为这个消息已经处理掉了&＃xff09;

解决方案&＃xff1a;关闭 autoAck,自己处理完了一条消息后&＃xff0c;再发送 ack给 rabbitmq,如果此时还没处理完就宕机了&＃xff0c;此时rabbitmq没收到你发的ack消息&＃xff0c;然后 rabbitmq 就会将这条消息重新分配给其他的消费者去处理。

Kafka 可能存在的数据丢失问题

消费端弄丢数据

原因&＃xff1a;消费者消费到那条消息后&＃xff0c;自动提交了 offset&＃xff0c;kafka以为你已经消费好了这条消息&＃xff0c;结果消费者挂了&＃xff0c;这条消息就丢了。

例子&＃xff1a;消费者消费到数据后写到一个内存 queue里缓存下&＃xff0c;消息自动提交 offset&＃xff0c;重启了系统&＃xff0c;结果会导致内存 queue 里还没来得及处理的数据丢失。

解决方法&＃xff1a;kafka会自动提交 offset&＃xff0c;那么只要关闭自动提交 offset&＃xff0c;在处理完之后自己手动提交&＃xff0c;可以保证数据不会丢。但是此时确实还是会重复消费&＃xff0c;比如刚好处理完&＃xff0c;还没提交 offset&＃xff0c;结果自己挂了&＃xff0c;此时肯定会重复消费一次 &＃xff0c;做好幂等即可。

Kafka 丢掉消息

原因&＃xff1a;kafka 某个 broker 宕机&＃xff0c;然后重新选举 partition 的 leader时&＃xff0c;此时其他的 follower 刚好还有一些数据没有同步&＃xff0c;结果此时 leader挂了&＃xff0c;然后选举某个 follower成 leader之后&＃xff0c;就丢掉了之前leader里未同步的数据。

例子&＃xff1a;kafka的leader机器宕机&＃xff0c;将 follower 切换为 leader之后&＃xff0c;发现数据丢了
解决方案&＃xff1a;&＃xff08;保证 kafka broker端在 leader发生故障&＃xff0c;或者leader切换时&＃xff0c;数据不会丢&＃xff09;

• 给 topic设置 replication.factor &＃xff0c;这个值必须大于 1&＃xff0c;保证每个 partition 必须至少有 2 个副本

• 在 kafka 服务端设置 min.insync.replicas 参数&＃xff0c;这个值必须大于 1&＃xff0c;这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系&＃xff0c;没掉队&＃xff0c;这样才能确保 leader挂了还有一个follower&＃xff0c;保证至少一个 follower能和leader保持正常的数据同步。

• 在 producer 端设置 acks &＃61;all&＃xff0c;这个是要求每条数据&＃xff0c;必须是写入所有 replica 之后&＃xff0c;才能认为是写成功了。否则会生产者会一直重试&＃xff0c;此时设置 retries &＃61; MAX&＃xff08;很大的重试的值&＃xff09;,要求一旦写入失败&＃xff0c;就卡在这里&＃xff08;避免消息丢失&＃xff09;

• kafka 生产者丢消息

按 2 的方案设置了 ack &＃61;all&＃xff0c;一定不会丢。它会要求 leader 接收到消息&＃xff0c;所有的 follower 都同步 到了消息之后&＃xff0c;才认为本次写成功。如果没满足这个条件&＃xff0c;生产者会无限次重试 。

消息队列顺序性

背景&＃xff1a;mysql binlog 同步的系统&＃xff0c;在mysql里增删改一条数据&＃xff0c;对应出来了增删改 3 条binlog&＃xff0c;接着这 3 条binlog发送到 MQ 里面&＃xff0c;到消费出来依次执行&＃xff0c;起码是要保证顺序的吧&＃xff0c;不然顺序变成了 删除、修改、增加。日同步数据达到上亿&＃xff0c;mysql->mysql,比如大数据 team&＃xff0c;需要同步一个mysql库&＃xff0c;来对公司的业务系统的数据做各种复杂的操作。

场景&＃xff1a;

• rabbitmq,一个queue,多个consumer&＃xff0c;这不明显乱了

• kafka,一个topic&＃xff0c;一个partition,一个consumer&＃xff0c;内部多线程&＃xff0c;这不也乱了

RabbitMQ 消息顺序错乱

RabbitMQ 如何保证消息顺序性

需要保证顺序的数据放到同一个queue里

Kafka 消息顺序错乱

写入一个 partition中的数据一定是有顺序的。

生产者在写的时候&＃xff0c;可以指定一个 key&＃xff0c;比如订单id作为key,那么订单相关的数据&＃xff0c;一定会被分发到一个 partition中区&＃xff0c;此时这个 partition中的数据一定是有顺序的。Kafka 中一个 partition 只能被一个消费者消费。消费者从partition中取出数据的时候 &＃xff0c;一定是有顺序的。

Kafka 保证消息顺序性

如果消费者单线程消费&＃43;处理&＃xff0c;如果处理比较耗时&＃xff0c;处理一条消息是几十ms&＃xff0c;一秒钟只能处理几十条数据&＃xff0c;这个吞吐量太低了。肯定要用多线程去并发处理&＃xff0c;压测消费者4 核 8G 单机&＃xff0c;32 条线程&＃xff0c;最高每秒可以处理上千条消息

消息队列延迟以及过期失效

消费端出了问题&＃xff0c;不消费了或者消费极其慢。接着坑爹了&＃xff0c;你的消息队列集群的磁盘都快写满了 &＃xff0c;都没人消费&＃xff0c;怎么办&＃xff1f;积压了几个小时&＃xff0c;rabbitmq设置了消息过期时间后就没了&＃xff0c;怎么办&＃xff1f;

例如&＃xff1a;

• 每次消费之后都要写 mysql&＃xff0c;结果mysql挂了&＃xff0c;消费端 hang 不动了。

• 消费者本地依赖的一个东西挂了&＃xff0c;导致消费者挂了。

• 长时间没处理消费&＃xff0c;导致 mq 写满了。

场景&＃xff1a;几千万条数据再 MQ 里积压了七八个小时

推荐福利&＃xff1a;

快速处理积压的消息

一个消费者一秒是 1000 条&＃xff0c;一秒 3 个消费者是 3000 条&＃xff0c;一分钟是 18W 条&＃xff0c;1000 多 W 条需要一个小时恢复。

步骤&＃xff1a;

• 先修复 consumer 的问题&＃xff0c;确保其恢复消费速度&＃xff0c;然后将现有的 consumer 都停掉

• 新建一个topic,partition是原来的 10 倍&＃xff0c;临时建立好原先 10 倍或者 20 倍的 queue 数量

• 然后写一个临时的分发数据的 consumer 程序&＃xff0c;这个程序部署上去消费积压的数据&＃xff0c;消费之后不做耗时的处理&＃xff0c;直接均匀轮询写入临时建立好的 10 倍数量的 queue

• 接着临时征用 10 倍的机器来部署 consumer,每一批 consumer 消费一个临时 queue 的数据

• 这种做法相当 于是临时将 queue 资源和 consumer 资源扩大 10 倍&＃xff0c;以正常 10 倍速度

• 等快速消费完积压数据之后&＃xff0c;恢复原先部署架构 &＃xff0c;重新用原先的 consumer机器消费消息

原来 3 个消费者需要 1 个小时可以搞定&＃xff0c;现在 30 个临时消费者需要 10 分钟就可以搞定。

如果用的 rabbitmq&＃xff0c;并且设置了过期时间&＃xff0c;如果此消费在 queue里积压超过一定的时间会被 rabbitmq清理掉&＃xff0c;数据直接搞丢。
这个时候开始写程序&＃xff0c;将丢失的那批 数据查出来&＃xff0c;然后重新灌入mq里面&＃xff0c;把白天丢的数据补回来。

如果消息积压mq&＃xff0c;长时间没被处理掉&＃xff0c;导致mq快写完满了&＃xff0c;你临时写一个程序&＃xff0c;接入数据来消费&＃xff0c;写到一个临时的mq里&＃xff0c;再让其他消费者慢慢消费 或者消费一个丢弃一个&＃xff0c;都不要了&＃xff0c;快速消费掉所有的消息&＃xff0c;然后晚上补数据。

如何设计消息队列中间件架构

• mq要支持可伸缩性&＃xff0c;快速扩容。设计一个分布式的 MQ&＃xff0c;broker->topic->partition&＃xff0c;每个 partition 放一个机器&＃xff0c;就存一部分数据。如果现在资源不够&＃xff0c;给 topic 增加 partition &＃xff0c;然后做数据迁移&＃xff0c;增加机器。

• mq数据落磁盘&＃xff0c;避免进程挂了数据丢了&＃xff0c;顺序写&＃xff0c;这样就没有磁盘随机读写的寻址开销&＃xff0c;磁盘顺序读写的性能是很高的&＃xff0c;这个就是 kafka的思路。

• mq高可用性。多副本->leader & follower-> broker 挂了重新选举 leader 对外提供服务

• 支持数据 0 丢失。

END后台回复“电子书” “资料” 领取一份干货&＃xff0c;数百技术电子书等你开发者技术前线 &＃xff0c;汇集技术前线快讯和关注行业趋势&＃xff0c;大厂干货&＃xff0c;是开发者经历和成长的优秀指南。历史推荐裸辞4个月&＃xff0c;面试了30家公司&＃xff0c;终于找到了理想的工作
面试官问我&＃xff1a;一个 TCP 连接可以发多少个 HTTP 请求&＃xff1f;我竟然回答不上来...
面试鹅厂&＃xff0c;我被虐的体无完肤
面试阿里露馅被怼了&＃xff01;面试官&＃xff1a;这简历一看就是包装过的
中文版开源&＃xff01;一份来自亚马逊工程师写的 Google 面试指南&＃xff0c;太火了
面试环节:在浏览器输入xxxhub 回车之后发生了什么&＃xff1f;&＃xff08;超详细版&＃xff09;
又要要饭了&＃xff0c;点个在看吧