京东薪资开了，性价比太高了

hello，大家好，我是千羽。

我可跟你们说，早在5月份的时候，就有看到京东招聘有上说京东采销年薪从16薪才到20薪，而且这个业绩是上不封顶的，这个消息出来的话就很诱人。

然后没想到，到了九月份，京东在今年2025校园招聘全球启动，本次校招开放1.8万个岗位，包含1.2万个2025届应届生岗位和6000多个实习生岗位，同时将校招生薪酬再次大幅上调！

再接着，然后现在京东研发这边的话，又提升了20薪，真的是可想而知，幅度越来越高。

过去三年来，京东集团连续提升员工的薪酬水平：

1. 2021年7月1日至2023年7月1日，京东用两年时间将员工平均年薪由14薪逐步涨至16薪。
2. 2024年1月1日起，京东采销等一线业务人员的年固定薪酬大幅上涨近100%，2024年初京东零售全员平均加薪不低于20%。
3. 2024年2月1日起，超2万名京东一线客服员工实现全年平均薪酬上涨超过30%。
4. 2024年7月1日起，通过一年半时间，京东采销年度固定薪酬由16薪提升至20薪，业绩激励上不封顶。
5. 2024年8月，京东2025校园招聘全球启动，开放1.8万个岗位，同时将校招生薪酬再次大幅上调。

再看看京东去年 24 届京东校招开发岗位的薪资吧。真的特别香！

	评级	薪资	年包
京东	普通 offer	19.5k~23k*16	31w~37w
京东	sp offer	24k~27k*16	38w~43w
京东	sss offer	29k~30k*16	46w~48w

很难不想和东哥做兄弟！！

在之前京东都是 16 薪，但是今年就不一样喽，不同部门的年终奖月数开始有差别啦。就像京东科技今年是 20 薪，京东零售是 19 薪，京东物流还是 16 薪呢。

生为老员工，就被狠狠倒挂了哎，再来看看今年京东科技的offer开的情况

	评级	薪资	年包
京东科技	普通 offer	21k x 20薪	42w
京东科技	sp offer	24k x 20薪	48w
京东科技	sss offer	27kx 20薪	54w

京东现在不少都开始开奖了，不过还会继续会开的，而且明年还会有补录的情况。

好了，再来看看今年京东科技一面Java面经。一面时长40分钟没有手撕代码，整体面试不难，主要是java技术栈。比较看重笔试，面试基本上都是看八股文相关。

1.自我介绍

面试官您好，我是某某大学计算机专业应届毕业生，主要方向是后端开发。曾经参与了一个基于 Spring Cloud 的电商平台开发，负责订单管理模块。熟悉 Java 技术栈、MySQL 优化，以及常见的分布式系统设计。实习期间优化了某模块的性能，将响应时间缩短了 30%。希望有机会和贵公司共同成长。

2.项目介绍

我参与了一个电商平台的开发，主要目标是支持百万级用户同时下单。 使用 Spring Cloud 微服务架构，我负责订单管理模块的开发，具体包括：

1. 实现分布式事务，解决跨服务的订单支付一致性问题；
2. 优化数据库查询，将复杂查询语句改成缓存和分库分表结合的方式；
3. 针对高并发场景，采用 Redis 实现了秒杀库存的预扣减功能，减少了数据库压力。 通过这些优化，系统性能提升了 40%。

3.项目问题

1. 数据库相关问题

问：为什么要使用分库分表？实现时遇到了哪些问题？

答：分库分表主要为了解决单库性能瓶颈，例如查询变慢和存储限制。在实现过程中，主要遇到以下问题：

• • 分片策略：选择基于订单 ID 或用户 ID 分片，确保查询定位准确；
  • 事务问题：使用分布式事务或最终一致性策略；
  • 跨分片查询：尽量避免，使用缓存或预计算结果解决。
  • 高并发场景的优化 问：如何实现秒杀系统的库存扣减？

答：

• • 在 Redis 中预扣减库存，用户请求先写入队列。
  • 使用异步任务逐步将队列中的订单写入数据库。
  • 设置分布式锁，防止超卖问题。 这样设计可以减轻数据库的并发压力，同时保证高性能。

1. 缓存相关问题

问：Redis 中如何避免缓存穿透和缓存雪崩？

答：

• • 缓存穿透：对不存在的 key 设置空值缓存，并增加过期时间。
  • 缓存雪崩：使用随机过期时间，避免大量缓存同时失效。
  • 使用多级缓存策略，减少对 Redis 的直接依赖。

1. 分布式事务问题

问：你们项目是如何解决分布式事务问题的？

答：

• • 使用 Seata 解决分布式事务，确保各服务间数据一致性；
  • 结合消息队列实现最终一致性，通过重试机制处理失败场景。

1. 消息队列的应用

