滴滴泡池子

九月初面的，二进宫，这次顺利通过一面。自我介绍实习系统采用异步架构，如何保证数据的实时性流量暴增导致消息堆积，如何保证数据的实时性日志是用来做什么的项目黑马点评共同关注是如何用 Redis 实现的；Redis Set 求交集的命令，复杂度；关注用户比较多时，如何优化性能点赞排序是如何做的统计签到天数是如何做的为什么用 HyperLogLog 做 UV 统计，而不是 Set讲一下秒杀中使用的 Lua 脚本的逻辑数据库和缓存的一致性是如何保证的；先改数据库，再删缓存有什么问题吗；可能出现缓存击穿，如何处理为什么要做库存预占为什么不用 MySQL 做模糊查询说一下数据同步的链路；既然是异步的，如何避...

从9.25面完到现在都没动静还有泡出来的希望吗

1.项目介绍2.说一下项目，云核心网 SMF，会话管理具体覆盖哪些能力？3. 控制面挂了、用户面还活着时，为什么大多数 TCP 连接不会断？5.控制面从切换到恢复这段窗口，UPF 上隧道状态怎么保持一致？6.如果 UPF 清理策略触发早于SMF 恢复，你们如何避免半恢复这种情况呢7.我给你个具体的业务场景，假设现在是双11临近期间，和往年一样，各大电商平台都会搞一些大促活动。今年我们（以xx养车为例）打算通过一个“影响力竞拍”的方式来做这个大促活动。这个竞拍的玩法在现实中其实也比较常见，比如车牌竞拍大致逻辑是这样的：我们选取一个有价值的拍品（比如一辆 Tesla Model Y），它的市场价大概是40万元。为了吸引更多用户参与，我们将它的起拍价设置为远低于市场价，比如说 1 万元。所有具有出价资格的注册用户都可以参与竞拍。活动时间就是双11当天这一天。在这一天中，所有参与者都可以出价。活动结束时，出价最高的用户就可以以他所出的价格购买该商品。同时，为了控制竞拍节奏，我们会设置一些比如每个用户最多只能出价3次；每次出价必须至少比当前可接受的最低出价高出100元；出价区间会随着竞拍的推进动态变化，比如最开始是 1 万 ~ 1.1 万，后续可能变成 5 万 ~ 5.1 万，这个系统要考虑非常高的并发压力，因为我们的平台注册用户有上亿，活动当天流量会非常大。所以请你思考一下：如果由你来设计这个系统，你会怎么来设计8.如果我们放宽到区间出价的规则，也就是说用户在活动期间都可以自由出价，不一定非要比当前最高价高，只要在合法区间内就行，你怎么来设计11.我们不要求每次都比当前价高，那实时阶段你写什么呢12.那比如22:00 到点就要封盘，新来的请求你怎么处理？可以允许在路上的请求吗？就是它这个缓冲窗口大概是多久呢13. 最终以谁为准，因为刚刚提到了有缓存快照 / 数据库 / 消息日志回放的最终状态？14. 如果出现同样的价格并列呢，比如价格相同，接下来呢？你会按什么去做这种二级排序？15.这规则要不要提前公示出来

滴滴网约车还会发意向吗，鼠鼠9月25日参加了后端一二面，公众号状态一直是面试考察中，问hr说是部门复盘流程，通过了11月份沟通offer，请问这种情况还能泡出来吗？