高并发架构设计原则-无状态

无状态：

服务端不保存任何客户端请求者信息，客户端的每次请求必须具备自述信息，通过这些信息识别客户端身份。

优点-客户端请求不依赖服务端的信息，任何多次请求不需要必须访问到同一台服务，这样为服务器横向扩展提供了条件。

有状态：

服务端需要记录每次绘画的客户端信息，从而识别客户端身份，根据客户端身份进行对请求的处理，如session。

缺点

-服务端保存大量客户端信息，增加服务端压力。

-服务端保存用户状态，无法进行水平拓展。

-客户端请求依赖服务端，多次请求必须访问同一台服务器。

有状态无状态判断依据：

来自相同客户端发起的请求在服务端是否具备上下文关系。服务端保存状态化请求的相关信息，每个请求可以默认地使用以前的请求信息。服务端处理无状态请求时，信息必须圈闭来自于请求所携带的信息以及其他服务端自身保存的并且可以被所有请求所使用的公共信息。

状态是什么？

服务调用过程中有两种“状态”：应用状态和资源状态。应用状态是某一特定请求的相关信息。资源状态则反应了某一存储在服务端资源在某一时刻的特定状态，该状态不会因客户请求而改变，任何用户在同一时刻对该资源的请求都会获得这一状态的表现。

为什么要使用无状态架构：

存储状态限制了分布式系统，如负载均衡时，一个用户的请求必须被提交到保存有其相关状态信息的服务器上，否则这些请求可能无法被理解，这也意味着再次模式下服务器无法对客户的请求自由调度，另一个问题就是容错性，保存用户信息的服务器宕机，那么该用户最近的所有交互操作将无法被透明底移送到备用服务器上，除非改服务器时刻与主服务器同步全部用户状态信息。此外由于HTTP本身不是一个有状态的协议，开发者必须通过模拟实现状态的钝化与激活等。无状态架构风格有效的克服了这些不足。

无状态大大提高了服务集群的可伸缩性、在横向扩展或集群部署时不用状态重建，无状态是针对服务端来说的。

总结：

状态化的服务在功能实现方面有更大的优势，但由于需要维护大量信息和状态，在性能方面要逊于无状态服务器。无状态在处理简单服务方面有优势，但复杂功能方面有很多弊端。如用无状态服务实现实时通讯？有句话总结的比较贴切：无状态不是消灭了有状态架构的问题，而是将有状态架构的问题延后了。