問題：
1. 自我介紹 3min
2. 問項目概述， 然后問你做了哪些部分 
3. 為什么要狀態(tài)機？ 狀態(tài)機的選型有什么依據
4. 那redis 分布式鎖是怎么用的， 如果有人占了一直不取消怎么辦？
5. 導出優(yōu)化中， 分析是怎么做的， 具體是怎么優(yōu)化的？各自因素開銷占比多少？ 接口超時怎么辦？
6.  講一下你對Mysql索引機制的理解？
7. 實際使用用過哪些索引？
8. 事務隔離級別； 你們項目用什么級別？ 怎么實現可重復讀?
9. Kafka ？ 可以做到保順序嗎？
10. 怎么做到高可用？ 
11. 用過redis？ redis 用過哪些數據結構？有哪些數據結構？
12. 問了下另一段實習經歷；感覺就是確認我是不是干了活。。
13. 消息消費失敗了怎么辦？
14. 如果回過頭來做？ 怎么做到不丟消息？
算法題: 二叉樹層序遍歷
隊列5分鐘秒了

回答：
1. 自我介紹
2. 先說項目總體概述1min 然后說自己負責的部分
3. 狀態(tài)機的選型是為了定下業(yè)務模型， 狀態(tài)機有三個核心參數可以作為統(tǒng)一的模型去絲滑的完成所有的狀態(tài)流轉， 同時具備單機cas加鎖以及持久化機制至DB， 具備拓展性， 有新的需求不需要單獨寫接口和業(yè)務代碼， 而是在配置類里面實現就可以。
4. 分布式鎖的原因是用來保證數據一致性， 因為操作的對象我們認為是暴露出來的問題， 很容易被多人操作， 會出現分布式線程不安全的問題， 故采用分布式鎖， 每個人操作前必嘗試獲取鎖， 同時鎖就限定5分鐘操作時間， 每個人操作完也會釋放鎖， 取消Redisson自動看門狗機制， 在實際提交前還需要校驗現在當前操作人是否持有鎖， 否則拒絕
5. 因為一開始導出就是復用了查詢的邏輯但是數據量暴增很容易OOM并且耗時很長故需要優(yōu)化; arthas 分析stack 耗時， 分為網絡（對外調接口）和sql開銷， 46開， 對外調接口部分刪掉不必要然后第一次查詢存下數據； sql部分為防止OOM 采用分批分頁的形式每次查100個， order by id ，用上次最后的id 作為下次查詢的游標， 不僅可以走主鍵索引而且避開了深度分頁的情況；接口肯定要超時，  先響應返回結果， 后臺異步完成了后軟件通知連接
6.  底層b+樹， 分為主鍵索引、普通索引、唯一鍵索引、組合索引； 主鍵：不能為null 唯一性； 普通； 唯一鍵可以為null 但是不能重復； 組合 按順序排序索引 
7. 都用過。
8. RU RC RR 可串行， 分別解決了臟讀、 讀不可提交、 讀可提交、幻讀的問題；用的是默認級別RR； MVCC 機制， RR是在第一次select 時候創(chuàng)建readview， 算法是根據max_trx_id、 min_trx_id本次事務id 去看是否處于活躍事務id中還是非活躍事務id 中， 如果不允許，則根據undolog 形成的版本鏈回退直到處于非活躍區(qū)間，則可以讀； 本質上是一種快照讀的形式， 不影響其他事務更新； 
9. 兩種， topic 里面只給一個分區(qū)； 生產消費都在一個分區(qū)里面；因為分區(qū)內有序但是topic內不有序
10.  高可用機制：就是說如果broker 掛了依舊可以支持服務， 原理是分區(qū)有多個副本， 主分區(qū)負責讀寫， 從分區(qū)負責同步， 分區(qū)分布在不同的broker上， 一旦有主分區(qū)掛了， 會有選舉機制讓從分區(qū)頂上成為主分區(qū); 又因為kafka具備持久化的刷盤機制， 定時以segement形式把消息存在磁盤里， 故如果所有的broker都掛了， 消息仍然在磁盤里， 重啟broker可以恢復 
11. string 緩存數據 或者加鎖setnx list存隊列 hash 存對象 zset 用來做排行榜 set 用來做交集并集去重 hyperloglog做uv統(tǒng)計， bitmap做標志位識別
12. 也是講沒寫的項目；具體講效果
13.  會重試？重試次數超過了就丟掉不用了？
14.  首先消息隊列作為一個中間件是不會丟消息的從生產者獲取到的消息一定會發(fā)送給消費者， 所以只需要考慮消費者這端； 可以用隊列或者單表去存儲 收到的消息， 如果沒有消費完保存待重試的狀態(tài)； 后臺開一個線程或者定時任務去巡檢 單表掃沒有消費的消息， 如果還是超過了某個閾值比如10次都沒有成功， 我們會認為很可能是下游服務出現了問題， 做預警并徹底斷死 只允許人工來看。 面試官說我思路非常好。。。
15. 反問部門業(yè)務也是做高并發(fā)的場景， 負責營銷活動， 各種大促， 很多同事跳槽去了XXX哈哈哈哈哈， 美團混元體系的搭建； 別的也挺重要挺雜的事情， 場景高并發(fā)有很多， 有很多上百億的數據， 接口填劵10wqps
16. 當場約二面