当东哥开始卷外卖：奶茶砍半价比拼多多还狠！附京东面试题

东哥这波操作太狠了，不是因为商业决策，而是因为送外卖！

4 月 21 日，北京街头惊现一位 “神秘骑手”，定睛一看，竟是刘强东本人。他穿着京东外卖工服，骑着小电驴，穿梭在楼宇间送奶茶炸鸡，这画面简直不要太魔幻。网友们纷纷调侃：“东哥这是要体验生活，还是要抢外卖员的饭碗？”

送完外卖后，刘强东又搞了个大动作 —— 包下海底捞请全体骑手涮火锅。在视频里，他举着酒杯对着穿美团、饿了么工服的骑手喊话：“欢迎兄弟们跳槽来京东！” 这波操作可谓是赚足了眼球，也让京东和美团的外卖大战彻底白热化。

今年 2 月，京东高调杀入外卖赛道，一上来就甩出三张王牌：0 佣金挖墙脚、百亿补贴砸用户、骑手 “五险一金” 拉人头。这每一招都直戳美团的痛点，尤其是骑手的福利问题，更是引发了广泛关注。面对京东的攻势，美团也迅速做出反应，推出 “护城计划”，降低商家抽佣，豪掷 1000 亿补贴餐饮行业，还放话要建 10 万个 “闪电仓”。双方你来我往，互不相让，这场商战堪称史无前例。​

在这场大战中，最开心的莫过于普通群众了。资本打架，百姓得利，各种优惠券满天飞，奶茶、炸鸡的价格也是一降再降。网友们纷纷表示：“这样的商战请再来一打，最好打到奶茶 1 元、炸鸡白送！”​

这场外卖江湖的大战，看似是京东和美团在抢订单，实则是本地生活服务的终极对决。京东想通过高频的外卖业务带动低频的电商业务，让用户从 “一年逛两次京东” 变成 “天天点京东”；美团则要守住外卖基本盘，防止即时零售业务被反杀。而骑手们，也在这场大战中成为了 “香饽饽”，福利越来越好。​

看到这里，很多小伙伴可能已经迫不及待想要和东哥做兄弟了，当然，是那种坐办公室的兄弟，哈哈。

你别说，我的学员还真就实现了，跟着东哥混了。

想必你也希望加入京东这样的优秀企业，今天我就来分享一下我们组织内部整理的京东面经详解，希望能帮助到你。

京东面经分享

go语言的map，拉链法

Go语言的map底层基于哈希表实现，采用拉链法解决哈希冲突。其核心结构是hmap，包含以下关键点：

1. hmap结构：

   • hmap是map的底层数据结构，包含以下关键字段：

     • count：键值对数量。
     • B：哈希桶数组的大小（2^B）。
     • bucket：指向桶数组的指针。
     • oldbucket：扩容时临时存储旧桶的指针。
     • hash0：哈希种子，用于提高哈希分布的随机性。
   • 桶数组：每个桶（bmap类型）存储8个键值对。

2. bmap结构：

   • 每个bmap包含以下字段：

     • keys：存储键的数组，长度为8（uint8类型，实际存储的是指针或值，取决于键类型）。
     • topbits：记录键的高位哈希值，用于快速判断键是否存在。
     • overflow：指向溢出桶的指针（当冲突时形成链表）。
     • flags：标记键是否被占用或删除。

3. 拉链法实现细节：

   • 哈希冲突处理：当多个键的哈希值映射到同一桶时，通过overflow指针链接到下一个bmap，形成链表。

   • 扩容机制：

     • 当count > loadFactor * bucketCnt时触发扩容（默认loadFactor=6.5/8）。
     • 新桶大小为2^(B+1)，元素重新哈希到新桶。
     • 扩容过程中，旧桶和新桶同时存在，通过oldbucket指针过渡，保证并发读写安全。

   • 优化点：

     • 每个桶固定存储8个键值对，减少指针开销。
     • 利用CPU缓存局部性，连续存储键值对提升访问速度。

---

数据库索引有哪些

数据库索引主要分为以下类型（基于知识库中的分类和扩展）：

1. B+树索引：

   • 结构：

     • 多级索引树，叶子节点按顺序存储键值及对应数据指针。
     • 非叶子节点存储中间键和子节点指针。

   • 特点：

     • 支持范围查询（如WHERE id BETWEEN 1 AND 100）。
     • 插入/删除需保持树平衡，性能略低于哈希索引。
   • 适用场景：主键索引、唯一索引、普通索引。

2. 哈希索引：

   • 结构：

     • 哈希表结构，键通过哈希函数映射到桶位置。

   • 特点：

     • 仅支持等值查询（如WHERE id=5）。
     • 不支持范围查询，且数据无序存储。
   • 适用场景：等值查询频繁的场景（如内存数据库）。

3. 全文索引：

   • 结构：

     • 对文本进行分词，构建倒排索引（词→文档ID列表）。

   • 特点：

     • 支持模糊匹配（如WHERE content LIKE '%keyword%'）。
     • 需预处理文本（分词、停用词过滤）。
   • 适用场景：搜索引擎、日志分析。

