cluster计算机集群-cookie-session- 运维

● - 集群诞生的原因：
在当今的高并发环境中，对计算机性能的要求越来越高，通常提升性能的方式有两种：
scale up 向上扩展：
提升现有主机的硬件性能，例如将单台服务器进行硬件升级；
比如提升CPU或内存的性能，或者淘汰掉旧服务器，淘汰掉旧服务器；

即Scale vertically）纵向扩展，向上扩展。
称为单节点系统，指系统中只包括一个有效节点（如果需要HA时，可以将两个单节点以System Replication形式构成单节点的HA架构）。这种架构的系统只具有垂直扩展能力，当需要扩展系统时，通过在节点上增加更多的CPU、内存和硬盘来扩大系统的能力。
Scale-up通过购买性能更好的硬件提升系统的并发处理能力，
比如：我们向原有的机器增加CPU、内存数。

scale out 向外扩展：
多节点扩展，将复杂任务分散给多个单点主机进行处理；
水平扩展，即计算机集群；

即Scale horizontally，横向扩展，向外扩展。
称为集群系统。指由多个节点组成的系统，这种系统的扩展主要以水平扩展方式（指增加节点的方式）来进行。
Scale-out 通过将多个低性能的机器组成一个分布式集群来共同抵御高并发流量的冲击。
比如向原有的web、邮件系统添加一个新机器。

文章图片

负载均衡集群
简单的集群架构图：
思考一下：当图中两个web服务器提供同样的web服务时，由于被随机分配至A或B上，这时如果之前客户端在A服务器上上传了图片或文章，下次登录时被分配到了B服务器，那么之前上传在A服务器上的图片和文章就不能访问到了，为了避免这类问题，所以在后端使用了文件共享服务器和数据库服务器，这样就保证了A和B服务器都可以读取到同样的数据或图片；

客户端浏览器：众多的客户端向服务器发起请求，访问web服务； server4：将来自不同客户端的请求分散给后端的web服务器进行响应；负载均衡服务器A、B：提供web服务，一般是nginx或apache; 文件共享服务器：一般是NFS共享文件系统，将web服务需要的网页文件存在此主机上；比如图片；（） MySQL数据库服务器：将web服务器需要读取或存入的数据存在此服务器上；比如文章；

数据类型有三种：结构化数据，非结构化数据，半结构化数据；

●Cookie和Session机制：
HTTP协议是无状态的，无状态的意思就是服务器无法判断用户身份，现今有很多网站需要追踪客户端的访问行为并记录，比如电商站点，需要记录客户端浏览了哪些商品，在购物车加入了哪些商品等信息，或者客户访问了哪些网站，这些信息如果未同步提供web集群上，会导致用户数据缺失；

举例：比如客户端首次访问某电商网站被服务器A响应并建立会话连接，客户端加入了自己挑选的商品在购物车中，这时客户端断开连接并停止访问网站了，过了两天，这个用户再次登录，而这次负责建立连接响应的是服务器B，因为B服务器中没有之前用户加入购物车的数据，那么用户就无法查看到自己之前的商品，这种体验感就会大大下降，用户一气之下删除软件也是非常可能的，哈哈~

那么为了避免这种情况的发生，就用到了cookie和session了；
我们看这张图：

文章图片

cookie：
在客户端访问站点时，如果服务器需要记录用户状态，那么服务端会颁发给客户端一个cookie文件,客户端将cookie保存在本地浏览器中，这个文件将用户使用浏览器在站点上的各种行为都记录在cookie文件中，每次客户端访问站点时，都将这个cookie文件发送给服务器端，服务器通过读取cookie文件中的数据来识别用户状态；

文章图片

