有关容器的六大误区和八大正确场景

这个观点当然不正确，应用的高可用性和重启的速度没有直接关系。高可用性一定要通过多个副本来实现，在任何一个挂掉之后，不能通过这一个应用快速重启来解决，而是应该靠挂掉的期间，其他的副本马上把任务接过来进行解决。虚拟机和容器都可以有多副本，在有多个副本的情况下，重启是一秒还是20秒，就没那么重要了，重要的是挂掉的这段时间内，程序做了什么，如果程序做的是无关紧要的操作，那么挂了20秒，也没啥关系，如果程序正在进行一个交易和支付，那挂掉一秒也不行，也必须能够修复回来。所以应用的高可用性要靠应用层的重试，幂等去解决，而不应该靠基础设施层重启的快不快来解决。

对于无状态服务，在做好重试的机制的情况下，通过自动重启修复是没有问题的，因为无状态的服务不会保存非常重要的操作。

对于有状态服务，容器的重启不但不是推荐的，而且可能是灾难的开始。一个服务有状态，例如数据库，在高并发场景下，一旦挂了，哪怕只有一秒，我们必须要弄清楚这一秒都发生了什么，哪些数据保存了，哪些数据丢了，而不能盲目的重启，否则会很可能造成数据的不一致性，后期修都没法修。例如高频交易下的数据库挂了，按说DBA应该严格审核丢了哪些数据，而不是在DBA不知情的情况下，盲目的重启了，DBA还觉得没什么事情发生，最终很久才能发现问题。

所以容器比较适合部署无状态服务的，随便重启都可以。

而容器部署有状态容器不是不能，而是要非常小心，甚至都是不推荐的。虽然很多的容器平台都支持有状态容器，然而平台往往解决不了数据问题，除非你对容器里面的应用非常非常非常熟悉，当容器挂了，你能够准确的知道丢了哪些，哪些要紧，哪些不要紧，而且要写代码处理这些情况，然后才能支持重启。网易这面的数据库主备同步的情况下，是通过修改mysql源代码，保证主备之间数据完全同步，才敢在主挂了的情况下，备自动切换主。

（编辑：网站开发网_安阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!