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

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