只是无响应 (我猜是tcp连接中断) 比较简单，nginx切换配置时可以graceful restart的，这样可以撤掉一台后端--升级后端--加回去。

但是"不影响访问" 不止要解决这个，你还需要让旧版本的前端和新版本的服务器可以共用。

脏数据是另一个问题了。不应该期待每个请求都正常结束，清理脏数据 (现场或事后) 的机制总归是应该有的。

当你的服务器支持平滑重启，这就比较方便了。平滑重启可能是你自己实现的，也可能是框架或者库提供的。

你这么想本来就是错的，除非你5台机器上部署的是不同的项目，那么升级只能停机，不然还能怎么办你说。你这个意思是5台机器上部署同一个项目，那么升级的时候你考虑怎么能不影响服务，你的出发点应该在这儿，那这里就有一个问题，对于一个请求你是怎么做分发到5台机器上的，你怎么做的然后就在哪里调整就是了，在低谷的时候把5台改成4台，然后升级成功之后再加回去，如果担心升级过程中响应不过来，那么就调整缓存时间，都5台机器了，不会没缓存把。。。

升级一般都是凌晨升级，因为如果出了什么问题，都不会影响那么大

负责均衡下掉一台服务器，升级，然后再up

完全不影响是不可能，只有尽可能的让影响看不出来，你观察一下京东就会发现，它家的服务器经常凌晨升级，升级的时候你打开它的菜单是刷不出东西来的，就看不停的转圈，但是就是不出内容。所以基本都是升级的时候把服务器切换到友好的不出内容界面，升级完再换回来。

逐台升级，升级过程中把流量引导其他服务器

我们项目是用pm2发布和做进程管理的

发布的时候不会影响用户是用

1. 热部署

2. 灰度发布