小红书 Java / 后端怎么准备
小红书后端常围绕笔记、评论和关系。公开讨论里「计数」和「Feed」出现得多，因为它们又热又容易不一致。
本页五题走计数、Feed、评论、关系链和内容安全协作。用你的社区或内容项目经历替换。
小红书怎么面Java后端
- 会问 Feed 是拉还是推，以及你如何处理已读和重复。
- 评论和计数会追问缓存不一致。
- 内容安全是底线，工程方案要留审核钩子。
面试阶段与知识点
第一批不把每个阶段拆成独立 URL，避免程序化重复页。阶段对应下面的题，练完再用模拟面试串起来。
- Feed 与计数：热 Key 和重复。
- 评论与审核：写入路径上的安全钩子。
- 关系链缓存：关注列表的一致。
- 安全协作：体验和审核的冲突。
值得开口练的题
每题给考察点、思路、结构化参考答案和追问。参考答案用来组织语言，面试时必须换成你自己的项目事实。
笔记点赞数在 Feed 和详情页不一致，你怎么收口？
考察点
- 多入口读取
- 最终一致
- 用户感知
回答思路
先承认不同入口可能读不同缓存层，再给修复路径和对齐机制，而不是否认不一致。
结构化参考答案
- 详情页走更准的计数服务，Feed 允许短延迟展示，但要设对齐上限和纠偏任务。
- 用户点赞成功后对当前用户立即加一，避免自己刚点的赞在列表里看不见。
- 后台用明细流水定期重算覆盖缓存，禁止 Feed 和详情两个入口长期分叉。
- 展示层可做数字平滑过渡，避免点赞数来回跳动伤害用户对内容热度的信任。
面试官可能追问
- Feed 缓存多久必须对齐？
- 刷赞如何延迟入账？
- 重算会不会把已展示的数改小？
关注 Feed 是推还是拉，粉丝千万的博主怎么处理？
考察点
- 大 V 问题
- 混合模型
- 存储放大
回答思路
大 V 不能纯推模式；要讲推拉混合、存储放大上限和已读去重的完整方案。
结构化参考答案
- 粉丝量少的作者发文时写入粉丝收件箱，读 Feed 时直接拉取收件箱内容。
- 超过阈值的作者不再写全量收件箱，粉丝侧改为拉取作者时间线并合并排序。
- 已读游标和去重逻辑要覆盖推拉混合场景，避免同一笔记在 Feed 里重复出现。
- 评估推模式的写放大成本，设定粉丝数阈值和存储上限，防止大 V 发文拖垮存储。
面试官可能追问
- 阈值如何定？
- 取消关注后收件箱脏数据怎么办？
- 置顶和广告如何插入？
评论写入如何接审核，既不堵发布也不把违规放出去？
考察点
- 同步拦截
- 异步人审
- 可见范围
回答思路
分层处理：机器先挡明显违规，其余先对作者或小范围可见，人审结果必须回写。
结构化参考答案
- 同步过轻量规则和词表，明确违规的评论当场拒绝并给出可理解的失败原因。
- 可疑评论进入待审队列，作者可见、他人不可见，避免违规内容公开扩散。
- 人审结果回写后通知作者处理进度，避免评论石沉大海引发重复发布和投诉。
- 审核服务超时走安全默认策略：宁可延迟公开，也不默认放行未审内容。
面试官可能追问
- 误伤如何申诉？
- 热点笔记评论洪峰怎么削？
- 删除评论后计数和 Feed 摘要怎么改？
关注关系缓存在取消关注后仍能刷到对方内容，怎么查？
考察点
- 缓存失效
- 多级缓存
- 读己之写
回答思路
这是缓存失效顺序和并发写回问题；取消关注后要保证读己之写和下游键清理。
结构化参考答案
- 取消关注先更新权威存储，再删除关系缓存和 Feed 相关键，顺序不能颠倒。
- 读路径若命中旧缓存，用版本号或时间戳判断过期，拒绝返回已取消的关系内容。
- 对操作用户保证读己之写，避免自己取消关注后仍能在 Feed 刷到对方笔记。
- 必要时采用延迟双删或订阅失效消息，防止并发请求把旧关系写回缓存。
面试官可能追问
- 关注列表分页缓存如何局部失效？
- 双向关注和单向关注是否共用缓存？
- 如何观测失效延迟？
运营要更快放出评论提升氛围，安全要更严，你怎么推进？
考察点
- 分层发布
- 指标
- 灰度
回答思路
给可灰度的中间态方案，而不是站队；用分层策略同时看氛围和安全两类指标。
结构化参考答案
- 提出按内容风险分层：低风险类目加速放出，高风险类目维持严格审核策略。
- 约定误伤率和违规漏放双指标，任何一边恶化都能触发回滚或收紧。
- 选小社区或低流量场景灰度，观察氛围、举报和客诉是否同时恶化。
- 把默认策略文档化并定期复盘，避免每次冲突都靠临时协调或口头约定。
面试官可能追问
- 漏放造成舆情谁负责？
- 你如何向两边汇报？
- 灰度失败如何回滚可见性？
和岗位、模拟面试一起用
资料管理里保存目标岗位 JD，模拟面试会按简历出题。点题目下的按钮会把本题带进模拟开场，仍需先绑定简历与岗位。