滴滴基础平台意向

🍡核心目标不同私募量化：极致的性能与低延迟（纳秒/微秒级响应），直接关联交易盈亏。互联网大厂：高并发、高可用、可扩展性（应对百万级QPS）。🍡技术挑战不同私募量化：① 硬件级优化（CPU缓存、内存对齐、指令流水线）。② 网络协议优化（UDP/FPGA、内核旁路技术如DPDK）。③ 高频交易系统的容错与回撤控制（单点故障可能导致巨额损失）。互联网大厂：① 分布式系统设计（一致性协议、分库分表）。② 云原生技术（K8s、Service Mesh）。③ 大数据处理（PB级存储、实时计算）。🍡技术栈涉及方面不同私募量化：C++标准贴近底层（甚至C++11/14），可能涉及Linux内核修改、定制化编译器等。互联网大厂：C++多用于基础设施（存储引擎、推荐系统），配合Go/Python生态。🍡业务逻辑不同私募量化：代码直接体现交易策略（如做市、套利），需与量化研究员深度协作。互联网大厂：服务于用户产品（如广告推荐、支付系统），需求来自产品经理。

boss投完hr打电话让去线下面，结果到地方面试说不招应届生，又让我回去了？？？？？来回4个多小时的路程，折腾收拾又浪费了一天。hr不能看清楚点？😁

线程池项目 给了实例化线程池的参数，问他是干什么用的，就介绍各个参数的作用怎么根据运行状态调整参数，举例说任务堆积太多，就申请多线程问计算密集型的用什么配置，问跟上面的例子矛盾了。所以应该加上对cpu、io和内存等的监控。线程的调度是jvm还是操作系统，是用户态还是内核态答了内核态，为什么用内核态，用户态不是更快吗，答了安全问题，问有什么造成安全的场景（好像可以从协程和线程的优缺点来回答）索引讲一下innoDB存储引擎的模型，就是索引的存储结构等，讲了B+树，聚簇索引和非聚簇索引，存储的东西。问为什么不用B树和红黑树假设订单用联合索引查询， select * where "楼栋号" = and "手机号" = ，问用哪种顺序建立索引好。主键用相对自增的还是用随机的，答了自增，顺序写比较快（他不太满意这个答案）日志redoLog的作用。问为什么不直接把数据刷盘，而是先持久化redoLog，开销的对比。讲了可以用后台线程，问后台线程阻塞了怎么办，数据不久丢失了。想起来好像是redoLog可以先写到内核缓冲区，这样只要系统不崩溃就不会丢失。binLog的作用，跟redoLog的区别外卖项目是自己练手还是真实应用的，QPS有多高手撕给一个时间区间，起始时间和结束时间，格式“HH:MM:ss Weekday”一个具体的时间点，何时"Y-M-D-HH:MM:ss"，判断时间点在不在每周的这个区间内，如果在直接返回时间区间，不在返回离它最近的时间区间（以"Y-M-D-HH:MM:ss"的格式）

项目适用岗位：互联网C++后端， 大模型端侧部署 ，自动驾驶/机器人具身智能C++开发1、底层通信组件方案通信模式封装支持兼容多种通信模式普通消息模式：PUB/SUB(发布订阅)、PUSH/PULL(点对点通信)RPC 模式：通过ZMQ_REP、ZMQ_REQ 封装 RPC 功能RPC功能支持 RPC 方法的动态注册提供默认的 RPC 方法列表查询支持 RPC 调用2、Master模块（实现思路：类似ROS1 Master功能, 更轻量化）背景：分布式大模型系统中，多个节点（如llm/vlm， asr，tts， camera，yolo）需要动态发现彼此并高效通信，外部用户可以动态管理节点内任务调度​​节点注册与发现​实现轻量化内存kv缓存数据库：存储节点元信息；并提高sql查询接口，供节点动态通信节点启动时向Master模块注册，上报自身元信息；节点通信时自动匹配动态任务调度分配设计用户请求-任务匹配机制：外部用户仅封装简易数据包请求，可实现动态控制各个模块(启停/llm推理等)3、Channel模块封装上层发布-订阅(PUB/SUB)和点对点通信(PUSH/PULL)混合通信模式设计闭包，通过闭包将​​网络层​​（ZeroMQ）与​​业务层​​（用户回调）解耦，同时隐式维护了通信上下文状态。4、Infra基础架构模块rpc分布式控制指令下发+异步​事件驱动架构​​注册rpc_setup/rpc_pause等分布式控制接口->注册eventpp事件监听->上层触发rpc调用 -> 添加eventpp事件队列中-> 异步事件驱动->各子类Setup/Pause等功能接口标准化控制协议​​基于抽象接口（Setup/Pause等）实现跨模块统一管控，支持LLM/ASR/TTS等异构节点无缝集成5、TASK模块与Infra模块关系：类似与进程和线程之间关系，Infra模块负责资源分配和流程管控，TASK模块是真正干活的，干的活如下：各模块中模型生命周期管理（加载/卸载）infra推理包装回调输出等等