问：为什么使用 Kafka，而不是 RabbitMQ？

答：Kafka 在高吞吐量、可扩展性和大数据流处理方面更有优势。虽然 RabbitMQ 支持复杂路由，但我们项目需要的是日志型消费和批量处理功能，因此选择了 Kafka。

八股文：

1.redis淘汰策论

Redis 淘汰策略（Eviction Policy）是指当 Redis 内存使用达到设定的最大值（maxmemory）时，决定如何处理新数据和现有数据的策略。这些策略主要目的是在有限的内存资源下，保证高效的缓存利用率。

1. Redis 提供的淘汰策略

Redis 支持以下几种内存淘汰策略，设置在配置文件中或通过maxmemory-policy 参数动态调整：

（1）noeviction

• 含义：不淘汰任何数据。当内存不足时，新写入操作会直接返回错误。
• 适用场景：重要数据缓存且不希望丢失时使用，适用于只读缓存场景。
• 注意：当内存满了，新请求将被拒绝。

（2）volatile-lru

• 含义：基于最近最少使用（LRU）算法，淘汰设置了过期时间的键。
• 适用场景：希望优先清除快过期或不常访问的临时数据。
• 限制：只作用于设置了expire 的键。

---

（3）allkeys-lru

• 含义：基于 LRU 算法，淘汰所有键中最近最少使用的键，无论是否设置了过期时间。
• 适用场景：全局缓存场景，需要根据访问频率自动调整。

---

（4）volatile-lfu

• 含义：基于最近最少使用频率（LFU）算法，淘汰设置了过期时间且使用频率最低的键。
• 适用场景：访问模式稳定且缓存中需要保留高频访问数据。

---

（5）allkeys-lfu

• 含义：基于 LFU 算法，淘汰所有键中使用频率最低的键，无论是否设置了过期时间。
• 适用场景：通用缓存场景，适合访问频率变化较大的业务。

---

（6）volatile-random

• 含义：随机淘汰设置了过期时间的键。
• 适用场景：临时缓存场景，对具体淘汰哪个键没有严格要求。

（7）allkeys-random

• 含义：随机淘汰所有键，无论是否设置了过期时间。
• 适用场景：数据访问模式不可预测时使用。

（8）volatile-ttl

• 含义：淘汰设置了过期时间的键，并优先淘汰剩余生存时间（TTL）最短的键。
• 适用场景：需要保证即将过期的临时数据优先被清理。

2. 策略选择建议

根据不同的业务需求选择合适的淘汰策略：

场景	建议策略
数据访问频率高，内存有限	allkeys-lru
需要保留高访问频率的数据	allkeys-lfu
数据中包含临时过期的部分	volatile-lru或volatile-ttl
缓存不允许丢失任何数据	noeviction
数据访问模式不确定	allkeys-random

3. LRU 与 LFU 区别

• LRU（Least Recently Used）
  淘汰最近最少使用的键。适合于访问模式基于近期访问的缓存场景。
  • Redis 使用带采样的近似 LRU 算法，采样键数量由maxmemory-samples 参数控制，默认值为 5。
• LFU（Least Frequently Used）
  淘汰使用频率最低的键。适合于访问频率较稳定的场景。
  • LFU 统计的是访问频率的对数值，记录在键的元数据中。

4. 设置淘汰策略

修改配置文件

在 Redis 配置文件（redis.conf）中设置：

maxmemory 256mb maxmemory-policy allkeys-lru

运行时动态修改

使用 Redis 命令动态设置：

127.0.0.1:6379> CONFIG SET maxmemory 256mb
127.0.0.1:6379> CONFIG SET maxmemory-policy allkeys-lru

---

5. 实际案例分析

• 秒杀场景：
  在高并发的秒杀系统中，使用allkeys-lru，将热门商品的库存缓存优先保留，冷门商品数据被淘汰。
• 推荐系统：
  使用allkeys-lfu，推荐高频访问的用户行为数据，清理不常使用的行为记录。
• 任务队列：
  在任务临时存储中，选择volatile-ttl，让快过期的任务优先淘汰。

2.spring事务级别

在 Spring 框架中，事务管理通过@Transactional 注解或编程式配置实现，支持多种事务传播行为和隔离级别。

1. 事务传播行为（Propagation）

传播行为定义了当一个事务方法被另一个事务方法调用时的行为。Spring 提供了以下传播类型：

传播级别	描述
REQUIRED	默认值，当前方法必须在事务中运行；如果当前没有事务，则创建一个新的事务。
REQUIRES_NEW	总是创建一个新的事务，如果当前已经有事务，暂停当前事务。
SUPPORTS	当前方法支持事务，如果当前有事务，则加入；否则以非事务方式运行。
NOT_SUPPORTED	当前方法不需要事务，如果有事务，则挂起当前事务。
MANDATORY	当前方法必须在一个事务中运行，如果没有事务，则抛出异常。
NEVER	当前方法不能在事务中运行，如果有事务，则抛出异常。
NESTED	如果当前有事务，则在嵌套事务中运行（保存点）；否则行为与REQUIRED 相同。

