快手面試總結

• 一面
  • 演算法
    跳臺階問題
  • 穩定且有上限的頻寬條件下，超大檔案從server傳輸到client端，選擇一個tcp連線快，還是構建多個tcp連線
    考察點：tcp連線的滑動視窗＋頻寬受限
    • 區域網內，頻寬受限時，每秒鐘傳輸的資訊量大小被限制，就算是多個tcp連線，也只是多個tcp傳輸的資訊量和＝單個tcp連線傳輸的資訊量。
    • 公網上，可能由於tcp被阻塞斷開連線，此時多條tcp連線要比單tcp連線更保險，所以此時多tcp連線可能效率更高。
  • 執行緒和程序的區別
  • 執行緒模型、執行緒狀態切換
    從就緒、執行、阻塞到核心態和使用者態的切換，幾個方面自己講了講。
    • 分類：使用者級執行緒、核心級執行緒
    • 使用者級執行緒
      • 當執行緒在使用者空間下實現時，OS對執行緒的存在一無所知，OS只能看到程序
      • 當一個執行緒完成了其工作或等待需要被阻塞時，其呼叫系統過程阻塞自身，然後將CPU交由其它執行緒
      • 這種模式的好處
        • 在使用者空間下進行程序切換的速度 遠快於 在作業系統核心中
        • 使用者空間下實現執行緒使得程式設計師可以實現自己的執行緒排程演算法
        • 由於作業系統不需要知道執行緒的存在，所以在任何作業系統上都能應用
      • 這種模式的缺點
        • 由於作業系統不知道執行緒的存在，因此當一個程序中的某一個執行緒進行系統呼叫時，比如缺頁中斷而導致執行緒阻塞，此時作業系統會阻塞整個程序
        • 造成程式設計困難，我們在寫程式的時候必須仔細斟酌在什麼時候應該讓出CPU給別的執行緒使用
        • 假如程序中一個執行緒長時間不釋放CPU，因為使用者空間並沒有時鐘中斷機制，會導致此程序中的其它執行緒得不到CPU而持續等待
    • 核心級執行緒

      • 這種模式下，作業系統知道執行緒的存在

      • 實現執行緒造成阻塞的執行時呼叫(System runtime call)成本會高出很多

      • 當一個執行緒阻塞時，作業系統可以選擇將CPU交給同一程序中的其它執行緒，或是其它程序中的執行緒。而在使用者空間下實現執行緒時，排程只能在本程序中執行，直到作業系統剝奪了當前程序的CPU

      • 這種模式的優點

        • 使用者程式設計簡單，使用者程式設計師在程式設計的時候無需關心執行緒的排程，即無需擔心執行緒什麼時候會執行，什麼時候會掛起
        • 如果一個執行緒執行阻塞操作，作業系統可以從容地排程另外一個執行緒執行。因為作業系統能監控所有執行緒。

      • 這種模式的缺點

        • 效率較低。因為執行緒在核心態實現，每次執行緒切換都需要陷入到核心，由作業系統來進行排程
        • 佔用核心稀缺的記憶體資源
    • 混合模式－現在OS的實現方式
      • 使用者態的執行系統負責程序內部執行緒在非阻塞時的切換
      • 核心態的作業系統負責阻塞執行緒的切換
      • 每個核心態執行緒可以服務一個或多個使用者態執行緒
      • 在這種模式下，作業系統只能看到核心執行緒
  • mysql架構＋這樣設計的原因
  • redis專案中怎麼用的
  • redis為什麼設計成單執行緒的
  • mysql的事務，acid特性 ，宕機時正在處理的事務會如何？
    • 針對突然宕機的問題
      不會自動繼續執行，不會自動直接回滾，但是可以人工手動選擇繼續執行或者直接回滾，依據是事務日誌。
      事務開啟時，事務中的操作，都會先寫入儲存引擎的日誌緩衝中，在事務提交之前，這些緩衝的日誌都需要提前重新整理到磁碟上持久化，這就是人們口中常說的“日誌先行”(Write-Ahead Logging)
    • 日誌分為2種
      • redo log
        • 保障的是事務的永續性和一致性
        • 在系統啟動的時候，就已經為redo log分配了一塊連續的儲存空間，以順序追加的方式記錄redo log，通過順序io來改善效能
        • 所有的事務共享redo log的儲存空間，它們的redo log按語句的執行順序，依次交替的記錄在一起
        • 如果資料庫崩潰或者宕機，那麼當系統重啟進行恢復時，就可以根據redo log中記錄的日誌，把資料庫恢復到崩潰前的一個狀態。未完成的事務，可以繼續提交，也可以選擇回滾，這基於恢復的策略而定。
      • undo log
        • 保障了事務的原子性
        • 主要為事務的回滾服務
        • undo log記錄了資料在每個操作前的狀態，如果事務執行過程中需要回滾，就可以根據undo log進行回滾操作
    • redo log和undo log的過程分析
      • eg : 假設有2個數值，分別為A和B，值為1，2
        1 start transaction;
        2 記錄 A=1 到undo log;
        3 update A = 3；
        4 記錄 A=3 到redo log；
        5 記錄 B=2 到undo log；
        6 update B = 4；
        7 記錄B = 4 到redo log；
        8 將redo log重新整理到磁碟
        9 commit
      • 在1-8的任意一步系統宕機，事務未提交，該事務就不會對磁碟上的資料做任何影響.
      • 如果在8-9之間宕機，恢復之後可以選擇回滾，也可以選擇繼續完成事務提交，因為此時redo log已經持久化
      • 若在9之後系統宕機，記憶體對映中變更的資料還來不及刷回磁碟，那麼系統恢復之後，可以根據redo log把資料刷回磁碟
  • 智力題
    兩個同體積的糖罐和鹽罐，裡面分別裝滿了糖和鹽。現在拿一個勺子從糖罐挖走一勺糖放到鹽罐裡，再從鹽罐裡挖走同樣大小的一勺糖罐裡面的東西（可以糖鹽混合，不定）。問最終糖罐的鹽質量百分比和鹽罐的糖質量百分比誰大誰小？
    answer：一樣。
