一面
- 自我介绍
- 最近这个团队规模大概是什么样的，你个人在其中主要是负责哪些模块
- 重点项目介绍
- 实体属性是纯粹你们spic中的定义，还是包含业务属性化呢
- 从实体A到实体B的查询路径都可以在你们这个平台上配置的吗
- 你们这是个树的结构还是图的结构？
- 实体本身也会有一些层级的属性吗？
- 能再详细表述下表结构存储大概是什么样的，这些实体，属性，包括之间的pipeline配置等
- 每次请求进来后动态生成pipeline，那当后续实体属性数据量过多，会出现瓶颈吗？是否有必要做一些缓存
- 如果是代码里写死的或者事先定义配置好的方式，新下游（实体）打算接入你这个系统时，有没有办法实现比较好的快速扩展？
- 实体A路由到实体B存在多个步骤的调用，涉及多个API，不同外部API在调用期间也可能存在一些依赖，耗时也会不同，是怎么实现一个比较合理的API编排
- 走的是泛化调用吗？
- 项目结果中提到的性能优化主要是来源于这个编排的合理性吗，还是有其它工作？
- 缓存记到什么维度？例如跨实体的查询，是会把中间上下文的路径配置也缓存下来吗
- 那假设现在的两条路径，一条是A到C，一条是B到C，那A可能取值是要实体C的 1,2,3属性，B取值要实体C的 4,5,6属性，那缓存大概是同样的结构？
- 这个local cache是怎么实现的，数据淘汰策略大概是怎样的
- 聊聊前一段经历，介绍一下这个预算池模块里头，你做了什么优化？
- 批量功能公共组件如何设计
- 乐观锁实现budget主表和category子表的并发保护这个具体指什么？
- 这个预算池中的每次金额扣减和返退，你们是直接写表吗？
- 假设把这个预算池投到C端场景，相当于我有一条预算记录被很多活动方引用，本身的核销量或消化预算量都非常大，你觉得针对目前直接扣减DB的方式，有什么改进的方式？
- 你们是强卡控还是弱卡控的，如果是强卡控的，上游的活动方强依赖于你这个预算够不够进行判断，如果是刚才削分流量的思路，会不会导致上游受到影响？
- 假设我再加个前提，就是强卡控的，类似库存扣除场景，该怎么去优化来保证高可用
- 万一就是很多流量就是通过了check，真实的扣减请求也非常大，该怎么通过DB改造或引入别的中间件方式呢？
- 预算扣除是一条记录还是多条记录？如果是一条记录可能都等不到单库单表的瓶颈，并发写请求很大时，单行的行锁就影响业务了，那这个问题又该怎么解决？（同步扣Redis，异步扣DB）
- MySQL相关问题，innoDB，隔离级别为RR，select * from tab_a where xxx for update，从一些锁算法和锁粒度分析这条语句？
- 可能带条件，也可能不带条件
- 可能命中索引，也可能不命中
- 可能有数据，也可能没有数据
- 代码题：leetcode.cn/problems/re…
- 怎么想着出来看看别的机会？
- 对后面的工作有什么期望，如果转Java可以接受吗
- 反问
CLC业务覆盖包括到家（送门到家相关，例如外卖，闪送），到店（用户到店消费相关，餐饮，酒旅，门票，到店综合（休闲娱乐，美容美发，医疗等））
CLC到店营销技术中台组（主要面向到店），搭建营销域的解决方案能力
- toC的优惠计算，优惠工具（优惠券，优惠立减，活动玩法等）
- 面向商户的招商报名，招选
- 底层选人，选品，策略计算等基建能力
HC主要是优惠券组，主要是优惠券的创建，查询，校验，交易链路上的使用，核销退款等等。
三高系统（节假日查询/发券流量达到百万QPS），直接和交易链路对接，可用性保障要求也比较高，业务复杂度极其高，对接到店2，30个垂类业务，挑战点是针对各个业务个性化场景，如何搭好平台能力又去兼容各个业务的扩展能力
