很多遊戲維護時需要服務器停機，而有一些不需要。或者某一款遊戲有時候服務器停機維護，有時候不停機維護，是因為什麽？ 是不是不停機維護需要更高的技術呢？

遊戲的定期更新版本已經再尋常不過了，但頻繁的更新會造成流失率非常嚴重，哪個玩家也不希望再BOSS將要躺下那一刻，服務器停機維護了。在小版本更新過程中，采用不停機維護成為現在遊戲的主流方式，那究竟是如何做到不停機維護的呢?

網絡遊戲如果數據放在服務器的話，要分很多種情況來看。我就大概就我的所致簡單說一下吧。遊戲服務器分邏輯程序服務器和數據庫服務器，如果是線上運營的服務器，基本上是在兩臺主機上（至少是兩臺虛擬主機上），當然也有多臺邏輯主機+多臺分布式數據庫的情況，我先不討論多對多的。有時候，發現幾個邏輯服務器bug，或者加了某些功能，比如少加了三個金幣，多算了一點經驗啊，只需要在測試服測試完畢，上傳覆蓋執行文件（jar或php），重啟邏輯服務器進程，客戶端基本感覺不到，http是短鏈接，即便是長鏈接，只要客戶端有自動重連策略，也沒啥問題。對外叫做不停機維護，可以公告告訴玩家，也可以不公告。
而Erlang的熱升級技術，就帶了更好的體驗。Erlang原本脫胎於電信行業，Jow Armstrong 在描述Erlang的設計要求時期中就提到了“軟件維護應該能在不停止系統的情況下進行。”在實踐中，我們也因為這種不停服務的熱更新獲益良多，終於不用再等到半夜沒人的時候再做更新了，對於一些緊急的bug修復，熱更新實在是一把利器。Erlang熱更新的秘密其實都集中在code模塊,code模塊是Erlang Code Server暴露出來的對外接口其職責就是把已經編譯好的模塊加載到Erlang的運行時環境。代碼版本有兩個概念 當前版本代碼‘current‘和老版本代碼‘old‘,一旦模塊被加載就變成‘current‘,再有一個版本過來被加載,之前的版本就變成‘old‘,新加載的變成‘current‘。這時候,兩個版本還是同時存在,新的請求執行的時候會使用新的版本,而老版本的代碼還會被使用因為還有其他模塊的調用‘old‘版本中。如果再進行一次熱更新,這時就有第三個實例被加載,code server就會終止掉還在駐留在‘old‘版本代碼依賴的進程。然後第三個實例成為‘current‘,之前版本的‘current‘被標記成‘old‘。這種方法有效降低了因版本升級而導致的用戶流失。

還有一種服務器維護，是物理（虛擬）主機linux（windows）系統維護，包括升級（降級）配置，移動機房，機房故障等等，需要新搞一臺主機，將運行環境搭建起來，如果有緩存數據，需要把緩存數據拷貝過去，如果沒有跳板（網關），這需要更改DNS，等待生效（1-24小時）這個時候的時間差，客戶絕對連接不上的。

再有就是在數據庫的搭建的時候，建表的時候，沒有考慮到兼容的情況，在做版本叠代的時候，新的功能需要的表結構需要重新升級或者建立新的索引，於是需要把數據庫進程停止，導入數據到新的結構裏面去，這段時間邏輯服務器服務器是停擺的，客戶端也肯定不然連的。

最後還有很多遊戲服務器群構架，包括緩存服務器，聊天服務器等等，他們也會出現各種各樣的問題，也可能會停機維護或者不停機維護，原理差不多，我就不一一舉例子了。

天下數據專業提供海外遊戲解決方案,我們會根據您的需求情況,為您量身定做一套獨一無二的海外服務器平臺解決方案!

遊戲怎麽做到服務器不停機維護？