浅谈常见的集群技术应用

从字面上能够看出，集群是多个独立的单机集合在一起形成一个群体，即叫做集群，集群可以充分利用群体的力量，让服务发挥倍数级的提高，比如一个单体机器能处理100W/S 请求，在增加一台能就能处理200W/S请求，因此集群在系统应用是非常适用的一种技术，一般来说，集群服务一般会涉及以下一些步骤。

 

一.负载均衡常用方案及算法，针对请求或需处理的任务，通过一系列策略均匀的去分配个各服务器，让群体中的服务器最大化发挥效率，一般的负载均衡方案有：

1.基于DNS的负载均衡
根据不同的地域的请求转发分配给最近地域的服务器进行处理，主要是根据DNS来判断请求用户的归属地实现请求的转发，此种负载均衡方案比较简单， 缺点由于DNS的多级缓存，变更配置后可能生效不及时

2.基于硬件的负载均衡F5
直接通过硬件设备

3.基于软件的负载均衡
通过软件的方式来分发请求，一般有LVS和NGINX，LVS工作在第四层的传输层，NGINX工作在第七层的应用层，工作在第四层性能一般几十万/S,NGINX一般几万/S,通过软件来做分发一般价格比较便宜，投入一些技术即可，互联网企业用的比较多

4.常用的负载均衡算法
1）轮训策略：顺序轮询、随机轮询、按权重轮询（机器性能高的权重设置高一点，性能低的权重低一点）

2）负载度策略
评估集群中服务器的负载度，然后再来分配流量，结合了服务器的运行状态，动态进行分配，比轮训更合理，但性能会有影响，因为会通过一些机制与服务器做交互（采集连接数、cpu指标、i/o指标）来判断哪台服务器压力大
3）响应策略
负载均衡器优先将请求转发给相应最快的服务器进行处理，如何知道哪天服务器响应最快，需要通过一些算法机制去判断某个服务器相应最快，比如每分钟通过排行榜来统计相应请求最快的服务器，后面有请求，直接按排行榜优先级进行转发。
4）哈希策略
对请求中的某个信息比如ip进行hash，然后根据服务器总数进行取模得到一个确定的值，根据确定的值转发到对应的服务器，因此可以保证统一个用户可以每次都是对应固定的服务器，这样可以处理一些缓存或会话问题。

二、健康检测（心跳机制）
集群中有很多机器，如何判断集群中哪些机器是可用或不可用，需要用到健康检测机制，也就是所谓的心跳检测，通过心跳机制来判断服务器能否提供服务。
1.NGINX中，可以在负载均衡中进行设置,健康检测参数：

 upstream servertest{
       server 10.91.81.174:8080 max_fails=3 fail_timeout=10s weight=1;
       server 10.91.80.32:8080  max_fails=3 fail_timeout=10s weight=2;
    }   

max_fails：检查失败的次数，在fail_timeout设定的时间内，当检查失败达到三次后，标记该服务器不可用，则取消往该服务器的分发请求
fail_timeount: 表示在单位时间内检测服务器健康状态，配合max_fails使用，如果可用就标识该服务器可用，否则继续按照fail_timeount时间检测max_fails次数

2. 通过ngx_http_proxy_module 模块进行参数设定，进行监控检测
proxy_connect_timeout 60s 设置与后端服务器建立连接的超时时间。 注意这个超时一般不可能大于75秒
proxy_read_timeout 60s 定义从后端服务器读取响应的超时。此超时是指相邻两次读操作之间的最长时间间隔，而不是整个响应传输完成的最长时间。如果后端服务器在超时时间段内没有传输任何数据，连接将被关闭。
proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...;
 

指定在何种情况下一个失败的请求应该被发送到下一台后端服务器：
 

指定在何种情况下一个失败的请求应该被发送到下一台后端服务器：

error           # 与服务器建立连接，向服务器传递请求或读取响应头时发生错误
timeout         # 与服务器建立连接，向服务器传递请求或读取响应标头时发生超时
invalid_header  # 服务器返回了一个空的或无效的响应
http_500        # 服务器返回响应，代码为500
http_502        # 服务器返回响应码为502
http_503        # 服务器返回响应，代码为503
http_504        # 服务器返回代码为504的响应
http_403        # 服务器返回响应，代码为403
http_404        # 服务器返回了代码为404的响应
http_429        # 服务器返回响应，代码为429（1.11.13）
off             # 禁用将请求传递到下一个服务器
non_idempotent  # 通常，具有请求 非幂等 方法（POST，LOCK，PATCH）不传递到请求是否已被发送到上游服务器（1.9.13）的下一个服务器

三、集群中如何解决SESSION会话共享问题
什么是SESSION，其实很多人都弄的不是很清楚，实际上SESSION是在特定需求产生的，基于http无状态的连接而产生，http发送请求--接收完请求就结束了，因此session用于改善无状态的特征为有状态的，SESSION用于与服务端保持交互，如用户登录成功后产生一个SESSION，该SESSION会对应该用户一些的操作权限，那么当第一次产生session后，后续只要判断有该session即可，表示是合法的授权，并且sessionid会传给浏览器储存在cookie中，下次请求cookie直接带上这个sessionid即可，验证通过即表示是合法的授权用户。
集群中各请求可能会被转发到其它服务器，如何保持session会话显然是个需要解决的问题，如不保持会话可能就是非法访问或每次都要重新登录，显然很繁琐，可以通过如下方式保持session

1.粘性session
粘性session 是指Ngnix 每次都将同一用户的所有请求转发至同一台服务器上，即将用户与服务器绑定，一般实现是哈希策略，hash 用户ip 取模对应后端服务器。

2.服务器session 复制
即每次session 发生变化时，创建或者修改，就广播给所有集群中的服务器，使所有的服务器上的session 相同。

3.session 共享
缓存session，使用redis， memcached。

4.session 持久化
将session 存储至数据库中，像操作数据一样才做session

四、几种的具体实现方案：

1.持久化session到数据库，即使用数据库来储存session。数据库正好是我们普遍使用的公共储存空间，一举两得，推荐使用mysql数据库，轻量并且性能良好。

优点：就地取材，符合大多数人的思维，使用简单，不需要太多额外编码工作 
缺点：对mysql性能要求较高，访问mysql需要从连接池中获取连接，又因为大部分请求均需要进行登录鉴权，所以操作数据库非常频繁，当用户量达到一定程度之后，极易造成数据库瓶颈，不适用于处理高并发的情况。

2.使用redis共享session。redis是一个key-value的储存系统。可以简单的将其理解为一个数据库，与传统数据库的区别是，它将数据储存于内存中，并自带有内存到硬盘的序列化策略，即按策略将内存中的数据同步到磁盘，避免数据丢失，是目前比较流行的解决方案。

优点：无需增加数据库的压力，因为数据存储于内存中，所以读取非常快，高性能，并能处理多种类型的数据。 
缺点：额外增加一些编码，以便操作redis。

3.使用memcache同步session，memcache可以实现分布式，可将服务器中的内存组合起来，形成一个“内存池”，以此充当公共空间，保存session信息。

优点：数据储存在内存中，读取非常快，性能好； 
缺点：memcache把内存分成很多种规格的存储块，有大有小，不能完全利用内存，会产生内存碎片，浪费资源，如果储存块不足，还会产生内存溢出。

4.通过脚本或守护进程在多台服务器之间同步session。

优点：实现了session共享； 
缺点：对个人来说实现较为复杂，速度不稳定，有延时性，取决于现实中服务运行状态，偶然性较大，如果用于访问过快，可能出现session还没同步成功的情况。