• 二面
  • 層序遍歷變種，每層從右到左列印，空節點列印特殊字元
  • 悲觀鎖、樂觀鎖
    • 樂觀鎖
      • 樂觀鎖是指操作資料庫時(更新操作)，想法很樂觀，認為這次的操作不會導致衝突，在操作資料時，並不進行任何其他的特殊處理（也就是不加鎖），而在進行更新後，再去判斷是否有衝突了.
      • innodb對樂觀鎖的實現是MVCC機制
      • 用於併發控制
    • 悲觀鎖
      • 在操作資料時，認為此操作會出現資料衝突，所以在進行每次操作時都要通過獲取鎖才能進行對相同資料的操作，這點跟java中的synchronized很相似.
      • 悲觀鎖需要耗費較多的時間
      • 兩種實現
        • 排他鎖（寫鎖）
          • 對於多個不同的事務，對同一個資源只能有一把鎖
          • update、insert、delete語句會自動加排它鎖
        • 共享鎖（讀鎖）
          指的就是對於多個不同的事務，對同一個資源共享同一個鎖
    • 行鎖
    • 表鎖
  • session和cookie的區別，如果瀏覽器禁用了cookie，怎麼解決
    https://blog.csdn.net/caoxiaohong1005/article/details/79633849
  • JVM都瞭解什麼內容
  • 併發和並行的區別
  • get post 的區別
    • get
      • 請注意，查詢字串（名稱/值對）是在 GET 請求的 URL 中傳送的
      • GET 請求可被快取
      • GET 請求保留在瀏覽器歷史記錄中
      • GET 請求可被收藏為書籤
      • GET 請求不應在處理敏感資料時使用
      • GET 請求有長度限制 ,大多數瀏覽器通常都會限制url長度在2K個位元組
      • GET 請求只應當用於取回資料
      • 只接受ASCII字元的引數的資料型別
      • get效率高
    • post
      • 查詢字串（名稱/值對）是在 POST 請求的 HTTP 訊息主體中傳送的
      • POST 請求不會被快取
      • POST 請求不會保留在瀏覽器歷史記錄中
      • POST 不能被收藏為書籤
      • POST 請求對資料長度沒有要求
      • POST支援多種編碼方式
    • 為什麼get比post效率高
      • **[最重要原因]**post在真正接受資料之前會先將請求頭髮送給伺服器進行確認，然後才真正傳送資料
        • post 請求過程
          1.瀏覽器請求tcp連線（第一次握手）
          2.伺服器答應進行tcp連線（第二次握手）
          3.瀏覽器確認，併發送post請求頭（第三次握手，這個報文比較小，所以http會在此時進行第一次資料傳送）
          4.伺服器返回100 continue響應
          5.瀏覽器開始傳送資料
          6.伺服器返回200 ok響應
        • get 請求過程
          1.瀏覽器請求tcp連線（第一次握手）
          2.伺服器答應進行tcp連線（第二次握手）
          3.瀏覽器確認，併發送get請求頭和資料（第三次握手，這個報文比較小，所以http會在此時進行第一次資料傳送）
          4.伺服器返回200 ok響應
      • get會將資料快取起來，而post不會。
        ps：chrome下和firefox下如果檢測到get請求的是靜態資源，則會快取，如果是資料，則不快取，但是IE這個傻X啥都會快取起來
      • post請求包含更多的請求頭
      • post不能進行管道化傳輸
  • 智力題
    5L桶和3L桶，如何量出4L的水？
    寫成程式怎麼寫？