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

> 东哥这波操作太狠了，不是因为商业决策，而是因为送外卖！ 4 月 21 日，北京街头惊现一位 “神秘骑手”，定睛一看，**竟是刘强东本人**。他穿着京东外卖工服，骑着小电驴，穿梭在楼宇间送奶茶炸鸡，这画面简直不要太魔幻。网友们纷纷调侃：“东哥这是要体验生活，还是要抢外卖员的饭碗？”  送完外卖后，刘强东又搞了个大动作 —— 包下海底捞请全体骑手涮火锅。在视频里，他举着酒杯对着穿美团、饿了么工服的骑手喊话：“**欢迎兄弟们跳槽来京东**！” 这波操作可谓是赚足了眼球，也让京东和美团的外卖大战彻底白热化。  今年 2 月，京东高调杀入外卖赛道，一上来就甩出三张王牌：0 佣金挖墙脚、百亿补贴砸用户、骑手 “五险一金” 拉人头。这每一招都直戳美团的痛点，尤其是骑手的福利问题，更是引发了广泛关注。面对京东的攻势，美团也迅速做出反应，推出 “护城计划”，降低商家抽佣，豪掷 1000 亿补贴餐饮行业，还放话要建 10 万个 “闪电仓”。**双方你来我往，互不相让，这场商战堪称史无前例。​** 在这场大战中，最开心的莫过于普通群众了。**资本打架，百姓得利，各种优惠券满天飞**，奶茶、炸鸡的价格也是一降再降。网友们纷纷表示：“这样的商战请再来一打，最好打到奶茶 1 元、炸鸡白送！”​  这场外卖江湖的大战，看似是京东和美团在抢订单，实则是本地生活服务的终极对决。京东想通过高频的外卖业务带动低频的电商业务，**让用户从 “一年逛两次京东” 变成 “天天点京东”**；美团则要守住外卖基本盘，防止即时零售业务被反杀。而骑手们，也在这场大战中成为了 “香饽饽”，福利越来越好。​ 看到这里，很多小伙伴可能已经迫不及待想要和东哥做兄弟了，**当然，是那种坐办公室的兄弟，哈哈。** 你别说，[我的学员](https://mp.weixin.qq.com/s/lgJSqmSTurZEZYKuZc4eKw)还真就实现了，跟着东哥混了。   想必你也希望加入京东这样的优秀企业，今天我就来分享一下我们**组织内部整理的京东面经详解**，希望能帮助到你。 # 京东面经分享 ### 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）。 - 比如，转账操作若中途失败，日志记录撤销未完成的步骤。 - **示例**： ```sql 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`：活跃事务列表。 - **可见性判断逻辑**： ```go 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**：记录锁 + 间隙锁，防幻读。 - **示例**： ```sql -- 事务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。 - **示例**： ```bash 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**，备注：面试群。