无状态服务(stateless service)

简介: 一、定义 无状态服务(stateless service)对单次请求的处理,不依赖其他请求,也就是说,处理一次请求所需的全部信息,要么都包含在这个请求里,要么可以从外部获取到(比如说数据库),服务器本身不存储任何信息 有状态服务(stateful service)则相反,它会在自身保存一些数据,先后的请求是有关联的 二、优劣 有状态服务常常用于实现事务(并不是唯一办法,下文有另外的方案)。举一

一、定义

无状态服务(stateless service)对单次请求的处理,不依赖其他请求,也就是说,处理一次请求所需的全部信息,要么都包含在这个请求里,要么可以从外部获取到(比如说数据库),服务器本身不存储任何信息

有状态服务(stateful service)则相反,它会在自身保存一些数据,先后的请求是有关联的

二、优劣

有状态服务常常用于实现事务(并不是唯一办法,下文有另外的方案)。举一个常见的例子,在商城里购买一件商品。需要经过放入购物车、确认订单、付款等多个步骤。由于HTTP协议本身是无状态的,所以为了实现有状态服务,就需要通过一些额外的方案。比如最常见的session,将用户挑选的商品(购物车),保存到session中,当付款的时候,再从购物车里取出商品信息

有状态服务可以很容易地实现事务,所以也是有价值的。但是经常听到一种说法,即server要设计为无状态的,这主要是从可伸缩性来考虑的。如果server是无状态的,那么对于客户端来说,就可以将请求发送到任意一台server上,然后就可以通过负载均衡等手段,实现水平扩展。如果server是有状态的,那么就无法很容易地实现了,因为客户端需要始终把请求发到同一台server才行,所谓“session迁移”等方案,也就是为了解决这个问题

6486d16d-38c6-38de-837f-637ff99c30d4.png

三、session和cookie

基于session和cookie都可以实现事务,可以认为,session是有状态的,而cookie是无状态的

四、无状态实现事务的方法

并不是一定要用有状态服务才能实现事务,本文提供另外的几种方案作为参考
举一个多次提交的场景作为例子:用户需要提交很多数据,分为2个页面提交

d2a571e3-dea4-3fad-bf5b-e896730ebf10.png

这里就涉及到2次http请求,第一次提交字段1、2、3,第二次提交字段4、5、6

用session很容易实现这个需求,server只需要将第一次提交的数据,保存在session里,然后返回第2个表单作为相应;然后取出第一次提交的数据,和第二次提交的数据汇聚以后,一起存入数据库即可

不用session同样也可以实现,server接收到第一次请求以后,将数据作为隐藏元素,放在第2个表单里返回;这样用户第2次提交的时候,就隐含地再次提交了第一次的数据;server将所有数据存入数据库
用HTML5,则还可以进一步优化,client可以将第一次提交的数据,保存在sessionStorage里
用cookie也是类似的道理,同样可以实现,但是不太好

总的来说,3种替代方案(隐藏表单元素、sessionStorage、cookie)都避免了在server端暂存数据,从而实现了stateless service。本质上,这3种方案的请求里,都包含了所有必须的数据,符合本文一开始的定义

五、将有状态服务转换成无状态服务

根据本文一开始的定义,除了将所有信息都放在请求里之外,还有另外一种方法可以实现无状态服务,即将信息放在一个单独可共享的地方,独立于server存在
比如,同样还是采取session的方式,在服务端保存数据,减少每次client请求传输的数据量(节省流量);但是将session集中存放,比如放在单独的session层里。这种情况下,server同样是无状态的,可以做水平扩展

47bd72bf-1162-33d2-be07-0ddcebdc633a.png

六、无状态类

引申一下,JAVA里有一种类的设计,可以称为无状态类。这种类的特征是只有方法没有字段,在三层架构(展现层、逻辑层、持久层)里,逻辑层经常可以看到这种类
我觉得无状态类和stateless server在思想上是一样的,这个类本身是没有状态的,所以当外部要调用它的方法时,需要在方法参数中传来所需的所有信息,不依赖该类自身的状态(字段值),在并发环境下,可以避免多线程带来的副作用

七、总结