4. 空间索引：

   • 结构：

     • 使用R树或四叉树存储地理坐标数据。

   • 特点：

     • 支持范围查询（如WHERE distance < 100km）。
     • 处理高维数据效率较高。
   • 适用场景：GIS系统、地图应用。

5. 组合索引：

   • 结构：

     • 多列组合成一个索引，按列顺序存储。

   • 特点：

     • 遵循最左前缀原则（如索引(a,b)可支持WHERE a=1，但WHERE b=2无效）。
   • 适用场景：多条件联合查询。

---

数据库四大特性

数据库的四大特性（ACID）是事务可靠性的核心保障：

1. 原子性（Atomicity）：

   • 实现方式：

     • 通过事务日志（Redo Log）记录操作，失败时回滚（Rollback）。
     • 比如，转账操作若中途失败，日志记录撤销未完成的步骤。

   • 示例：

     BEGIN;
     UPDATE account SET balance = balance - 100 WHERE id=1;  -- 步骤1
     UPDATE account SET balance = balance + 100 WHERE id=2;  -- 步骤2
     COMMIT;  -- 若步骤2失败，步骤1会被回滚

2. 一致性（Consistency）：

   • 约束维护：

     • 通过外键约束、检查约束等确保数据符合业务规则。
     • 例如，订单金额必须大于0。
   • 依赖ACID：一致性依赖其他特性（如原子性避免数据半更新）。

3. 隔离性（Isolation）：

   • 隔离级别：

     • Read Uncommitted（RU）：允许脏读，但无实际应用场景。
     • Read Committed（RC）：每次查询使用最新快照，避免脏读但可能不可重复读。
     • Repeatable Read（RR）：事务内快照一致，通过MVCC和间隙锁防幻读。
     • Serializable（SERIALIZABLE）：串行化执行，通过锁全表。

   • 冲突示例：

     • 脏读：事务A读取事务B未提交的数据，B回滚后A数据无效。
     • 幻读：事务A两次查询同一条件，事务B插入新数据导致结果变化。

4. 持久性（Durability）：

   • 实现机制：

     • Write-Ahead Logging（WAL）：先写日志再写数据，崩溃后通过日志恢复。
     • 刷盘策略：COMMIT时确保日志写入磁盘（如MySQL的innodb_flush_log_at_trx_commit=1）。

---

innodb默认隔离级别

InnoDB的默认隔离级别是可重复读（Repeatable Read，RR），其设计原因和实现细节如下：

1. 设计原因：

   • 主从复制兼容性：

     • 在STATEMENT格式的Binlog中，RR避免因其他事务修改数据导致主从不一致。
     • 例如，SELECT后UPDATE若在READ COMMITTED下可能产生不同结果。
   • 用户习惯：大多数用户期望事务内多次读取结果一致。

2. 实现机制：

   • MVCC（多版本并发控制）：

     • 隐藏列：每行记录包含DB_TRX_ID（创建事务ID）、DB_ROLL_PTR（回滚指针）等。
     • Read View：事务开始时生成，记录活跃事务列表，过滤不可见版本。

     • 可见性规则：

       • 若当前事务ID > 记录的DB_TRX_ID且记录未被删除，且记录的事务已提交。

   • 间隙锁（Gap Lock）：

     • 锁定索引区间（如WHERE id > 100会锁(100, ∞)区间）。
     • 防止其他事务在区间内插入新行，避免幻读。

   • Next-Key Lock：

     • 结合记录锁和间隙锁，锁定索引记录及前后区间。
     • 例如，SELECT ... FOR UPDATE会锁定查询到的记录及可能的间隙。

---

rr是怎么实现的

RR的实现依赖MVCC和锁机制，具体流程如下：

1. MVCC实现：

   • 行版本管理：

     • 每次更新生成新版本，旧版本通过回滚段（Undo Log）保留。
     • 事务通过Read View过滤不可见版本。

   • Read View结构：

     • min_trx_id：当前事务ID。
     • max_trx_id：系统中未提交的事务最大ID。
     • trx_ids：活跃事务列表。

   • 可见性判断逻辑：

     if record.trx_id < current_trx_id {
         // 记录已提交，可见
     } else if record.trx_id > max_trx_id {
         // 未提交，不可见
     } else {
         // 检查trx_ids列表，若存在则不可见
     }

2. 锁机制：

   • 记录锁（Record Lock）：锁定具体索引记录。
   • 间隙锁（Gap Lock）：锁定索引区间，防止插入。
   • Next-Key Lock：记录锁 + 间隙锁，防幻读。

   • 示例：

     -- 事务A执行：
     SELECT * FROM t WHERE id = 1 FOR UPDATE;  -- 锁定id=1记录
     SELECT * FROM t WHERE id BETWEEN 10 AND 20;  -- 锁定区间(10,20)

3. 冲突处理：

   • 死锁检测：InnoDB定期检测锁等待环，自动回滚代价小的事务。
   • 锁超时：通过innodb_lock_wait_timeout设置等待时间。

