遊戲 Lag 白皮書 › L13 伺服器架構與維運
部署與重新啟動 Deploy / rolling restart
原因 ID in-deploy · 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（伺服器基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
為了更新而重新啟動伺服器時，如果不先把連線移走，原本在那台伺服器上的人就會斷線，關閉前的存檔與重新連線也會同時湧入。
為什麼 部署 hotfix，依序重新啟動伺服器 → 於是 沒有把連線移到其他伺服器就關閉，那台伺服器上所有玩家的存檔同時湧向 DB → 畫面上 沒有公告就斷線、重新連線暴增
- 症狀
- 斷線, 連不上／無限讀取, 輸入延遲
- 因素
- 停滯
- 誰會遇到
- 整個伺服器, 特定地點／頻道
- 何時
- 偶爾隨機發生, 剛登入／維護剛結束
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（伺服器基礎設施）
- 遊戲開發團隊要做的事
- drain 功能（只擋新連線，等現有的人離開），把角色移到其他伺服器，關閉前分批存檔，重新啟動後完成快取載入與 JIT 暖機再回報準備完成，熱重載（hot reload）在另一個執行緒先讀好，再於 tick 之間一次替換。
- 基礎設施團隊要做的事
- 部署工具逐台等 drain 完成後再重新啟動，重新啟動的伺服器確認準備完成（暖機結束）後才接流量，公告部署時間。
- 數值參考
- 一台伺服器有 5,000 人時，關閉前幾秒內會有 5,000 筆存檔湧向 DB。
- 圖表上
- 連線同時大量中斷 · 各伺服器連線數、DB 寫入次數
- 查看位置
- 把部署工具的作業紀錄（各伺服器重新啟動時間）以垂直線（註記）疊在連線數、斷線次數、DB 寫入、登入請求的圖表上看
- 符合的跡象
- 各伺服器的連線數在重新啟動時間點逐台依序驟降，驟降前 DB 寫入往上衝，驟降後登入請求往上衝
- 不符合的跡象
- 斷線時間點與部署、重新啟動紀錄不重疊時，是伺服器當機或網路設備的問題
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
- 深入了解
- 剛重新啟動後的幾分鐘也會比較慢。快取是空的，DB 查詢集中湧入；Java、C# 伺服器在執行中最佳化程式碼的過程（JIT 暖機）尚未結束，同樣的工作要花更多時間。不關伺服器、直接重新讀取腳本與資料表的方式（熱重載）也一樣，讀取期間 tick 會停住，造成短暫定格。
出處
- Site Reliability Engineering, Chapter 20: Load Balancing in the Datacenter Google
收到 SIGTERM 的伺服器進入 lame duck 狀態，把新請求轉給其他伺服器，只完成進行中的請求；剛重新啟動的幾分鐘尚未完成 JIT 最佳化、耗用更多資源，所以暖機後才接流量 - Liveness, Readiness, and Startup Probes Kubernetes
用 readiness 檢查，在建立連線、載入檔案、快取暖機完成之前不送流量 - Edit target group attributes for your Network Load Balancer AWS
取消註冊目標後不再送新連線，現有連線則 drain（預設 300 秒）
相關原因
同一層：L13 伺服器架構與維運
同一症狀（斷線）在其他層的原因
查看含圖解與實驗的完整版卡片