1. 主鍵索引與非主鍵索引區別? https://www.cnblogs.com/heishuichenzhou/p/10813463.html
非主鍵索引查找數據，根據條件，查找到對應的主鍵ID，然后根據主鍵ID去索引表里面找對應的數據
2. redis主從同步原理(問了3次)
全量和增量同步
全量:
Redis全量復制一般發生在Slave初始化階段，這時Slave需要將Master上的所有數據都復制一份。
具體步驟如下：
1）從服務器連接主服務器，發送PSYNC命令；
2）主服務器接收到SYNC命名后，開始執行BGSAVE命令生成RDB文件並使用緩沖區記錄此后執行的所有寫命令；
3）主服務器BGSAVE執行完后，向所有從服務器發送快照文件，並在發送期間繼續記錄被執行的寫命令；
4）從服務器收到快照文件后丟棄所有舊數據，載入收到的快照；
5）主服務器快照發送完畢后開始向從服務器發送緩沖區中的寫命令；
6）從服務器完成對快照的載入，開始接收命令請求，並執行來自主服務器緩沖區的寫命令；
增量:
增量復制的過程主要是主服務器每執行一個寫命令就會向從服務器發送相同的寫命令，從服務器接收並執行收到的寫命令。
斷線之后的命令，如何同步?
redis2.8之前, 全量同步，效率低
之后，增量同步, 需要關注以下幾個點:
如何記錄斷線后的命令？
1.主從都會記錄復制的偏移量(記錄上次復制到哪里了)
主從服務器都會記錄上次復制的偏移量
2.主服務器復制積壓區
從服務器斷線后，主服務器的命令都會放到積壓區，等待重服務器上線以后同步
3. 如何判斷是全量同步還是增量同步
主服務器和從服務器啟動以后，會生成一個40位的ID，這是每個服務器的標示。
當初次進行同步的時候，主服務器會把自己的ID發給從服務器保存；斷線重連后，從服務器發送同步命令，
主服務器會講從服務發送來的ID和自己運行的ID進行對比，如果一致，執行增量同步；如果不一致，執行全量同步；
3. redis slot
Redis 集群使用數據分片（sharding）而非一致性哈希（consistency hashing）來實現： 一個 Redis 集群包含 16384 個哈希槽（hash slot）， 數據庫中的每個鍵都屬於這 16384 個哈希槽的其中一個， 集群使用公式 CRC16(key) % 16384 來計算鍵 key 屬於哪個槽， 其中 CRC16(key) 語句用於計算鍵 key 的 CRC16 校驗和 。
集群中的每個節點負責處理一部分哈希槽。
節點 A 、B 、C 的例子中， 如果節點 B 下線了， 那么集群將無法正常運行， 因為集群找不到節點來處理 5501 號至 11000號的哈希槽。
首先要開啟cluster-enable
> cluster meet ip port 可以讓集群握手，加入到集群中
A 與 B 握手，握手成功后，會通過gossip協議廣播給集群中的其它節點，讓其它節點與節點B進行握手，經過一段時間握手成功。B也就加入到集群中了。
> cluster nodes 查看集群節點
> cluster addslots 0 1 2 3 .... 分配slot
只有slot全部被分配以后集群才會上線。
集群中執行命令
當16384個slot被分配完畢后，集群上線；客戶端就可以發送命令到集群中；
當客戶端的命令發送到集群后，接收命令的node會根據key計算出要處理的命令屬於哪個slot,
如果這個槽點是在自己這台機器上, 直接保存即可
如果不是，返回一個moved錯誤，就會給客戶端返回一個redirect至正確的節點，然后在執行命令；
計算key屬於哪個slot
def slot_nums(key):
return crc16(key) & 16384
> 查看key屬於哪個slot: cluster keyslot "name"
def cluster_keyslot(key):
slot = slot_nums(key)
return reply_client(slot)
4. redis常用的命令
5. 索引底層實現原理
6. 短url設計
7. jwt原理
8. 分布式算法raft與paxos區別
9. in操作 對於list, set, tuple, dict 效率如何?
10. django中間件與裝飾器區別
11. django路由到達視圖函數的流程(源碼級)
12. 數據庫管理工具
13. celery相關: 異步任務怎么處理? 用celery做什么？celery任務在執行過程中，手動中斷, 脫離supervisor管理，如何進行處理
14. io模型？io多路復用？epoll水平觸發和邊緣觸發
水平觸發:當被監控的文件描述符上有可讀寫事件發生時，epoll_wait()會通知處理程序去讀寫。如果這次沒有把數據一次性全部讀寫完(如讀寫緩沖區太小)，那么下次調用 epoll_wait()時，它還會通知你在上沒讀寫完的文件描述符上繼續讀寫，當然如果你一直不去讀寫，它會一直通知你！！！如果系統中有大量你不需要讀寫的就緒文件描述符，而它們每次都會返回，這樣會大大降低處理程序檢索自己關心的就緒文件描述符的效率！(也就是描述符有變化，但是你不想讀，人家就不停提醒你去讀)
邊緣觸發：當被監控的文件描述符上有可讀寫事件發生時，epoll_wait()會通知處理程序去讀寫。如果這次沒有把數據全部讀寫完(如讀寫緩沖區太小)，那么下次調用epoll_wait()時，它不會通知你，也就是它只會通知你一次，直到該文件描述符上出現第二次可讀寫事件才會通知你！！！這種模式比水平觸發效率高，系統不會充斥大量你不關心的就緒文件描述符(也就是描述符有變化，人家只提醒你一次去讀，如果你沒去讀，人家不管了)
15. 項目技術點，流程
16. 迭代器，生成器，可迭代對象原理
17. redis分布式鎖？
18. 分布式ID如何生成？
19. 可重入鎖 https://www.cnblogs.com/gxyandwmm/p/9387833.html python 里面的threading.Rlock() https://studygolang.com/articles/16480
20. mysql事務隔離級別(從小到大)
21. 索引失效場景? mysql哪些類型會導致索引不可用？
22. nginx配置相關
23. 消息隊列相關, rabbitmq
24. 設計一個消息隊列
25. etcd實現原理；一致性hash算法
26. tcp握手流程
27. 簡單說說微服務
28. 簡單說說常見過的rpc框架
29. 服務之間如何通信
20. 緩存雪崩？穿透？
哎，最后止步於4面，有點可惜～