切换为七牛云pic
This commit is contained in:
fanxb
parent
d41ea215f3
commit
dee636e3b6
@ -8,7 +8,7 @@ categories:
|
||||
- "spring boot学习"
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
  最近我们组要给负责的一个管理系统 A 集成另外一个系统 B，为了让用户使用更加便捷，避免多个系统重复登录，希望能够达到这样的效果——用户只需登录一次就能够在这两个系统中进行操作。很明显这就是**单点登录(Single Sign-On)**达到的效果,正好可以明目张胆的学一波单点登录知识。
|
||||
|
||||
@ -39,7 +39,7 @@ categories:
|
||||
|
||||
  cookie 允许同域名(或者父子域名)的不同端口中共享 cookie,这点和 http 的同域策略不一样（http 请求只要协议、域名、端口不完全相同便认为跨域）。因此只需将多个应用前台页面部署到相同的域名（或者父子域名），然后共享 session 便能够实现单点登录。架构如下：
|
||||
|
||||
|
||||
|
||||
|
||||
  上面方案显而易见的限制就是不仅前台页面需要共享 cookie，后台也需要共享 session（可以用`jwt`来干掉 session，但是又会引入新的问题，这里不展开）.这个方案太简单了，不作进一步说明。
|
||||
|
||||
@ -47,13 +47,13 @@ categories:
|
||||
|
||||
  通过上文可以知道，要实现单点登录只需将用户的身份凭证共享给各个系统，让后台知道现在是`谁`在访问。就能实现一次登录，到处访问的效果，实在是非常方便的。在 session 机制中是共享 sessionId，然后多个后台使用同一个 session 源即可。这里我们用一种新的基于 JWT 的 token 方式来实现，不了解 JWT 的可以看这篇：[java-jwt 生成与校验](http://blog.fleyx.com/blog/detail/2019-02-28-15-50),简单来说 jwt 可以携带无法篡改的信息（一段篡改就会校验失败),所以我们可以将用户 id 等非敏感信息直接放到 jwt 中，干掉了后台的 session。然后我们要做的就是将 jwt 共享给各个平台页面即可。系统架构如下：
|
||||
|
||||
|
||||
|
||||
|
||||
  此架构中，业务系统 A 和业务系统 B 之间不需要有任何联系，他们都只和 SSO 认证平台打交道，因此可以任意部署，没有同域的限制。你可能就要问了这样要怎么共享身份凭证（也就是 jwt 字符串）？这里就要通过 url 参数来进行骚操作了。文字总结来说是这样的：jwt 存到认证平台前端的 localStore(不一定是 localStore，cookie，sessionStore 都可以),然后业务平台携带自己的回调地址跳转到认证中心的前台，认证中心的前台再将 ujwt 作为 url 参数，跳回到那个回调地址上，这样就完成了 jwt 的共享。
|
||||
|
||||
  文字很可能看不懂，下面是整个过程的路程图：
|
||||
|
||||
|
||||
|
||||
|
||||
相信通过上面的流程图你应该能大概看明白，jwt 是如何共享了的吧，还看不懂的继续看下来，下面上一个 spring boot 实现的简易 SSO 认证。主要有两个系统：SSO 认证中心，系统 A（系统 A 换不同端口运行就是系统 A、B、C、D 了).
|
||||
|
||||
@ -123,12 +123,12 @@ SSO 说：好嘞，这个地址是合法的可以送 jwt 过去，这就跳转
|
||||
  这里上几个效果图：
|
||||
|
||||
- 系统 A 首次登陆系统
|
||||
|
||||
|
||||
|
||||
可以看到首次登陆是需要跳到 sso 认证中心输入用户名密码进行登陆验证的。登陆成功回跳后接口请求成功。
|
||||
|
||||
- 将 A 的启动端口改为 8082 后再次启动，当作系统 B
|
||||
|
||||
|
||||
|
||||
可以看到这次是无需登陆的，跳到认证中心后就马上跳回了，如果去掉 alert 一般是看不出跳转过程的。
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ redis 目前主流的有三种集群模式，本文将对这三种模式进行
|
||||
|
||||
结构最简单的一种，和关系型数据的读写分离类似，一个主节点（master)，多个从节点(slaver)，写入请求全部到主节点上，读取会分散到各个从节点中,架构图如下：
|
||||
|
||||
|
||||
|
||||
|
||||
其中比较重要的是主从复制的实现原理，大致可分为三个部分：**建立连接**,**数据同步**,**命令传播**
|
||||
|
||||
@ -65,7 +65,7 @@ redis 目前主流的有三种集群模式，本文将对这三种模式进行
|
||||
|
||||
同步流程图如下：
|
||||
|
||||
|
||||
|
||||
|
||||
1. 从节点接收 slaveof 指令，开始进行数据同步
|
||||
2. 判断是否首次进行同步
|
||||
@ -78,7 +78,7 @@ redis 目前主流的有三种集群模式，本文将对这三种模式进行
|
||||
|
||||
在命令传播阶段主从节点之间会彼此进行心跳检测，如下图：
|
||||
|
||||
|
||||
|
||||
|
||||
#### 主节点向从节点发送`ping`命令
|
||||
|
||||
@ -143,7 +143,7 @@ docker 部署见：[点击此处](https://github.com/FleyX/demo-project/tree/mas
|
||||
|
||||
哨兵模式架构图如下：
|
||||
|
||||
|
||||
|
||||
|
||||
哨兵节点是特殊的 redis 节点，不会用于存储数据
|
||||
|
||||
@ -218,7 +218,7 @@ UID=0 GID=0 docker-compose up -d
|
||||
|
||||
启动完毕后，哨兵节点的配置文件会增加从节点以及其他哨兵的数据，如下：
|
||||
|
||||
|
||||
|
||||
|
||||
哨兵模式解决了故障转移的问题，但本质仍然是主从架构，只对读做了负载均衡，并未提高写入并发能力，无法应对大量写的问题，大量写的情况就需要对写也做负载均衡，即下面的集群模式.
|
||||
|
||||
@ -345,7 +345,7 @@ ba63167ebfd5f8cc9d02331275d15652e3c14aa1 192.168.143.84:11005@21005 slave ddffbf
|
||||
|
||||
一致性 hash 引入了一个虚拟圆环，圆环有一个范围，比如 0-2^32-1，然后把真实的节点均分到环中，对于每个 key，先做 hash 然后对环长度取余，得到在环中的位置，然后从此位置顺时针许找第一个遇到的节点，就是数据真实落的节点。
|
||||
|
||||
|
||||
|
||||
|
||||
如上图所示，一致性哈希中，如果去掉了 cache 服务器 2,那么原本落到服务器 2 的数据就会全部落到服务器 3,对另外两个节点无影响。缺点也很明显，如果节点数比较少，删除一个节点会知道数据分布严重不均匀，比如上图中服务器 3 的数据量会是其他节点的两倍
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user