腾讯游戏后台一般还是C/C++的比较多，不知道最近的技术栈是不是有变化。一般游戏过审的时候，有比较重要的指标就是不停服热更新的技术，美其名曰提高用户体验。不停服更新的基本思想就是保持服务器玩家的状态不丢失，这里的状态，包括玩家的存盘数据，自己一些游戏过程产生的临时的不需要存盘的数据。
如果有些服务是无状态的，服务器内存不保存数据，只是有消息来了就处理，那随便重启，顶多多整几个平行服务，分批重启。
难的是有状态的。一种做法就是既然状态保存在内存重启丢失，那就用特殊的内存来保存，共享内存。linux的共享内存机制可以让进程重新启动后，数据仍然能恢复。C的struct恢复容易点，C++涉及到继承的相对麻烦，直接恢复，虚表会被破坏，但是有placement new还是可以处理的。
还有种方法就是状态数据放redis这类缓存服务里，但是所有逻辑操作都和redis打交道，也是十分不爽。
再有就是另一种思路了，业内用的也比较多，就是分批更新，其他答案也说的很清楚。具体到王者农药，肯定是分布式来搞，可能就是匹配服和战斗服分版本，新老版本区隔开。第一场战斗在老服，第二场战斗可能就被分到新服了，老服只出不进，等所有人都不在了，更新即可，更新完了再调整权重开放进人。
还有其他so小众做法，比如替换逻辑so，数据so不变的也能做。或者逻辑用脚本比如python或者lua来做的，也有方案让状态保持的。
最后，其实很多大公司如网易应该都不搞这些的，简单粗暴重启更新，我喜欢…
不知道王者荣耀这个特例怎么实现的，但是有其他的服务器是这样实现的：
服务器上运行的大部分是消息触发的“无状态”设计。怎么说呢，就是你即使在玩游戏，发消息也是好半天发一条，并不是每秒发好多消息。在你没有发消息的时候，服务器上没有任何代码为你运行。你的消息到了服务器，服务器拉起你的相关数据，处理一下，然后退出。
那么这种框架下收发消息的部分，只要做好了负荷分担，其他部分想怎么升级就怎么升级。因为收到消息由谁处理，是临时决定的。升级的那部分资源不分任务就是了。收发消息部分怎么升级呢？收发消息部分本身就是无状态的，他的任务可以随意迁移。
如果遇到有状态的怎么办呢？可以通过内存转移的方式去做，把未升级部分的用户的相关内存数据转移到某些特意留着的老版本服务器上去继续干活，空出来的服务器就可以升级。热迁移也不是多复杂的问题。
至于用户数据升级，完全是后台的事情，格式转换就可以了。当然只能对不活跃用户进行数据格式转换，活跃用户的数据不能转换。等他下线转换就行啦
大概就像我更新vsphere exsi主机一样吧。
我先把主机1的虚拟机平均迁移到2，3，4上。然后主机1进入维护模式进行更新，更新完毕后把虚拟机迁回主机1。其余主机同理，于是我的业务根本没有中断，我就把所有主机更新了。
感觉不是采用常规热修复的技术，而是采用一种类似react native的技术。
游戏实测体验。
游戏过程中提示更新完成。
游戏结束 继续游戏提示本地版本太低需要更新。
引用其他人的回答 就是分布式服务
登录服务器 和若干游戏服务器
假设开始更新，先从没有玩家的服务器开始更新。
从过程中 思考进入游戏不都是某个服务器控制的连接几号服务器
大致就是这样了
...就是你玩的时候不更，你不玩了就更。区别于rpg类游戏，因为那种游戏你一直在线。
不知道王者有没有掉线重连 先掉线，再更新然后游戏结束了
感觉和码分复用差不多。。
波动更新网关路由
@王朝同