菜鸟开奖，这算明升暗降？

最近秋招在陆续开奖，今天菜鸟也看到有同学爆料了：

研发岗：

• Java 后端，base 杭州，211硕，22k*14

• Java 后端，base 杭州，本科，19k*14

其他：

• 运营，base 杭州，211硕，15k*14
• 市场拓展，base 杭州，硕士，13k*14

鸭鸭翻了去年菜鸟开奖的信息，去年大部分 Java 后端薪资在 17～19k*16 这个区间，硕士基本都定的 P4。从今年这几个开奖消息来看， base 微涨，但年终砍了。职级倒是差不多。

今年早些时候菜鸟有传闻要降公积金，后来说还是按 12%，但今年校招开的公积金都只给了 8%。看来整体福利还是有调整和收紧的。

而且 4 月的时候阿里宣布终止菜鸟的独立上市计划，股权激励已经全部转为长期现金激励。校招

不过菜鸟的好处就是，相比其他阿里系，一些部门没有那么卷，八九点就可以下班。今年还发了双倍年终奖。

菜鸟在阿里内部虽非“嫡系”，但跨境物流与国内供应链的业务布局也提供了稳定的发展前景。

在纠结手头 offer 的同学，可以考虑一下，菜鸟虽然不算最好的 offer，但如果手头没有更好的 offer 的时候，也是可以考虑的。起码菜鸟还怎么见过裁应届生的消息。

……

今天分享一篇 Java 阿里菜鸟后端一面（校招） 面经：

篇幅有限，完整答案可以登陆面试鸭查阅：https://www.mianshiya.com/

对于给表创建索引，你会考虑什么？

索引是提高查询性能的关键。但是设计时应避免过多索引，以免对写操作造成负担。

• 对于经常查询的字段（如 WHERE、JOIN、ORDER BY 中使用的字段）应该创建索引。
• 考虑 复合索引，可以将多个列组成一个索引，优化复合查询性能。
• 避免在低基数列（如布尔值、性别字段）上创建索引，因为它们不会带来太大的查询性能提升。

以下几种情况不推荐建立索引：

1）对于数据量很小的表

2）频繁更新的表

3）执行大量的 SELECT *

5）低频查询的列

6）长文本字段（非常长的 varchar 或 JSON、BLOB 和 TEXT 类型，这些类型的列通常包含大量数据）

哪些场景下索引是会失效的？

索引不一定有效。

例如查询条件中不包含索引列、低基数列索引效果不佳，或查询条件复杂且不匹配索引的顺序。

对于一些小表，MySQL可能选择全表扫描而非使用索引，因为全表扫描的开销可能更小。

最终是否用上索引是根据 MySQL 成本计算决定的，评估 CPU 和 I/O 成本最终选择用辅助索引还是全表扫描。有时候确实是全表扫描成本低所以没用上索引。但有时候由于一些统计数据的不准确，导致成本计算误判，而没用上索引。

你有自己去用redis去实现一个限流器吗？

RateLimiter 是 Redisson 基于 Redis 实现的分布式限流组件，底层使用令牌桶算法，能够控制某个操作或服务在一定时间内的请求频率，保护系统不被过多的请求压垮。

在项目中，考虑到 AI 生成图表是一个耗时且耗费资源的操作，我决定给 AI 生成图表接口增加限流，具体的策略是：单个用户每秒内最多执行 2 次生成图表操作。

具体的实现方式如下：

1）集中管理限流器：创建一个 RedisLimiterManager 类，集中管理整个项目中所有的限流器，并提供创建限流器的接口。

2）创建限流器：通过向 redissonClient 传入指定的 key 来创建限流器，每个用户对应的 key 不同，对应的限流器也不同，从而实现不同用户的独立限流

3）设置限流规则：通过 rateLimiter 的 trySetRate 方法制定限流规则，每秒内最多获取 2 个令牌

4）请求令牌：当用户要执行操作时，会执行对应 rateLimiter 的 tryAcquire 方法尝试获取令牌，如果能够获取到，可以执行后续操作，否则抛出 TOO_MANY_REQUEST 异常。

更多

💻 编程学习交流：编程导航
📃 简历快速制作：老鱼简历
✏️ 面试刷题神器：面试鸭
📖 AI 学习指南：AI知识库