小红书C++搜推工程面经|引用占用内存吗

希望大家可以帮我权衡一下两个offer本人做后台开发工作offer1：鹅厂，做广告业务。优点是业务稳定增长，培养完善且理论上试用期压力不大，相对后者wlb。目前来看缺点是薪资很低（不可A）。offer2：宇宙厂，做搜索架构。优点是薪资较高，月base甚至高于前者10。目前来看缺点是压力大。此外，我也有点在意其培养机制与试用期问题。本人比较care的是：1. 后者试用期裁员问题以及新人培养问题。（总感觉不是特别稳定）2. 后者工作强度与工作压力问题。（个人可能还是希望能wlb一些，因为确实身体可能没那么耐造）3. 前者薪资问题。（前者薪资真的很白菜且不可A）希望大家能给些建议，如果实在是都不行我就全力备战补录和春招了。最后希望大家都能顺利找到自己的offer！

有没有了解字节 data 下的推荐架构的 uu，问问这个部门的情况还有强度作息这些如何呀？

你xx项目/xx实习/xx经历中 你觉得最有挑战、创新点、你最大的成长是什么？面试一共一小时，抛开八股、算法估计只有半小时，如何在这短短的半小时给面试官留下最有差异化、竞争力的印象其实就取决于这类问题的回答。大部分人可能的回答方式是：xx项目用了xx技术，优化了性能xx%，节省了人力xx%。 这种回答固然没有问题，但是没有足够的让面试官了解到最全面的你。好的回答方式应当是从项目背景出发，按照项目背景->产品设计->技术选型->问题发现->产品优化->技术优化->最终成果 这样的思路去回答问题。用大家最熟悉的外卖项目举个例子：面试官：你这个项目最大的难点在哪？回答：【面试官您好！我选择重点分享 “订单高峰期高并发处理与系统稳定性保障” 这个核心技术难点的实践过程。首先先介绍下项目背景：苍穹外卖是覆盖 C 端用户、B 端商家、骑手端的全链路 O2O 餐饮平台，核心支撑 “下单 - 接单 - 配送 - 支付 - 统计” 全流程，而午晚高峰的高并发下单是平台最核心的场景之一，直接影响三方用户的核心体验，也是整个项目最关键的技术挑战。从产品设计来看，我们的核心诉求很明确：高峰时段用户下单支付不能卡顿、不能超时，要求响应时间≤3 秒；商家要实时收到订单通知，骑手能及时获取配送单，同时绝对不能出现菜品超售的情况 —— 毕竟超售不仅会让用户投诉，还会影响商家口碑。初期我们的技术选型是 SpringCloud Alibaba 微服务架构，因为微服务能横向扩展，应对并发压力；用 MySQL 存订单核心数据，Redis 缓存热销菜品这类热点数据，RabbitMQ 来解耦订单推送、短信提醒这些异步通知，核心思路就是 “拆分压力、解耦流程”，让每个服务专注做自己的事。但压测的时候，问题很快就暴露了：当并发量超过 300QPS，下单接口响应时间直接冲到 5 秒以上，完全不达标；而且热点商家比如连锁快餐，出现了明显的超售 —— 多个用户同时下单同一款菜品，库存校验没控制好，导致实际卖出的比库存多；另外骑手端还出现订单推送延迟，因为 RabbitMQ 队列堆了太多消息，消费速度跟不上。发现这些问题后，我们先从产品层面做了优化：把下单流程拆成优先级，核心的 “创建订单 + 库存预占” 先完成，让用户快速看到下单成功，而积分赠送、短信通知这些非核心流程，后续异步处理；还加了库存预占机制，用户下单后先占住库存 5 分钟，没支付就自动释放，从业务上避免超售；骑手端这边，给订单分了级，距离商家近、路线顺的骑手，优先推高优先级订单，比如快超时的单子。技术层面的优化是重点，我们做了四件核心事：第一是并发控制，用 Redis+Lua 脚本实现库存原子预减，因为 Lua 脚本能保证操作的原子性，不会出现并发冲突；给热点商家加了 Redisson 分布式锁，限制单商家的并发下单量，避免单个商家拖垮整个系统。第二是流量防护，用 Sentinel 对下单接口做限流，峰值设到 500QPS，超出的请求就返回 “高峰期稍候再试” 的友好提示，防止系统雪崩。第三是异步提速，把下单流程拆成 “同步核心 3 步 + 异步非核心 4 步”，异步任务通过 RabbitMQ 投递，消费端用多消费者组加线程池提升处理速度，还设了死信队列兜底失败的消息，避免消息丢失。第四是缓存优化，把热点商家的菜品信息、库存都缓存到 Redis，设 3 分钟过期；同时用 Canal 监听 MySQL 的库存变更，实时同步到 Redis，保证缓存和数据库一致。最终的成果也很显著：高峰时段能支持 500+QPS 的并发下单，接口响应时间控制在 800ms 以内，超时率低于 0.1%；热点商家的超售率降到了 0，骑手端的订单推送延迟也≤500ms，完全满足了产品设计的核心诉求，也保障了平台高峰时段的稳定运行。这个难点的解决，让我深刻体会到 “产品诉求引导技术方案，技术优化落地业务价值” 的思路，也积累了高并发场景下 “限流、缓存、异步、分布式锁” 的实操经验，也是我做这个项目中收获的最大成长】这种有头有尾的介绍，能够带给面试官一种你能依赖自己设计架构-发现问题-解决问题-总结问题的能力，从而与其他同学拉开差距。如果有帮助，希望能送朵小花。

1.项目介绍。2.菜鸟有大量复杂的B端系统(如WMS、TMS)。在设计一个高度复杂、表单项繁多的“创建物流订单”页面时你会如何设计其组件架构和状态管理?3.在物流中后台系统中，经常有“拖拽排序”、“动态增删表单项”的需求。如果要你实现一个可拖拽的列表，你的技术思路是什么?4.菜鸟的物流大屏(“天眼”系统)需要展示全国包裹的实时流动数据。如果要你负责这个可视化大屏，你会如何选型(例如 ECharts,AntV G6/L7)?如何处理海量数据的渲染性能问题?5.包裹“实时追踪”是菜鸟的核心功能之一。在H5端展示一个包裹的实时物流轨迹(包含地图和时间轴)，你会如訥以有设计这个功能?如何与地图API(如高德地图)交互?6.假设你负责的菜鸟驿站站长工作台(PC端)首页加载很慢，你会从哪些方面去排查和优化?(请考虑B端系统的特点)7.物流系统的很多页面数据需要高实时性(例如库存、包裹状态)。你会如何实现前端数据的“实时”更新?(轮询、WebSocket、SSE等)请分析它们的优劣。8.你对菜鸟的业务有什么了解吗?从前端的角度，你认为菜鸟的核心技术挑战在哪里?