分布式集群架构场景化解决⽅案(Session共享，分布式ID，集群时钟同步)

一.分布式集群时钟同步问题和解决方案

1.时钟不同步导致的问题

时钟此处指服务器时间,如果集群中各个服务器时钟不⼀致势必导致⼀系列问题，
试想 “集群是各个服务器⼀起团队化作战，⼤家⼯作都不在⼀个点上，岂不乱了套.

举个例⼦:

2.集群时钟同步配置

集群时钟同步思路
情况1：分布式集群中各个服务器节点都可以连接互联⽹

操作⽅式：
#使⽤ ntpdate ⽹络时间同步命令
ntpdate -u ntp.api.bz #从⼀个时间服务器同步时间

情况2,3：分布式集群中某⼀个服务器节点可以访问互联⽹或者所有节点都不能够访问互联⽹

操作⽅式：
1).选取集群中的⼀个服务器节点A(172.17.0.17)作为时间服务器，⾸先设置好A的时间,把A配置为时间服务器（修改/etc/ntp.conf⽂件）
（整个集群时间从这台服务器同步，如果这台服务器能够访问互联⽹，可以让这台服务器和⽹络时间保持同步，如果不能就⼿动设置⼀个时间）

 - ⾸先设置好A的时间
 - 把A配置为时间服务器（修改/etc/ntp.conf⽂件）
		1、如果有 restrict default ignore，注释掉它
		2、添加如下⼏⾏内容
		 restrict 172.17.0.0 mask 255.255.255.0 nomodify notrap #放开局域⽹同步功能,172.17.0.0是你的局域⽹⽹段
		 server 127.127.1.0 # local clock
		 fudge 127.127.1.0 stratum 10
		3、重启⽣效并配置ntpd服务开机⾃启动
		 service ntpd restart
		 chkconfig ntpd on
 - 集群中其他节点就可以从A服务器同步时间了

二.分布式ID解决⽅案

 1. UUID(可以⽤)：UUID 是指Universally Unique Identifier，翻译为中⽂是通⽤唯⼀识别码，产⽣重复UUID 并造成错误的情况⾮常低
 2. 独⽴数据库的⾃增ID
 	1)如A表分表为A1表和A2表。可以单独创建⼀个Mysql数据库，在数据库中创建⼀张表，这张表的ID设置为⾃增。
 	2)需要全局唯⼀ID的时候，就模拟向这张表中模拟插⼊⼀条记录，此时ID会⾃增。
 	3)然后可以通过Mysql的select last_insert_id() 获取到表中⾃增⽣成的ID.
 注：使⽤独⽴的Mysql实例⽣成分布式id，虽然可⾏，但性能和可靠性都不够好，因为需要代码连接到数据库才能获取到id，性能⽆法保障。现在这种⽅式现在基本不⽤，
 3.SnowFlake 雪花算法（可以⽤，推荐）
 '雪花算法是Twitter推出的⼀个⽤于⽣成分布式ID的策略'
⽣成的ID是⼀个long型，那么在Java中⼀个long型是8个字节，算下来是64bit。

最后
一些互联网基于上面的方案封装了一些分布ID生产器
'⽐如滴滴的tinyid（基于数据库实现）、百度的uidgenerator（基于SnowFlake）和美团的leaf（基于数据库和SnowFlake）'

4.借助Redis的Incr命令获取全局唯⼀ID（推荐）
Redis Incr 命令将 key 中储存的数字值增⼀。如果 key 不存在，那么 key 的值会先被初始化为 0，然后再执⾏ INCR 操作。

四. Session共享问题

Session共享及Session保持或者叫做Session⼀致性

1.Session问题原因分析
	1)出现这个问题的原因，从根本上来说是因为Http协议是⽆状态的协议。
客户端和服务端在某次会话中产⽣的数据不会被保留下来，所以第⼆次请求服务端⽆法认识到你曾经来过。
	2)Http为什么要设计为⽆状态协议？
	早期都是静态⻚⾯⽆所谓有⽆状态，后来有动态的内容更丰富，就需要有状态，出现了两种⽤于保持Http状态的技术，那就是Cookie和Session。

⽽出现上述不停让登录的问题，分析如下图：

a场景：nginx默认轮询策略

2.解决Session⼀致性的⽅案

 1)Nginx的 IP_Hash 策略（可以使⽤）
 	同⼀个客户端IP的请求都会被路由到同⼀个⽬标服务器，也叫做会话粘滞
 	优点：配置简单，不⼊侵应⽤，不需要额外修改代码
 	缺点：
 		1.服务器重启Session丢失
 		2.存在单点负载⾼的⻛险
 		3.单点故障问题
 2)Session复制（不推荐）
 	也即，多个tomcat之间通过修改配置⽂件，达到Session之间的复制
	'优点'
	 - 不⼊侵应⽤
	 - 便于服务器⽔平扩展
	 - 能适应各种负载均衡策略
	 - 服务器重启或者宕机不会造成Session丢失
	'缺点'
		- 性能低
		- 内存消耗
		- 不能存储太多数据，否则数据越多越影响性能
		- 延迟性

3) Session共享，Session集中存储（推荐）
Session的本质就是缓存，那Session数据为什么不交给专业的缓存中间件呢？⽐如Redis

'优点'
能适应各种负载均衡策略
服务器重启或者宕机不会造成Session丢失
扩展能⼒强
适合⼤集群数量使⽤

'缺点'
对应⽤有⼊侵，引⼊了和Redis的交互代码