将用户状态记录在cookie中的机制也叫“胖cookie”机制，这种机制存在一些隐患，比如用户再某站点的cookie被另外一个有竞争关系的站点所截获，那么用户的信息就会有泄露的风险，所以还有一种机制即避免泄露用户信息，也能记录用户状态，就是session机制；
session:
session与cookie效果是相同的，都可以记录用户的状态数据，区别在于session是记录在服务器端的，我把这个记录形式想象成一个表，专门记录session的键、值等信息。
当客户端访问服务端时，服务端会检查客户端的请求中是否包含了一个sessionID,如果有则证明之前给这个客户端创建过，反之没有的话则新建一个session信息在表中，这个session信息是对应关系，有sessionID和这个ID对应的数据信息，sessionID是唯一标识的，不会重复的ID,服务器将sessionID发给客户端，客户端保存起来（有可能是保存在cookie中，这个cookie只保存sessionID而不保存用户状态，可能叫"瘦cookie"），每次客户端发起请求时都将自己的sessionID发给服务器端，服务器端在自己的表或库中检索匹配相应的用户状态数据，这样就可以保持用户的状态信息了；

引用：
让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：
1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，
店员就知道该怎么对待了。这种做法就是协议本身支持状态。
2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，
如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。
3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，
则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。
由于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。
具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。
同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要
借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。

简单了解完cookie与session机制和工作原理，我们回到本文的集群正题中来!!!

文章图片

我们看这张图，在右下角增加了一台session server,它是做什么的呢？
当我们的集群变多时，客户端每次的访问就会轮流到不同的服务器上，比如第一次是有服务器A负责响应的，那么客户端的session数据就保存在了服务器A上，下次客户端访问如果轮流到其他服务器上，那么就不会有之前在A服务器上的session信息，这样就麻烦了,session server就是负责给集群中的服务器共享session数据的，让每一台服务器都可以获取到所有session数据；
其实要实现session共享有三种方式都可以，各自有自己的优点和缺点，简单介绍一下三个方式：
集群下实现Session共享的几种方案
1.Session Sticky
请求精确定位：基于IP地址的Hash策略，将同一用户的请求都集中在一台服务器上，这台服务器上保存了该用户的Session信息。
让负载均衡器能够根据每次的请求的会话标识来进行请求的转发，这样就能保证每次都能落到同一台服务器上面，这种方式称为Session Sticky方式。

文章图片

存在问题：
a. 如果这一台Web服务器宕机或者重启了，服务器上的会话数据会丢失，用户需要重新登陆等。
b. 会话标识是应用层的信息，那么负载均衡器要将同一个会话的请求都保存到同一个Web服务器上的话，就需要进行应用层的解析，这个开销比第四层交换（LVS负载均衡器属于第四层）要大。
c. 负载均衡器变为一个有状态的节点，要将会话保存到具体的Web服务器的映射。和无状态的节点相比，内存消耗会更大，容灾方面会更麻烦。
打个比方，比如Web服务器是饭店，会话数据是碗筷。要保证每次吃饭都用自己的碗筷的话，我就把餐具存在某一家饭店，并且每次都去这家店吃饭。
2.Session Replication
Session复制共享：比如可以用Tomcat自带的插件进行Session同步，使得多台应用服务器之间自动同步Session，保持一致。如果一台发生故障，负载均衡会遍历寻找可用节点，Session也不会丢失。缺点：必须是Tomcat和Tomcat之间，Session的复制也会消耗系统的性能，使得同步给成员时容易造成内网流量瓶颈。
还是以吃饭的例子，如果我们在每个饭店都存放一套自己的碗筷，就可以自己的选择去哪家吃饭了。这就是Session Replication。如下图：

文章图片