---

2. 事务隔离级别（Isolation）

隔离级别定义了事务之间的隔离程度，Spring 支持的隔离级别对应数据库标准定义：

隔离级别	描述	解决问题
DEFAULT	使用数据库的默认隔离级别（一般是READ_COMMITTED）。	不指定特殊隔离要求时使用
READ_UNCOMMITTED	允许读取未提交的数据（脏读）。	最低隔离，性能高，数据可能不一致
READ_COMMITTED	只能读取已提交的数据，防止脏读。	防止脏读
REPEATABLE_READ	保证在同一事务中多次读取相同数据的结果一致，防止不可重复读。	防止脏读与不可重复读
SERIALIZABLE	最高隔离级别，所有事务串行执行，防止脏读、不可重复读和幻读。	数据一致性最高，但性能较低

---

3. 实际应用建议

• Propagation 使用建议
  • REQUIRED：适用于绝大多数业务逻辑，事务传播行为简单。
  • REQUIRES_NEW：适用于需要完全独立的事务（如日志记录）。
  • NESTED：适合需要局部回滚的场景。
• Isolation 使用建议
  • READ_COMMITTED：推荐默认隔离级别，性能和一致性平衡。
  • REPEATABLE_READ：适用于读多写少的业务（如金融业务）。
  • SERIALIZABLE：用于高一致性要求场景，但需要权衡性能。

3.redis底层

数据结构：

• 字符串（String）：底层实现为简单动态字符串（SDS），支持扩展、截断等操作。
• 列表（List）：底层使用双向链表或紧凑列表（ziplist）实现。
• 集合（Set）：使用哈希表或紧凑列表（intset）实现。
• 有序集合（Sorted Set）：底层是跳表（SkipList）和压缩列表的结合。
• 哈希表（Hash）：使用压缩列表或哈希表实现。

4.cap理论

CAP理论是分布式系统中的一个核心概念，全称是 Consistency, Availability, Partition Tolerance，即一致性、可用性和分区容错性。它描述了在分布式系统中，三者无法完全兼顾。

CAP 三个核心属性

一致性（Consistency）

• 所有节点的数据保持一致。 任意读操作返回的结果，要么包含最新写入的数据，要么报错。 类似于数据库中的强一致性。

可用性（Availability）

• 系统始终能够正常响应每个请求。 即使有部分节点失败，系统也能继续提供服务，返回合理的结果。

分区容错性（Partition Tolerance）

• 即使网络分区（Partition）发生，系统仍然能够继续运作。 分布式系统中网络故障（如节点间通信中断）是不可避免的，因此分区容错性是必须满足的。

实际应用中的权衡

• 强一致性场景（CP）：金融转账、订单处理，不能容忍数据不一致。
• 高可用性场景（AP）：社交网络、消息推送，允许短时间的不一致。
• 分区容错性（必须满足）：分布式系统不可避免地需要分区容错。

5.springCloud组件

Spring Cloud 核心组件：

1. 服务治理与注册
   • Eureka：服务注册与发现。
   • Consul/Zookeeper：其他服务注册替代方案。
2. 负载均衡
   • Ribbon：客户端负载均衡（已被替代）。
   • Spring Cloud LoadBalancer：现代负载均衡解决方案。
3. 服务调用
   • OpenFeign：声明式 HTTP 客户端，简化服务间调用。
4. 网关与路由
   • Spring Cloud Gateway：基于 WebFlux 的网关（推荐）。
   • Zuul：老牌网关（逐步被替代）。
5. 配置管理
   • Spring Cloud Config：集中式配置管理工具。
6. 链路追踪
   • Spring Cloud Sleuth：分布式链路追踪，集成 Zipkin/Jaeger。
7. 容错与限流
   • Hystrix：熔断、降级（已被 Resilience4j 替代）。
   • Resilience4j：轻量化容错组件。
8. 消息驱动
   • Spring Cloud Stream：基于消息中间件的事件驱动框架。
   • Spring Cloud Bus：广播配置更新、事件通知。
9. 任务调度
   • Spring Cloud Task：短期任务执行。
   • Spring Cloud Data Flow：数据流编排与任务调度。

场景题

大数据量查询 分库分表

略

总结

整体面试体验:超级好，互动性很强。答不上来的，面试官会给提示，而且会讨论解决方案的优劣性等等，许愿二面～～

牛客网：https://www.nowcoder.com/feed/main/detail/86a952829016407bb63b1c9637b650e3?sourceSSR=search