分布式session共享

（哎，这种类型的博客就显得特别虚伪，因为全是网上的内容总结，几乎没有自己的实践）

首先先从分布式开始说起，因为分布式架构，每个模块都在不同的服务器里，而session的话只能在同一个服务器进行数据共享，那么就会存在着分布式session共享的问题，如果不解决这个问题，那么用户在访问不同的服务之间就得需要进行不停的登录！

1.网上有种说法是基于nginx的ip_hash策略，利用用户的ip进行hash然后固定分配在某台服务器上，emm，其实这个方法我一开始不懂，因为我一开始想的是不同的服务怎么会保存在同一台服务器，然后我想了下，可能意思是利用ip进行hash然后保存在特定的一些服务器上吧。。。这样子是最容易理解的方法，但是他却失去了Nginx负载均衡的功能。。

2.基于cookie进行实现，也就是把用户名密码存入cookie里，然后再访问服务器的时候从cookie里面取出数值然后去数据库进行比较

网上说法是这样不安全，emm，但是我想我们可以用MD5（https://www.cmd5.com/，如果不加salt，那么存在被人暴力破解的情况）+salt进行加密为什么还会不安全？？？

3.直接把session进行各个服务器的存放（捂脸），我第一时间想到的就是这样，简单快捷粗暴。

4.利用redis实现session共享

其实这个和第二种的cookie差不多，就是用户登录了然后把session存入redis的hash里面，比如大键是SESSION小键是sessionId，然后在cookie里面存放sessionid，这样在用户访问的时候就可以根据cookie去对应的redis里面查找。

emmmmmm，我猜测，这个实现的原理应该是每个用户在访问的时候就只有1个redis？？？？，那么基于这个猜测，是不是说比如我们自定义一个hashmap然后把session存入进去。。。然后通过cookie查找对应的键。。。。。（甚至把这个hashmap持久化，比如利用io写入一个文件，然后用户就可以做到登录了以后，关闭浏览器以后不输入账号密码也能登录！（抽空找时间实现下））

5.利用cas技术进行单点登录！！！

这个是文章的原理，我也是看着他进行总结的

https://blog.csdn.net/wang379275614/article/details/46337529

下面是我的总结（可能是错的）：

cas执行流程：

​ 访问cas客户端会检测本地没有session（根据普通的cook？？），然后检测有没有st，如果没有那就进行定向到服务端，

​ 终端访问cas服务器的时候，服务器会判断有没有tgc（特别的cook？（是cas 服务器用来确认用户的cookie）（有的话直接根据tgc验证tgt））， 然后进行认证（这一步是不是为了补偿st失效）

​ 认证成功后，会返回tgc（cas会话标识）和自己保存的tgt（登录票据（相当于session？？？）），然后返回st（服务票据），然后st是直接写在地址栏上进行返回的

然后浏览器在访问的时候，携带了ticket，客户端的Authen*filter看到了会跳过交给Ticket**进行处理，原理是去cas的服务器验证st的有效性，如果有效那么过滤器会得到消息然后把用户信息写进session

​

留段空白等我有时间了去自己写一个简化版的cas，其实原理就是cookie和session