有状态服务可以比较容易地实现事务,在不需要考虑水平扩展时,是比较好的选择
无状态服务的优势在于可以很方便地水平伸缩,但是在实现事务时,需要做一些额外的动作
可以通过剥离session等方法,将一个有状态服务,转换成无状态服务

原文链接;

http://kyfxbl.iteye.com/blog/1831869

目录
相关文章
|
SQL 缓存 NoSQL
接口的幂等性设计和防重保证,详细分析幂等性的几种实现方法
本篇文章详细说明了幂等性,解释了什么是幂等性,幂等性的使用场景,讨论了幂等和防重的概念。分析了幂等性的情况以及如何设计幂等性服务。阐述了幂等性实现防重的几种策略,包括乐关锁,防重表,分布式锁,token令牌以及支付缓冲区。
8832 0
接口的幂等性设计和防重保证,详细分析幂等性的几种实现方法
|
Web App开发 索引
正则表达式匹配域名、网址、url
DNS规定,域名中的标号都由英文字母和数字组成,每一个标号不超过63个字符,也不区分大小写字母。标号中除连字符(-)外不能使用其他的标点符号。级别最低的域名写在最左边,而级别最高的域名写在最右边。由多个标号组成的完整域名总共不超过255个字符。
31339 0
|
存储 分布式计算 Kubernetes
大型分布式存储方案MinIO介绍,看完你就懂了!
MinIO 是一个基于Apache License v2.0开源协议的对象存储服务。它兼容亚马逊S3云存储服务接口,非常适合于存储大容量非结构化的数据,例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等,而一个对象文件可以是任意大小,从几kb到最大5T不等。
|
消息中间件 Java 中间件
秒懂消息队列MQ,万字总结带你全面了解消息队列MQ
消息队列是大型分布式系统不可缺少的中间件,也是高并发系统的基石中间件,所以掌握好消息队列MQ就变得极其重要。接下来我就将从零开始介绍什么是消息队列?消息队列的应用场景?如何进行选型?如何在Spring Boot项目中整合集成消息队列。
25412 10
秒懂消息队列MQ,万字总结带你全面了解消息队列MQ
|
Web App开发 应用服务中间件 nginx
|
8月前
|
人工智能 JSON 自然语言处理
我终于成为了全栈开发,各种AI工具加持的全过程记录
本文从一个需求出发,全程记录如何进行全栈开发。
1550 51
我终于成为了全栈开发,各种AI工具加持的全过程记录
|
程序员 数据库 微服务
长事务管理不再难:Saga模式全面解析
本文介绍了分布式事务中的Saga模式,它用于解决微服务架构下的事务管理问题。Saga通过一系列本地事务和补偿操作确保最终一致性,分为编排和协同两种模式。文章重点讲解了编排模式,其中 Saga 协调者负责事务的执行和失败后的补偿。Saga 模式适用于业务流程明确且需要严格补偿的场景,能有效管理长事务,但实现上可能增加复杂性,并存在一致性延迟。文章还讨论了其优缺点和适用场景,强调了在面对分布式事务挑战时,Saga 模式的价值和潜力。
2577 6
|
人工智能 自然语言处理 API
阿里云百炼平台上线首个最新文生图模型FLUX中文优化版
由Stable Diffusion团队推出的开源文生图模型FLUX风靡全球,其生成质量媲美Midjourney,被誉为“开源王者”。阿里云百炼平台首发FLUX中文优化版,提升了中文指令的理解与执行能力。开发者可直接在平台上体验并调用FLUX模型,且享有1000张图像的免费生成额度,有效期180天。无需额外部署,即可轻松利用这一先进模型创造高质量图像。
2208 0
|
机器学习/深度学习 人工智能 并行计算
【AI系统】Tensor Core 基本原理
本文深入介绍了英伟达GPU中的Tensor Core,一种专为加速深度学习设计的硬件单元。文章从发展历程、卷积计算、混合精度训练及基本原理等方面,详细解析了Tensor Core的工作机制及其在深度学习中的应用,旨在帮助读者全面理解Tensor Core技术。通过具体代码示例,展示了如何在CUDA编程中利用Tensor Core实现高效的矩阵运算,从而加速模型训练和推理过程。
2058 0
|
Cloud Native JavaScript API
一文读懂云原生 go-zero 微服务框架
一文读懂云原生 go-zero 微服务框架
1043 1