Khi khởi động lại server để cập nhật mà không chuyển kết nối đi nơi khác, những người đang ở server đó bị mất kết nối, đồng thời việc lưu dữ liệu ngay trước khi tắt và việc kết nối lại dồn vào cùng một lúc.
Vì sao Triển khai hotfix, khởi động lại lần lượt từng server → Dẫn đến Tắt server mà không chuyển kết nối sang server khác, dữ liệu cần lưu của mọi người chơi trên server đó dồn vào DB → Trên màn hình Mất kết nối không có thông báo trước, lượng kết nối lại tăng đột biến
Thỉnh thoảng bất chợt, Ngay sau đăng nhập hoặc bảo trì
Phụ trách
Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Hạ tầng server (Đội hạ tầng)
Việc cần làm (Đội phát triển game)
Tính năng drain (chỉ chặn kết nối mới và chờ đến khi người đang chơi thoát ra), chuyển nhân vật sang server khác, chia nhỏ việc lưu trước khi tắt, sau khi khởi động lại thì tải cache và JIT warm-up xong mới báo sẵn sàng, hot reload thì đọc trước ở thread riêng rồi thay một lượt giữa hai tick.
Việc cần làm (Đội hạ tầng)
Công cụ triển khai chờ drain từng máy xong rồi mới khởi động lại, server vừa khởi động lại chỉ nhận lưu lượng sau khi xác nhận đã sẵn sàng (làm nóng xong), thông báo trước giờ triển khai.
Con số tham khảo
Một server có 5.000 người thì trong vài giây trước khi tắt, 5.000 lượt lưu dồn vào DB.
Trên đồ thị
Rớt kết nối hàng loạt · Số kết nối theo server, số lượt ghi DB
Chỗ cần xem
Chồng nhật ký tác vụ của công cụ triển khai (thời điểm khởi động lại từng server) lên đồ thị số kết nối, số lần mất kết nối, ghi DB, yêu cầu đăng nhập dưới dạng vạch dọc (annotation)
Đúng nếu
số kết nối của từng server lần lượt tụt mạnh đúng thời điểm khởi động lại, ngay trước đó lượt ghi DB vọt lên, ngay sau đó yêu cầu đăng nhập vọt lên
Loại trừ nếu
thời điểm mất kết nối không trùng với nhật ký triển khai hay khởi động lại → xem server crash hoặc thiết bị mạng
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm
Vài phút ngay sau khi bật lại server cũng chậm. Cache còn trống nên truy vấn DB dồn dập, còn server Java, C# chưa xong quá trình tối ưu code trong lúc chạy (JIT warm-up) nên cùng một việc lại tốn nhiều thời gian hơn. Cách đọc lại script và bảng dữ liệu mà không tắt server (hot reload) cũng làm tick dừng trong lúc đọc, gây đứng hình chốc lát.
Nguồn
Site Reliability Engineering, Chapter 20: Load Balancing in the DatacenterGoogle Server nhận SIGTERM chuyển sang trạng thái lame duck, đẩy yêu cầu mới sang server khác và chỉ xử lý nốt các yêu cầu đang dở; vài phút ngay sau khi khởi động lại, server chưa được JIT tối ưu nên tốn tài nguyên hơn, vì vậy cho server làm nóng xong rồi mới nhận lưu lượng
Liveness, Readiness, and Startup ProbesKubernetes Dùng readiness probe để không gửi lưu lượng cho tới khi thiết lập kết nối, tải file và làm nóng cache xong