滴滴一面

    上周刚面的滴滴，趁着记得，这会整理发出来。

1. 给定一个字符串，每2k个字符的前k个字符进行翻转。不够2k个的，对剩下的最多前k个进行翻转

2. 一个明星有很多粉丝，发一条消息，所有粉丝都能收到，一个粉丝可以查看他关注的所有明星的消息。有哪些模型？

• 读扩散，每个明星发消息时都写入到自己的信箱中。然后粉丝来拉取所有的消息。

• 用户侧是个业务大会话，包含所有聊天记录，其实这里是个大信箱，做了双写。所以用户侧只需要拉取一次即可，不知道对应的客服叫什么。但是客服侧需要拉取所有的小会话，每个小会话对应不同用户，每个小会话可以拉取到该订单的人机消息和人人消息，客服可以查看该订单的所有历史会话。售前客服可以看到该用户的多次咨询消息。webpush也是读扩散，对某个业务domain pipeline，有对应的通道，前端建连时，会拉取所有通道的数据。

• 写扩散，每个明星发消息时，写入到所有粉丝信箱，读取时每个粉丝从自己的信箱读取即可。粉丝的信箱含有他关注的所有明星的消息。如果粉丝很多，如上千万，则会爆炸。

• 优化和变形，相结合。例如写很多次，那肯定是优先读扩散，然后对读扩散进行优化，例如添加缓存，毕竟数据不会怎么变化。如果读取很多次，一般读取不会很多，可以并发拉取，或者添加关联关系，对于大v粉丝，可以对大v进行直接写，大v毕竟不会很多，那么他读取的时候就会很方便。

• 总而言之，大v自己写一次，给大部分粉丝拉取，如果自己的粉丝有大v，单独投递一份，免得大v要拉取一堆粉丝的消息，拉取一次就可以了

3. 如何做分库分表，什么情况要分库分表，如果要查询其他维度的数据怎么办。

   宽表es。

4. 分别在哪些场景用了redis。缓存如何做更新。

   定时更新和实时刷新。

5. 音视频通信的定位

• 打磨自研，指标对齐。诊断数据收集，大盘绘制。
• 容灾降级切换，业务快速集成。
• 后处理
• 增值服务
• 指标，进房成功率，百秒卡顿率，订阅成功率，进房耗时。

6. openapi如何保证对外扩展能力？

• 参数规范，响应码规范
• 限流
• 鉴权（appkey/appsecret）

7. 有时候数据量很大，仅仅是少部分极值有问题，如何排查？

   例如某个redis实例超时了，其他实例都正常，这个时候看p50是看不出来的，需要看p99，甚至p9999，才能看到这部分超时情况。