---

tcp三次握手

TCP三次握手的详细流程及作用如下：

1. 第一次握手（SYN=1）：

   • 客户端发送SYN包，携带初始序列号ISN_Client。
   • 客户端进入SYN_SENT状态。
   • 作用：请求建立连接，同步客户端初始序列号。

2. 第二次握手（SYN=1, ACK=1）：

   • 服务端回复SYN-ACK包，携带：

     • SYN=1：服务端同意建立连接。
     • ACK=ISN_Client + 1：确认客户端序列号。
     • ISN_Server：服务端初始序列号。
   • 服务端进入SYN_RCVD状态。
   • 作用：确认客户端请求，同步服务端初始序列号。

3. 第三次握手（ACK=1）：

   • 客户端发送ACK包，携带：

     • ACK=ISN_Server + 1：确认服务端序列号。
   • 双方进入ESTABLISHED状态。
   • 作用：客户端确认服务端的响应，连接正式建立。

4. 关键点：

   • 序列号同步：双方确认初始序列号，确保数据有序传输。

   • 防旧连接干扰：

     • 若客户端重传SYN，服务端的SYN-ACK包含ACK=ISN_Client+1，避免旧数据包被误处理。
     • 若服务端重启后收到旧SYN，其ISN_Server已变化，导致客户端无法正确响应。

---

ip位于哪层？icmp位于哪层？ping命令位于哪层？

1. IP协议：

   • OSI模型：网络层（第三层）。

   • 功能：

     • 逻辑寻址（IP地址）。
     • 路由选择（通过路由表转发数据包）。
     • 分片与重组（处理超过MTU的数据包）。

2. ICMP协议：

   • OSI模型：网络层（第三层）。

   • 功能：

     • 错误报告：如Destination Unreachable（目标不可达）。
     • 查询与诊断：如Echo Request/Reply（支持ping命令）。
     • 拥塞控制：如Source Quench（减少发送速率）。

3. ping命令：

   • 实现机制：

     • 发送ICMP Echo Request包，等待Echo Reply响应。
     • 计算往返时间（RTT）和丢包率。
   • 协议层：网络层，直接依赖IP和ICMP。

   • 示例：

     ping 192.168.1.1
     # 发送ICMP Echo Request到目标IP，接收Echo Reply

---

telnet是什么操作？位于哪层？

1. Telnet定义：

   • 功能：基于TCP协议的远程终端协议，用于登录并操作远程主机。

   • 典型用途：

     • 远程执行命令（如ls, cd）。
     • 配置网络设备（如路由器）。

2. 协议层：

   • OSI模型：应用层（第七层）。

   • 依赖层：

     • 传输层：使用TCP（端口23）建立可靠连接。
     • 网络层：IP负责寻址。

3. 工作原理：

   • 连接建立：客户端发起TCP三次握手，与服务端建立连接。

   • 数据交互：

     • 客户端输入命令，通过TCP发送。
     • 服务端响应通过TCP返回。

   • 选项协商（可选）：

     • 通过IAC（解释器命令）协商选项，如回显开关、字符集。

     • 示例：

       Client: IAC WILL ECHO（请求开启回显）  
       Server: IAC DO ECHO（同意请求）  

4. 缺点：

   • 明文传输：密码、命令可见，易被窃听。
   • 替代方案：SSH（加密传输，支持密钥认证）。

---

https加密过程

HTTPS的加密过程通过TLS/SSL协议实现，分阶段详细如下：

1. 客户端Hello：

   • 客户端发送支持的协议版本（如TLS 1.2）、加密套件（如TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384）、随机数ClientRandom。

2. 服务器Hello：

   • 服务端选择客户端支持的最高协议版本和加密套件。
   • 返回服务端随机数ServerRandom和证书（含公钥）。

3. 证书验证：

   • 客户端验证证书合法性：

     • 证书颁发机构（CA）是否可信。
     • 主机名是否匹配证书中的域名。
     • 证书是否过期或吊销。

4. 密钥交换（如ECDHE）：

   • 非对称加密：

     • 客户端生成预主密钥（Pre-Master Secret），用服务端公钥加密后发送。

   • 密钥协商：

     • 双方结合ClientRandom、ServerRandom和预主密钥生成对称密钥（Master Secret）。

5. 加密通信：

   • 对称加密：

     • 使用AES-256-GCM等算法加密数据，确保机密性和完整性。
     • MAC（消息认证码）：防止数据篡改（如HMAC-SHA384）。

   • 数据传输：

     • 应用层数据（如HTTP请求）通过TLS记录层封装后发送。

6. 安全特性：

   • 前向安全性：即使长期密钥泄露，攻击者无法解密之前的通信（因预主密钥每会话生成）。
   • 证书吊销检查：通过OCSP stapling减少延迟。

---

欢迎关注 ❤

我们搞了一个免费的面试真题共享群，互通有无，一起刷题进步。

没准能让你能刷到自己意向公司的最新面试题呢。

感兴趣的朋友们可以加我微信：wangzhongyang1993，备注：面试群。