3.21 美团一面 - 核心本地商业-业务研发平台 35min

问题：
1. 自我介绍 3min
2. 问项目概述， 然后问你做了哪些部分 
3. 为什么要状态机？ 状态机的选型有什么依据
4. 那redis 分布式锁是怎么用的， 如果有人占了一直不取消怎么办？
5. 导出优化中， 分析是怎么做的， 具体是怎么优化的？各自因素开销占比多少？ 接口超时怎么办？
6.  讲一下你对Mysql索引机制的理解？
7. 实际使用用过哪些索引？
8. 事务隔离级别； 你们项目用什么级别？ 怎么实现可重复读?
9. Kafka ？ 可以做到保顺序吗？
10. 怎么做到高可用？ 
11. 用过redis？ redis 用过哪些数据结构？有哪些数据结构？
12. 问了下另一段实习经历；感觉就是确认我是不是干了活。。
13. 消息消费失败了怎么办？
14. 如果回过头来做？ 怎么做到不丢消息？
算法题: 二叉树层序遍历
队列5分钟秒了

回答：
1. 自我介绍
2. 先说项目总体概述1min 然后说自己负责的部分
3. 状态机的选型是为了定下业务模型， 状态机有三个核心参数可以作为统一的模型去丝滑的完成所有的状态流转， 同时具备单机cas加锁以及持久化机制至DB， 具备拓展性， 有新的需求不需要单独写接口和业务代码， 而是在配置类里面实现就可以。
4. 分布式锁的原因是用来保证数据一致性， 因为操作的对象我们认为是暴露出来的问题， 很容易被多人操作， 会出现分布式线程不安全的问题， 故采用分布式锁， 每个人操作前必尝试获取锁， 同时锁就限定5分钟操作时间， 每个人操作完也会释放锁， 取消Redisson自动看门狗机制， 在实际提交前还需要校验现在当前操作人是否持有锁， 否则拒绝
5. 因为一开始导出就是复用了查询的逻辑但是数据量暴增很容易OOM并且耗时很长故需要优化; arthas 分析stack 耗时， 分为网络（对外调接口）和sql开销， 46开， 对外调接口部分删掉不必要然后第一次查询存下数据； sql部分为防止OOM 采用分批分页的形式每次查100个， order by id ，用上次最后的id 作为下次查询的游标， 不仅可以走主键索引而且避开了深度分页的情况；接口肯定要超时，  先响应返回结果， 后台异步完成了后软件通知连接
6.  底层b+树， 分为主键索引、普通索引、唯一键索引、组合索引； 主键：不能为null 唯一性； 普通； 唯一键可以为null 但是不能重复； 组合 按顺序排序索引 
7. 都用过。
8. RU RC RR 可串行， 分别解决了脏读、 读不可提交、 读可提交、幻读的问题；用的是默认级别RR； MVCC 机制， RR是在第一次select 时候创建readview， 算法是根据max_trx_id、 min_trx_id本次事务id 去看是否处于活跃事务id中还是非活跃事务id 中， 如果不允许，则根据undolog 形成的版本链回退直到处于非活跃区间，则可以读； 本质上是一种快照读的形式， 不影响其他事务更新； 
9. 两种， topic 里面只给一个分区； 生产消费都在一个分区里面；因为分区内有序但是topic内不有序
10.  高可用机制：就是说如果broker 挂了依旧可以支持服务， 原理是分区有多个副本， 主分区负责读写， 从分区负责同步， 分区分布在不同的broker上， 一旦有主分区挂了， 会有选举机制让从分区顶上成为主分区; 又因为kafka具备持久化的刷盘机制， 定时以segement形式把消息存在磁盘里， 故如果所有的broker都挂了， 消息仍然在磁盘里， 重启broker可以恢复 
11. string 缓存数据 或者加锁setnx list存队列 hash 存对象 zset 用来做排行榜 set 用来做交集并集去重 hyperloglog做uv统计， bitmap做标志位识别
12. 也是讲没写的项目；具体讲效果
13.  会重试？重试次数超过了就丢掉不用了？
14.  首先消息队列作为一个中间件是不会丢消息的从生产者获取到的消息一定会发送给消费者， 所以只需要考虑消费者这端； 可以用队列或者单表去存储 收到的消息， 如果没有消费完保存待重试的状态； 后台开一个线程或者定时任务去巡检 单表扫没有消费的消息， 如果还是超过了某个阈值比如10次都没有成功， 我们会认为很可能是下游服务出现了问题， 做预警并彻底断死 只允许人工来看。 面试官说我思路非常好。。。
15. 反问部门业务也是做高并发的场景， 负责营销活动， 各种大促， 很多同事跳槽去了XXX哈哈哈哈哈， 美团混元体系的搭建； 别的也挺重要挺杂的事情， 场景高并发有很多， 有很多上百亿的数据， 接口填劵10wqps
16. 当场约二面