当我运行Django应用程序时，我有一台服务器，但我有一点问题：
当我使用mercurial提交并在服务器上推送新的更改时，有一个微时间（如1微秒）主页无法访问。
我在服务器上有apache。
我该如何解决这个问题？
答案 0 :(得分：4)
你可以运行django应用程序的多个实例（在具有不同端口的同一台机器上或在不同的机器上）并使用apache来反转对每个实例的代理请求。它可以故障转移到实例B，而实例A正在重启。请参阅mod_proxy。
如果停机时间与您说的一样短，那么值得担心的问题就不足为奇了。
答案 1 :(得分：1)
如果您有任何以微秒为单位的重要流量，最好一次一个地将新更改推送到您的Web服务器，并在您进行升级时将机器从负载均衡器轮换中移除
答案 2 :(得分：0)
使用apachectl graceful时，可以最大程度地缩短“重启”Apache时网站不可用的时间。当他们没有做任何事情时，所有的孩子都被“请”重新启动并获得他们的新配置。
USR1或优雅信号导致父进程建议孩子在他们当前请求后退出（或者如果他们没有提供任何东西则立即退出）。父级重新读取其配置文件并重新打开其日志文件。当每个孩子去世时，父母将其替换为新一代配置中的孩子，该孩子立即开始提供新请求。
在人流量大的网站上，您会发现一些性能损失，因为有些孩子会暂时不接受新的连接。然而，根据我的经验，TCP完全可以从中恢复。
考虑到某些网站需要几分钟或几小时才能更新，这是完全可以接受的。如果这是一个非常大的问题，您可以使用代理，运行多个实例并一次更新一个实例，或者在非高峰时刻更新。
答案 3 :(得分：0)
如果你正在抱怨第1次/ 1,000,000次第二次停电，那么我建议采用以下方法：
指向多个后端服务器的前端负载均衡器。
从负载均衡器中删除一个后端服务器，以确保不会有任何流量。
等待服务器正在处理的所有流量都已发送。
关闭该实例上的网络服务器。
更新该计算机上的django实例。
将该实例添加回负载均衡器。
对所有其他服务器重复。
这将确保消除1 / 1,000,000秒的间隙。
答案 4 :(得分：-1)
我认为这是正常的，因为django可能需要在更新后重启服务器