重庆手机网站方案设计,浙江企业黄页大全,经典重庆论坛新闻论坛,如何用手机建网站微信搜一搜架构师修行之路session 说到 session#xff0c;我相信每个程序员都不陌生#xff0c;或多或少在项目中使用过。session 这个词#xff0c;其实是一个抽象的概念#xff0c;它不像 Cookie 那样有着明确的定义。当大多数程序员谈论 session 的时候#xff0c;可能… 微信搜一搜架构师修行之路session 说到 session我相信每个程序员都不陌生或多或少在项目中使用过。session 这个词其实是一个抽象的概念它不像 Cookie 那样有着明确的定义。当大多数程序员谈论 session 的时候可能指的是服务端存储数据的 session 对象例如用户登录成功之后把用户信息存储在 session 中类似于这样的程序 Session[UserName] new User();public class User{public int UserId {get ;set ;}public string UserName {get ;set;}}
而在计算机中尤其是网络应用中session 被定义为“会话”可以把它看做客户端和服务端的一条通道连接同一个用户的请求使用同一个 session 会话。在大多数应用中主要用于用户的识别通俗来讲服务端可以通过 session 来记录每一个用户的状态信息。那我们就以最常用的服务端 session 对象来啰嗦几句单机 session session 是存储在服务端的这是一个很重要的概念。这意味着它需要占用服务器的内存并且它需要一种释放的机制来保证服务器内存不会被撑爆例如 LRU。在项目初期为了快速上线服务器的部署很多情况下只有一台服务器记录用户的登录状态普遍使用 session 机制。请不要说这样做不合理至少在项目初期这种做法是最简单而且最快速的方案。随着项目的不断迭代升级用户量的不断增加你会发现单机系统成为了项目的最大性能瓶颈这个时候多数架构师会选择水平扩展方案。其实说到底系统性能的提升都围绕着一个“分”字无论是数据库的分库分表还是现在兴起的微服务始终在围绕着一个领域进行切分当单机的 session 机制进行水平扩展就面临着必须要要解决的问题session 的亲和性粘性要怎么样去解决分布式 session 一个单机系统扩展为一个分布式系统就会面临着分布式 CAP 理论中 AP 和 CP 的选择具体可以查看之前的文章晦涩难懂的 CAP是否完全正确谈到分布式 session 的一致性问题其实主要是要解决用户 session 的亲和性同一个用户的请求怎么样才能保证到达正确存储 session 信息的服务器呢session 复制最初的方案是采用 session 复制方案整体的流程非常简单假设现在有三台服务器当一个 session 在其中一台服务器上被创建则同时把这个 session 复制到其他两台服务器上。这样当用户的请求无论到达哪台服务器都会有相应的 session 数据。这种方案的优势在于服务器可以任意水平扩展每个服务器都保留着所有的 session 信息当加入一台服务器只需要把所有的 session 信息复制过去即可。但是劣势更加明显每个服务器上都保存着全部的 session 信息服务器占用的资源大大增加。session 同步需要占用网络带宽最重要的是如果采用的异步复制方式数据会有短暂性的不一致可能会导致用户访问失败。session 复制的方案现在已经很少有人使用了负载均衡方案当一台服务器扩展为多台服务器目前最常用的方案是在流量的入口添加负载均衡器大体的部署图是这样的image如果负载均衡器能够利用某种手段来实现 session 的粘性就能实现分布式 session。目前主流的 nginx 可以根据“hash_ip”算法将同一个 IP 的请求固定到某台服务器这样来自于同一个 ip 的 session 请求总是请求到同样的服务器。这种方式比 session 同步方式要好很多每台服务器只存储对应的 session 数据这大大节省了内存资源而且服务器之间没有数据同步过程。当有新服务器加入的时候只需要修改负载均衡器的配置即可这样很方便就支持了服务器水平扩展。但是同时也面临着一些不足服务器重启意味着对应的 session 信息丢失这在一些重要的业务场景中是不允许的服务器的水平扩展需要修改负载均衡器的配置修改之后可能会导致之前的 session 重新分布这样会导致一部分用户路由不到正确的 sessionsession 剥离现在应用更广泛的分布式 session 技术是把 session 数据彻底从业务服务器中剥离单独存储在其他外部设备中而这些外部设备可以采用主备或者主从甚至集群的模式来达到高可用。比如现在最常用的方案是把 session 数据存储在 redis 中虽然从 redis 读写 session 数据需要花费一定的网络耗时但是对于一般的应用来说在可以接受范围之内。这种方案好处是整体架构更加清晰也更加灵活应用的服务器整体扩展能力再也不用考虑 session 的影响而 session 的问题被转移到外部设备通常可以利用内存性 NOSql 来解决性能问题而这些外部设备一般都会有对应的分布式集群方案例如 redis可以利用主从或者哨兵模式甚至集群来提供更大规模的数据支撑能力。imageActor 模型很少有人会提及 Actor 模型我在之前的文章中介绍过 actor 模型大家可以去看一下分布式高并发下 Actor 模型如此优秀Actor 模型解决这种用户粘性问题会更加优雅它天生就自带了对象识别功能简单来说同一个 key 的请求总能到达正确的 actor 实例这不是我们想要的结果吗而且 actor 模型下不用加锁就能处理并发问题为什么没人用呢而且采用 acotr 模型就可以利用进程内缓存的形式比请求局域网 redis 的网络延迟要低很多。写在最后 当然如果只是针对用户登录这个应用场景session 方案并不是唯一的解决方案可以参考菜菜之前的文章程序员过关斩将--更加优雅的 Token 认证方式 JWTEND●程序员修神之路--为什么我会了SOA你们还要逼我学微服务●程序员过关斩将--数据库的乐观锁和悲观锁并非真实的锁●程序员修神之路--设计一套RPC框架并非易事●程序员过关斩将--要想获取我的用户信息就得按照规矩来●程序员过关斩将--更加优雅的Token认证方式JWT●程序员过关斩将--cookie和session的关系其实很简单●程序员修神之路--用NOSql给高并发系统加速●程序员修神之路--高并发系统设计负载均衡架构●程序员过关斩将--你为什么还在用存储过程●程序员修神之路--问世间异步为何物●程序员修神之路--提高网站的吞吐长按添加菜菜好友关注后回复“大礼包”和“福利”领取惊喜