此方案不用再要求负载均衡器保证同一个会话的多次请求必须到同一个Web服务器上了。我们在Web服务器之间增加了会话数据的同步，通过同步就保证了不同Web服务器之间Session数据的一致。一般应用容器都支持Session Replication方式，与Session Sticky方案相比，Session Replication方式对负载均衡器没有那么多的要求。
存在问题：
a. 同步Session数据造成了网络带宽的开销。只要Session数据有变化，就需要将数据同步到所有其他机器上，机器越多，同步带来的网络带宽开销就越大。
b. 每台Web服务器都要保存所有Session数据，如果整个集群的Session数据很多（很多人同时访问网站）的话，每台机器用于保存Session数据的内容占用会很严重。
这个方案是靠应用容器来完成Session的复制从而解决Session的问题的，应用本身并不关心这个事情。这个方案不适合集群机器数多的场景。如果只有几台机器，用这个方案是可以的。
3.Session数据集中存储
基于cache DB缓存的Session共享（推荐，Spring-Session也是同样的原理，同自定义的JRedis一起配置可以实现目的）:使用Redis存取Session信息，应用服务器发生故障时，当Session不在内存中时就会去CacheDB中查找（要求Redis支持持久化），找到则复制到本机，实现Session共享和高可用。
将Session数据集中存储，然后不同Web服务器从同样的地方获取Session，如下图：

文章图片

Session数据不保存到本机而且存放到一个集中存储的地方，修改Session也是发生在集中存储的地方。Web服务器使用Session从集中存储的地方读取。这样保证了不同Web服务器读取到的Session数据都是一样的。存储Session的具体方式可以是数据库、分布式存储系统等。这个方案解决了Session Replication方案中内存的问题，对于网络带宽也比Session Replication要好。
存在问题：
a. 读写Session数据引入了网络操作，这相对于本机的数据读取来说，问题就在于存在时延和不稳定性，不过我们的通讯基本都是发生在内网，问题不大。
b. 如果集中存储Session的机器或者集群有问题，就会影响到我们的应用。
相对于Session Replication，当Web服务器数量比较大、Session数比较多的时候，这个集中存储方案的优势是非常明显的。
●集群单点故障及冗余备份

文章图片

在集群架构中因某个节点故障导致全局无法运转的故障叫做单点故障，上图中标有叹号的服务器一旦发生故障就会导致前端应用服务器不能提供正常的服务，在集群中要尽量避免这种情况的发生，所有关键性节点做好冗余备份；
●负载均衡器

文章图片

负载均衡器的三种分发方式：基于不同的调度算法实现不同的分发方式；
轮流：集群中所有参与的服务器轮流负责响应，你一次我一次按顺序轮流；
权重：给某台服务器增加权重占比，比如性能好的服务器权重高，实现能者多劳；
负载：按服务器的负载情况来进分发，优先给负载低的服务器分发任务；比如哪个服务器的会话链接最少，就给它发任务；
【cluster计算机集群-cookie-session-】负载均衡器是接收所有用户请求并实现分发服务任务的最重要的一环，所以这里一定不要使用单点，要给负载均衡器做冗余，如果工作中的负载均衡器故障了，要有其他负载均衡器可以立刻接替工作，正常提供服务；

文章图片

上图所示：负载均衡器有主备关系，二者之间是持续保持连接的，主设备定期向备用设备发送报文，告知自己一切正常，可以看做是心跳正常，一旦备用服务器在一定时间没有接收到主设备发来的心跳监测，那么备用服务器就认定主设备宕机了，这时备用设备就把主设备的IP地址和端口号拿过来使用，“摇身一变”就成了负责响应用户端的调度器了；
failover：在集群中，在一个主机发生故障时，把它所提供的服务转移至其他主机，叫做故障转移，也叫失效转移；
failback：一旦自己接触故障，又恢复回来工作，叫做故障恢复；
高可用集群，像给负载均衡器添加冗余的这种思想就是高可用集群的思想；提升可用性；high availability cluster
Linux Cluster类型：
LB：Load Balancing，负载均衡；
HA：High Availiablity，高可用；避免SPOF(single point of failure)单点失败
MTBF:平均无故障时间
MTTR:平均恢复前时间
A=MTBF/（MTBF+MTTR）
(0,1)：90%, 95%, 99%, 99.5%, 99.9%, 99.99%, 99.999%, 99.9999%
HP：High Performance，高性能；
分布式系统：
分布式存储