# redis-go **Repository Path**: lvzihao521/redis-go ## Basic Information - **Project Name**: redis-go - **Description**: No description available - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2026-08-16 - **Last Updated**: 2026-08-19 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README [![progress-banner](https://backend.codecrafters.io/progress/redis/f98d5154-2bd3-492e-b1e9-7678b1bdae97)](https://app.codecrafters.io/users/breatheCoder?r=2qF) This is a starting point for Go solutions to the ["Build Your Own Redis" Challenge](https://codecrafters.io/challenges/redis). In this challenge, you'll build a toy Redis clone that's capable of handling basic commands like `PING`, `SET` and `GET`. Along the way we'll learn about event loops, the Redis protocol and more. **Note**: If you're viewing this repo on GitHub, head over to [codecrafters.io](https://codecrafters.io) to try the challenge. # Passing the first stage The entry point for your Redis implementation is in `app/main.go`. Study and uncomment the relevant code, then run the command below to execute the tests on our servers: ```sh codecrafters submit ``` That's all! # Stage 2 & beyond Note: This section is for stages 2 and beyond. 1. Ensure you have `go (1.26)` installed locally 1. Run `./your_program.sh` to run your Redis server, which is implemented in `app/main.go`. 1. Run `codecrafters submit` to submit your solution to CodeCrafters. Test output will be streamed to your terminal. 我们部门主要负责 Pack 相关的服务和平台能力。Pack 可以理解为处在 API 层和领域层之间的数据打包层：上游是各类 API 场景和客户端消费，下游是广告、内容、用户、音乐、挑战、商业化等领域服务。Pack 的核心职责不是单纯透传数据，而是把领域层的数据并发取回、聚合、过滤、加工，然后按照业务需要组装成客户端可以消费的 DTO 结构，再返回给 API 层。换句话说，Pack 是很多端上展示和交互能力背后的“数据组装中台”[1]。 如果放在商业化广告链路里，Pack 是广告投后链路中非常关键的一环，主要负责广告视频专属的物料和组件加载，比如广告卡片、蒙层、转化按钮、广告标识文案、落地页相关信息等。投放侧通常已经确定了 AdId、CreativeId 等核心广告身份信息，Pack 要基于这些广告身份和上下文，把广告展示所需要的各类字段、素材、组件数据打包出来，最终支撑客户端完成广告展现和交互[2]。 从架构上看，Pack 不是一个单点服务，而是一套平台化的打包体系。底层有 Pack Platform 基座服务，负责对外暴露接口、请求解析、权限控制、错误处理和结果返回；中间有 Pack Material 相关服务，负责物料加载、聚合和 DTO 填充；旁边还有 Content Filter 这类过滤服务，负责内容安全、隐私、规则过滤等后置决策。Pack Material 内部又会拆成 base、sub pack、pack server 或 pack biz 等模块，分别处理基础物料、关联对象和业务功能信息[3]。 Pack 内部的典型处理模型可以概括为 Loader → Material → Filter → Assembler → DTO。Loader 负责封装下游 RPC 调用，把外部数据或素材取回来，并通过聚合和缓存降低下游压力；Material 是 Pack 内部的中间数据集合，Loader 生产的数据会先沉淀在 Material 里；Filter 负责做过滤和规则判断；Assembler 负责从 Material 中取数据并填充 DTO，它本身不做网络调用；最后由 pack engine 把整个流程并发调度起来，完成从数据加载到字段填充的全过程[4]。 我们部门的职责可以分成几类。第一类是 在线打包链路稳定性和性能，因为 Pack 处在核心请求链路上，调用量大、下游依赖多，所以需要关注延迟、可用性、缓存、降级、容灾以及下游负载。第二类是 业务需求承接，比如广告样式、组件、按钮、卡片、落地页、锚点、互动能力等新需求，很多最终都会落到 Pack 侧做字段生产和 DTO 组装。第三类是 平台化建设，也就是把原来大量 hard code 的字段逻辑、组件逻辑、实验逻辑抽象成可配置、可复用、可运营的平台能力。第四类是 跨端、跨系统协作，因为 Pack 上游对接 API、客户端和产品，下游对接投放、素材、创意、广告引擎、内容领域服务等，所以它天然是一个业务和技术交叉比较深的位置[5]。 重点说一站式。一站式的背景是，广告样式和物料需求非常多，过去很多需求都是小改动、多迭代、强时效，但如果每次都需要研发改代码、发版、联调，成本会很高，而且容易出现字段散落、逻辑重复、链路长、沟通成本高的问题。因此一站式要解决的是：把广告样式从“代码驱动”逐步变成“平台配置驱动”，让样式、组件、物料、实验、预览、创编等能力标准化，降低业务接入和迭代成本[5]。 在一站式体系里，广告视觉样式不是一个单一概念，而是由端实现和数据依赖共同决定的。它会被拆成模板、组件类型、组件、UI 配置和物料。模板定义某个流量和广告场景下能出现哪些组件类型，以及组件之间的布局、事件、尺寸等配置；组件类型是某种视觉组件的抽象，比如 CTA 按钮、下载卡等；组件是某个组件类型的具体实例，会包含过滤条件、UI 配置、字段到物料的映射关系；UI 配置定义槽位、位置、尺寸、展示时机；物料则负责提供组件真正要展示的数据值[6]。 物料是这里最核心的部分。可以简单理解为：样式、模板、组件类型、组件更多是在定义“端上要展示什么结构”，而物料是在回答“这个结构里每个字段的值从哪里来、怎么生产、什么时候下发”。例如一个 CTA 按钮组件，组件本身定义了它是按钮、展示在哪里、什么时候出现，但按钮文案、跳转链接、样式配置、是否可展示、是否有优惠券、是否命中特定广告类型等，都可能需要物料来支撑。物料生产流程就是根据 Loader 拿到的源数据，再经过一系列业务逻辑处理，最终得到某个预定义字段的 value[7]。 所以一站式物料平台的职责，本质上是做 组件、物料、Loader、字段逻辑之间的资产管理和依赖编排。它需要管理某个组件依赖哪些物料，某个物料依赖哪些 Loader 或投放透传字段，物料如何过滤，如何生产，如何写入 Pack 内部数据结构，最终如何被组件打包并下发到端上。在新架构中，Pack 会根据物料和 Loader 的关系动态构建 DAG，尽量只调用当前样式和组件真正需要的 Loader，避免全量调用下游，从而降低下游负载和打包时延[7]。 一站式还改变了组件打包的方式。老链路里，新增一个组件类型往往需要 Pack 侧定义新的下发结构，并写新的组件打包逻辑，组件结构和业务逻辑容易硬编码在服务里。新链路希望把组件打包抽象成通用引擎，新增组件时更多关注平台配置、字段映射和物料生产，而不是每次都改一套专门的打包逻辑。这也是一站式对研发效率提升比较明显的地方[7]。 不过 Pack 并不是完全只做“透传配置”。在实际业务里，很多决策发生在样式优选之后，例如两个组件二选一、有券出优惠券组件、没券出卡片组件，这类判断条件可能只有 Pack 在拿到后置数据后才能做。因此 Pack 仍然会承担一部分二次过滤和兜底决策能力。一站式的目标不是让 Pack 没有业务逻辑，而是把通用的、可抽象的、可配置的逻辑平台化，把必须在线判断的逻辑收敛在清晰的链路和边界里[7]。 如果从岗位职责角度介绍，加入这个部门后通常会接触三类工作。第一类是业务需求开发，比如支持新的广告组件、新样式、新按钮、新卡片、新落地页能力，或者接入新的物料字段。第二类是平台能力建设，比如完善物料平台、组件打包引擎、字段管理、实验配置、样式预览、物料 DAG、配置校验和可观测能力。第三类是工程治理，比如梳理老链路、减少 hard code、治理重复字段、优化 Loader 调用、降低延迟、提升稳定性，并推动业务从研发改代码迁移到平台配置[5]。 如果用一句更面试化的话总结，可以这样说：Pack 部门负责商业化和内容消费链路中的数据打包与物料组装，是连接 API、客户端、投放、创意、素材和领域服务的中间层；一站式是部门在广告样式方向上的平台化建设，目标是把样式、组件、物料和实验从分散的代码逻辑抽象为可配置、可复用、可运营的体系；物料相关工作则是其中最核心的一环，负责定义字段从哪里来、如何生产、如何依赖 Loader、如何和组件绑定，并最终稳定、高效地下发到端上。 更优的包装角度不是“我做了很多模块”，而是：我把 Pack 下发数据从分散、人工、临时的排查素材，建设成统一、自助、可校验的数据基础 我理解这个团队的长期方向，是把高频、重复、易出错的样式和物料需求抽象成平台能力。比如把组件、物料、字段映射、Loader 依赖、实验和预览都沉淀成配置化资产，让 PM、客户端、前端和服务端都能在同一套语义下协作。研发侧则更多关注通用引擎、链路稳定性、性能优化、配置校验和兜底能力，而不是每个需求都从头写一套逻辑。 所以我理解 Pack 部门不是单纯做接口拼装，而是在商业化展现链路里承担一个“数据和展示表达的中台”角色。一方面它要保障在线打包链路稳定、高性能，另一方面要支撑广告样式和物料的快速迭代。一站式和物料平台就是这个方向上的核心建设，它们把过去散落在代码里的组件逻辑、字段逻辑、实验逻辑、物料依赖逐步平台化，让业务可以更快上线，也让系统边界更清晰、可维护性更好。对研发来说，这个方向既有业务理解要求，也有工程复杂度，比如 DAG 调度、缓存、降级、配置治理、链路观测和跨团队协作。 ## 直接执行 已阅读文档《[Tech Design] Pack 端数据平台》。它本质上是一个面向 Pack 广告下发链路的“数据采集—采样存储—检索回放—质量巡检”平台 方案，用于解决服务端下发数据难溯源、难排查、异常发现滞后、QA 获取测试数据成本高的问题。 ### 1. 项目定位 一句话总结： 将 Pack 服务端下发给客户端的广告数据沉淀为可查询、可校验、可复用的数据资产，把原本依赖人工抓包、任意门、TTAM、扫码等操作的排 查流程，收敛为平台化的数据检索与自动巡检能力。 ### 2. 核心流程 阶段 具体流程 目的 ━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━ 1. 数据打标 在 Mario 侧基于已解析的广告结构体识别数据特征，包括 RIT、业务类型、产品类型、素材 让每条下发数据具 类型、Spark/非 Spark、目标页面、组件类型等，并通过 IDL 透传 ads_features 备可检索、可过滤 的场景标签 ─────────────────── ──────────────────────────────────────────────────────────────────────────────────── ────────────────── 2. 数据拆分与上报 Kratos 请求中可能包含多个广告，系统按广告粒度拆分 request/response，避免多个广告的 保证数据粒度准 特征互相污染；再通过 DataBus + BMQ 上报 确，避免“AppAds + InfoCTA”这类错 误组合被查询出来 ─────────────────── ──────────────────────────────────────────────────────────────────────────────────── ────────────────── 3. 数据消费与采样 Consumer 按广告特征组合、白名单、预览数据、PPE 测试数据等维度差异化采集；使用 在控制存储成本的 Redis INCR + TTL 控制每个特征组合的采样数量和滚动更新 同时，保证常见测 试与排查场景都有 可用样本 ─────────────────── ──────────────────────────────────────────────────────────────────────────────────── ────────────────── 4. 在线存储 使用 MongoDB 存储请求、响应、广告特征、环境、时间、creative_id、ad_id、组件、模板 支撑复杂嵌套结构 等信息，并设计多维索引与 TTL 生命周期 查询、高写入吞吐 和自动过期清理 ─────────────────── ──────────────────────────────────────────────────────────────────────────────────── ────────────────── 5. 离线存储 规划通过 Dorado 将 MQ 数据转存 Hive，用于历史全量追溯；文档标注为低优先级 覆盖需要长期回溯 的场景，但避免一 开始承担过高存储 成本 ─────────────────── ──────────────────────────────────────────────────────────────────────────────────── ────────────────── 6. 数据检索 提供 CommercePackLogsService.queryLogs 查询 API，支持按 creative_id、ad_id、 让 RD、QA、 log_id、环境、时间范围、广告特征组合等条件查询，并与 QA 共建查询平台 oncall 可以快速 定位真实下发数据 ─────────────────── ──────────────────────────────────────────────────────────────────────────────────── ────────────────── 7. 数据巡检 对线上抽样日志做准实时校验，本期重点包括物料混淆、缺少转化路径等问题，并结合报警和 将异常发现从 QA 每日报告 回归或客户反馈前 置为准实时检测 ─────────────────── ──────────────────────────────────────────────────────────────────────────────────── ────────────────── 8. 验证与上线 方案包含 PPE 自测、diff 确认、联调、多机房验证、上线配置检查、发布依赖检查、观测指 保证数据链路上线 标、小流量验收和回滚方案 风险可控 ### 3. 项目作用与价值 1. 降低排查成本 原排查链路需要打开任意门、TTAM 找广告、扫码或配置预览，再搜索数据；新方案变成按广告 ID、特征、环境、时间等条件直接查询。 2. 提升异常发现效率 通过物料混淆、转化路径缺失等规则巡检，将问题发现从人工回归或客户反馈，前置为准实时报警和日报。 3. 沉淀可复用测试数据 按广告特征组合保留滚动样本，帮助端上 QA 快速获取不同业务、素材、组件、模板场景下的真实下发数据。 4. 提升数据可溯源能力 保存 request/response、环境、集群、调用方、日志 ID、广告特征等信息，使线上问题可以还原到具体下发链路。 5. 支撑后续平台化能力 文档中还规划了数据回放/Mock 能力，可以把历史下发数据提供给客户端做测试复现。 ### 4. 可直接使用的实习产出包装 #### 一段话版本 实习期间参与 Pack 端数据平台的建设，围绕服务端广告下发数据难排查、异常发现滞后、QA 获取测试数据成本高的问题，设计并落地了一套 数据采集、采样存储、检索与巡检链路。方案在 Mario 侧对广告数据进行 RIT、业务、素材、组件等多维度特征打标，在 Kratos 侧按广告粒 度拆分请求和响应，避免多广告特征混淆；数据经 DataBus/BMQ 上报后，由 Consumer 按特征组合、白名单、预览和 PPE 场景差异化采样， 并写入 MongoDB 支撑多维检索与 TTL 生命周期管理。同时提供日志查询 API，与 QA 共建数据查询平台，并落地物料混淆、转化路径缺失等 巡检规则，通过报警和日报提升线上问题发现效率。该平台将原本依赖人工抓包和多方工具链的数据排查过程，收敛为统一、可查询、可校验 的数据服务能力。 #### 简历 Bullet 版本 - 参与设计 Pack 端数据平台，构建广告下发数据的特征打标、日志上报、采样消费、在线存储和多维检索链路，提升线上数据可溯源性与排 查效率。 - 设计广告特征打标与单广告粒度拆分方案，覆盖 RIT、业务类型、产品类型、素材类型、目标页面、组件类型等核心维度，解决多广告请求 中特征混淆导致的查询误召回问题。 - 基于 Redis INCR + TTL 设计特征组合采样与滚动更新机制，在控制存储成本的同时保证不同广告场景均有可用样本；结合 MongoDB 索引与 TTL 设计支撑复杂条件查询和数据生命周期管理。 - 建设日志查询 API，支持按 creative_id、ad_id、log_id、环境、时间范围和广告特征组合检索下发数据，降低 RD、QA 与 oncall 的数据 获取成本。 - 参与数据质量巡检方案设计，支持物料混淆、缺少转化路径等异常检测，并通过报警与每日报告提升线上问题发现效率。 #### 转正/述职汇报框架 项目名称： Pack 端数据平台 背景问题： Pack 服务端下发数据结构复杂，历史上出现过核心物料漏下发、数据混淆等问题。日常 debug、oncall、QA 回归都需要查看端上下发数据， 但原流程依赖任意门、TTAM、扫码、预览配置和人工抓包，链路长、效率低、数据召回不稳定。 我的工作： 1. 梳理 Pack 下发链路的排查诉求和历史问题，抽象出数据平台需要的核心特征与查询维度。 2. 设计 Mario 侧特征打标方案，复用已有业务判断逻辑，并通过 IDL 将 ads_features 等字段透传至下游。 3. 设计 Kratos 多广告请求拆分逻辑，将一次请求中的多个广告拆成单广告日志，避免特征组合污染。 4. 设计 Consumer 采样策略，包括特征组合采样、白名单采样、预览数据全量采集、PPE 环境数据保留。 5. 设计 MongoDB 数据结构、索引、TTL 和容量预估，支撑复杂查询与自动过期。 6. 设计日志查询 API，支持多条件组合查询，为 QA 数据平台提供服务化入口。 7. 参与数据巡检规则设计，覆盖物料混淆、转化路径缺失等关键异常场景。 项目价值： - 排查方式从“人工抓包 + 多工具跳转”升级为“平台化条件查询”。 - 异常发现从“QA 回归/客户反馈”前置为“准实时巡检 + 报警 + 日报”。 - 测试数据从临时获取升级为按特征组合滚动沉淀。 - 数据链路具备 request/response、环境、广告特征等完整上下文，提升问题还原能力。 ——— ## 深度交互（如有） 这份文档作为“技术设计产出”是完整的，但作为“实习产出答辩材料”还缺后验证据。文档里的收益目前主要是预期收益，验收方案、观测指 标、收益后验表格基本还是模板状态，MR 部分也只有一个仓库链接，没有具体 MR、发布状态和量化结果。因此建议不要直接包装成“已显著降 低排查耗时”或“已避免线上事故”，除非你能补充真实数据。 转正或实习答辩前，建议补充 5 个数字： 1. 排查效率： 单次问题定位耗时从多少分钟降到多少分钟。 2. 数据召回： QA 需要的场景数据召回率或覆盖率提升了多少。 3. 异常发现： 巡检规则上线后发现过多少个真实异常，平均发现时长是多少。 4. 链路规模： 实际生效特征组合数、日写入量、查询 QPS、P99 延迟。 5. 成本控制： 采样后存储量相比全量存储节省多少。 更优的包装角度不是“我做了很多模块”，而是：我把 Pack 下发数据从分散、人工、临时的排查素材，建设成统一、自助、可校验的数据基础 设施。 这个表述更接近项目本质，也更容易体现实习产出的长期价值。