有状态 VS 无状态

应用（或其他任何事物）的状态是指它在特定时间的状况或品质，即它的存在状态。要判断一个应用为有状态或无状态，取决于交互状态的记录时长以及该信息所需的存储方式。 

无状态进程或应用可以理解为孤立的。关于它的既往事务，我们一无所知，没有任何参考。每项事务处理似乎都是从头开始。无状态应用只提供一项服务或功能，并使用内容交付网络（CDN）、Web 或打印服务器来处理这些短期请求。 

无状态事务的典型示例是执行在线搜索，寻找您想要的答案。您在搜索引擎中输入问题，然后按 Enter。如果您的事务被意外中断或关闭，则只需重新开始即可。我们不妨将无状态事务看作一台自动售货机：一个请求对应一个响应。 

另一方面，有状态应用和流程则是可以周而复始、反复发生的应用和流程，例如网上银行或电子邮件。这些操作是在先前的事务背景下执行的，当前事务可能会受到先前事务的影响。正因如此，有状态应用在每次处理用户的请求时都会使用相同的服务器。  

如果有状态事务被中断，其上下文和历史记录会被存储下来，这样就可以或多或少地从上次中断的地方继续。有状态应用会跟踪诸如窗口位置、设置首选项和近期活动等内容。我们可以把有状态事务视为与同一个人进行的定期对话。

我们日常使用的大多数应用都是有状态的，但随着技术的进步，微服务和容器使得在云端构建和部署应用变得更加容易。 

随着云计算和微服务的普及，无论是有状态还是无状态应用，其容器化程度都在不断提高。容器是一组打包在一起的应用代码以及它们的库和依赖项，这样一来，它们就可以轻松移动并能在任何环境中运行——无论是在台式机、传统 IT 基础架构上，还是在云端 。 

最初，容器被构建为无状态，因为这比较符合其便携、灵活的特性。但随着容器的广泛使用，人们开始对现有的有状态应用进行容器化处理（重新设计和重新封装，以实现从容器运行）。这在为他们赋予容器的灵活性和速度的同时，也提供了有状态应用的存储和上下文。

正是由于这个原因，有状态应用越来越像无状态应用，反之亦然。例如，您可能有一个无状态应用，它不需要长期存储，但允许服务器使用 Cookie 来跟踪同一客户端的请求。 

随着容器的普及，公司开始提供一些使用数据存储、Kubernetes 和 StatefulSets 来管理无状态和有状态容器的方法。有状态现在已成为容器存储的主体，而现在的问题从要不要使用有状态容器，变成了该何时使用。 

究竟是使用有状态还是无状态容器，要取决于您要构建哪种类型的应用以及您的用途。如果您只是临时需要信息（快速而短暂），无状态便是解决之道。但如果您的应用需要更多内存来存储从一个会话到下一个会话的操作，则应该采用有状态方式。

无论是有状态还是无状态，红帽都可以满足您的要求。无论是在我们的企业级 Kubernetes 平台（红帽 OpenShift）上编排有状态容器，还是通过红帽集成为应用开发打造统一的环境，您都可以享受到我们一流的支持服务，以及业界最大规模的合作伙伴生态系统的保障。 

了解我们的所有产品如何构建解决方案、提高开发人员生产力并促进创新——认识我们的开源之道。