追踪完整的推广链路（进行分佣）是怎么做的呢？
推广链路追踪通常是通过在推广链接中携带唯一的推广标识（如 PID/ClickID），并在用户点击时将标识与用户身份（如 Cookie、DeviceID 或登录账号）进行绑定，最终在交易完成时通过日志回传或 API 回调实现链路闭环，从而触发分佣结算。
简单来说就是：链接带参、点击留痕、转化关联、回传结算。
推广的链接里面会带用户的信息吗？
推广链接通常只携带推广者的唯一标识（如 PID）和业务参数，而不包含点击者的个人隐私信息；对于点击者的追踪，是靠链接中的匿名 ClickID 在用户进入系统后，与设备指纹或登录账号进行后台关联实现的。
短链接是怎么映射长链和跳转的？
其核心逻辑是将数据库自增 ID（或 Snowflake ID）通过 Base62 编码 生成唯一短码，并在数据库中建立短码与长链的映射关系；跳转时采用 HTTP 302 重定向，以便在跳转过程中实时记录点击日志并进行数据统计与反作弊分析。
短链的长度是固定的吗，是怎么设计的？
短链通常设计为 6 到 7 位的固定长度字符（基于 Base62 编码可容纳数百亿数据），其核心原理是将长链接映射为一个唯一的整数 ID 并转换为 62 进制短码，通过 HTTP 302 重定向实现跳转，从而兼顾 URL 的美观性与点击量统计的需求。
跳转的时候用的是 301 还是 302 跳转？为什么？
短链跳转通常建议使用 302（临时重定向）。
原因：短链系统的核心需求之一是数据统计（如点击量、来源、设备信息等）。如果使用 302，浏览器每次点击都会请求短链服务器，方便系统记录完整的访问数据；如果使用 301（永久重定向），浏览器会缓存跳转关系，后续相同的访问将直接跳转到目标 URL 而不再经过短链服务器，导致统计数据严重偏低。
注：虽然 301 对 SEO 更友好且能减轻服务器压力，但在需要精准分析点击数据的商业场景下，302（或 307）是更主流的选择。
短链的分库分表依据是什么？
- 按短码哈希取模，对短码做哈希运算后取模，比如分 4 个库就模 4，余数决定数据存哪个库，再模表数定具体表，这样数据分布均匀，查询时直接算哈希就能找到位置。
- 然后是按时间范围，比如按短链创建时间，每月或每周分一个库 / 表，适合有时间维度查询的场景，但要注意热点问题，比如某段时间短链多会导致单库 / 表压力大。
- 还有按推广业务维度，比如按 PID（推广员 ID）哈希分，同一推广员的短链存在同一库 / 表，方便统计该推广员的所有数据，但要避免推广员数量不均导致的数据倾斜。
假如有以上多个场景的时候怎么办？这种情况可以试试 “复合分库 + 冗余存储” 的思路。比如主库按短码哈希分，满足用户点击短链时的快速查询；再建从库，按 PID 哈希或时间分，专门处理推广员统计、时间维度分析的需求，主从之间通过 binlog 同步数据。如果不想维护多套库，也可以用中间件（比如 ShardingSphere)做多维度路由，比如查询带短码就按短码路由，带 PID 就按 PID 路由，但要注意维护路由规则的复杂度。另外，还能对热点数据做缓存，比如常用短链直接放 Redis，减少分库分表的查询压力。
分库分表
分库分表是一种通过将单表或单库的海量数据，按照特定规则（如 Hash 或范围）拆分并分散存储到多个物理数据库或数据表中的架构方案，其核心目的是突破单机数据库在存储容量和并发处理性能上的瓶颈，实现系统的水平扩展。
双写怎么保证数据一致？
在分布式系统中，为了提高性能，通常会使用缓存（如 Redis）来减轻数据库的压力。当数据发生变更时，需要保证缓存和数据库的一致性。最常用的方案是 Cache-Aside Pattern，即：写请求先更新数据库，再删除缓存。
短链有典型的冷热数据特点，怎么处理的？
“多级缓存抗高频，布隆过滤防穿透，冷热分离降成本”
- 通过 Redis 结合本地缓存（如 Caffeine）并配合 LRU 策略承载 99% 的热点跳转请求；
- 利用 布隆过滤器 快速拦截无效或冷数据请求以保护数据库
- 在存储层将海量低频访问的旧链定期迁移至 冷库（如 HBase 或归档表），并坚持使用 302 重定向 以确保每次访问都能触发统计逻辑及缓存预热。
OpenTracing 这个是基架做的吗，为什么业务团队也要去搭呢？
关于 OpenTracing 的详细介绍，请参考 OpenTracing 规范。
- 加入了这么多上报会不会对性能有影响？
- Tracing 有一定的采样率，如果调用链路中某个服务有报错，它并不一定能被采样到。怎样能使报错的调用都被采样到呢？
- binlog 有哪几种模式？
- 为什么需要不同模式？
- 主机房执行了一个事务，同步到从机房，它的事务性能保证吗？
- 什么是覆盖索引？
- 了解索引下推吗？什么情况下会下推到引擎去处理？
- 什么场景下索引会失效？
- 有没有具体一点的例子？
- WHERE id NOT IN (?, ?, ?) 会走索引吗？
- Redis 使用的过程中有碰到过一些热 Key、大 Key 的问题吗？
- rdb 导出会不会太慢了，比如说里面有一两亿的数据，里面会包含了一些大 Key，怎么样更快找出来？
- 如果有一些热点 Key，比如某个链接被明星分享了，访问就会很频繁，怎么办？
- 如果定位到了热 Key 之后怎么防止它把单个节点打爆呢？
- 用 RAND(5) 实现 RAND(7)？
- A 和 B 从一堆棋子中轮流取，每次需要取走 1-5 个棋子，A 先取，如何必胜？
反转链表 II
