From dee636e3b622d75fcbf041f6f9d9ba1487e1a0bf Mon Sep 17 00:00:00 2001 From: fanxb Date: Fri, 21 Jan 2022 19:37:57 +0800 Subject: [PATCH] =?UTF-8?q?=E5=88=87=E6=8D=A2=E4=B8=BA=E4=B8=83=E7=89=9B?= =?UTF-8?q?=E4=BA=91pic?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- java/web相关/2.spring boot SSO单点登录.md | 12 ++++++------ 数据库/redis/redis三种集群模式.md | 12 ++++++------ 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/java/web相关/2.spring boot SSO单点登录.md b/java/web相关/2.spring boot SSO单点登录.md index 5e740ed..9a1cb5b 100644 --- a/java/web相关/2.spring boot SSO单点登录.md +++ b/java/web相关/2.spring boot SSO单点登录.md @@ -8,7 +8,7 @@ categories: - "spring boot学习" --- -![塞尔达，林克](http://sqiniupic.fleyx.com/blog/20201027201713.png) +![塞尔达，林克](http://qiniupic.fleyx.com/blog/20201027201713.png)   最近我们组要给负责的一个管理系统 A 集成另外一个系统 B，为了让用户使用更加便捷，避免多个系统重复登录，希望能够达到这样的效果——用户只需登录一次就能够在这两个系统中进行操作。很明显这就是**单点登录(Single Sign-On)**达到的效果,正好可以明目张胆的学一波单点登录知识。 @@ -39,7 +39,7 @@ categories:   cookie 允许同域名(或者父子域名)的不同端口中共享 cookie,这点和 http 的同域策略不一样（http 请求只要协议、域名、端口不完全相同便认为跨域）。因此只需将多个应用前台页面部署到相同的域名（或者父子域名），然后共享 session 便能够实现单点登录。架构如下： -![共享session架构](http://sqiniupic.fleyx.com/blog/20201027204149.png) +![共享session架构](http://qiniupic.fleyx.com/blog/20201027204149.png)   上面方案显而易见的限制就是不仅前台页面需要共享 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 共享给各个平台页面即可。系统架构如下： -![基于jwt的回调](http://sqiniupic.fleyx.com/blog/20201027204300.png) +![基于jwt的回调](http://qiniupic.fleyx.com/blog/20201027204300.png)   此架构中，业务系统 A 和业务系统 B 之间不需要有任何联系，他们都只和 SSO 认证平台打交道，因此可以任意部署，没有同域的限制。你可能就要问了这样要怎么共享身份凭证（也就是 jwt 字符串）？这里就要通过 url 参数来进行骚操作了。文字总结来说是这样的：jwt 存到认证平台前端的 localStore(不一定是 localStore，cookie，sessionStore 都可以),然后业务平台携带自己的回调地址跳转到认证中心的前台，认证中心的前台再将 ujwt 作为 url 参数，跳回到那个回调地址上，这样就完成了 jwt 的共享。   文字很可能看不懂，下面是整个过程的路程图： -![流程图](http://sqiniupic.fleyx.com/blog/20201027204342.png) +![流程图](http://qiniupic.fleyx.com/blog/20201027204342.png) 相信通过上面的流程图你应该能大概看明白，jwt 是如何共享了的吧，还看不懂的继续看下来，下面上一个 spring boot 实现的简易 SSO 认证。主要有两个系统：SSO 认证中心，系统 A（系统 A 换不同端口运行就是系统 A、B、C、D 了). @@ -123,12 +123,12 @@ SSO 说：好嘞，这个地址是合法的可以送 jwt 过去，这就跳转   这里上几个效果图： - 系统 A 首次登陆系统 - ![系统A登陆gif](http://sqiniupic.fleyx.com/blog/20201027205546.gif) + ![系统A登陆gif](http://qiniupic.fleyx.com/blog/20201027205546.gif) 可以看到首次登陆是需要跳到 sso 认证中心输入用户名密码进行登陆验证的。登陆成功回跳后接口请求成功。 - 将 A 的启动端口改为 8082 后再次启动，当作系统 B - ![系统B登陆gif](http://sqiniupic.fleyx.com/blog/20201028091355.gif) + ![系统B登陆gif](http://qiniupic.fleyx.com/blog/20201028091355.gif) 可以看到这次是无需登陆的，跳到认证中心后就马上跳回了，如果去掉 alert 一般是看不出跳转过程的。 diff --git a/数据库/redis/redis三种集群模式.md b/数据库/redis/redis三种集群模式.md index 072fb3d..647da12 100644 --- a/数据库/redis/redis三种集群模式.md +++ b/数据库/redis/redis三种集群模式.md @@ -18,7 +18,7 @@ redis 目前主流的有三种集群模式，本文将对这三种模式进行 结构最简单的一种，和关系型数据的读写分离类似，一个主节点（master)，多个从节点(slaver)，写入请求全部到主节点上，读取会分散到各个从节点中,架构图如下： -![主从模式-架构图](http://sqiniupic.fleyx.com/blog20210630225614.png) +![主从模式-架构图](http://qiniupic.fleyx.com/blog20210630225614.png) 其中比较重要的是主从复制的实现原理，大致可分为三个部分：**建立连接**,**数据同步**,**命令传播** @@ -65,7 +65,7 @@ redis 目前主流的有三种集群模式，本文将对这三种模式进行 同步流程图如下： -![数据同步流程图](http://sqiniupic.fleyx.com/blog/20210702114631.png) +![数据同步流程图](http://qiniupic.fleyx.com/blog/20210702114631.png) 1. 从节点接收 slaveof 指令，开始进行数据同步 2. 判断是否首次进行同步 @@ -78,7 +78,7 @@ redis 目前主流的有三种集群模式，本文将对这三种模式进行 在命令传播阶段主从节点之间会彼此进行心跳检测，如下图： -![主从交互](http://sqiniupic.fleyx.com/blog/20210705172927.png) +![主从交互](http://qiniupic.fleyx.com/blog/20210705172927.png) #### 主节点向从节点发送`ping`命令 @@ -143,7 +143,7 @@ docker 部署见：[点击此处](https://github.com/FleyX/demo-project/tree/mas 哨兵模式架构图如下： -![哨兵模式架构图](http://sqiniupic.fleyx.com/blog/20210708154446.png) +![哨兵模式架构图](http://qiniupic.fleyx.com/blog/20210708154446.png) 哨兵节点是特殊的 redis 节点，不会用于存储数据 @@ -218,7 +218,7 @@ UID=0 GID=0 docker-compose up -d 启动完毕后，哨兵节点的配置文件会增加从节点以及其他哨兵的数据，如下： -![哨兵节点配置文件修改](http://sqiniupic.fleyx.com/blog/20210711215528.png) +![哨兵节点配置文件修改](http://qiniupic.fleyx.com/blog/20210711215528.png) 哨兵模式解决了故障转移的问题，但本质仍然是主从架构，只对读做了负载均衡，并未提高写入并发能力，无法应对大量写的问题，大量写的情况就需要对写也做负载均衡，即下面的集群模式. @@ -345,7 +345,7 @@ ba63167ebfd5f8cc9d02331275d15652e3c14aa1 192.168.143.84:11005@21005 slave ddffbf 一致性 hash 引入了一个虚拟圆环，圆环有一个范围，比如 0-2^32-1，然后把真实的节点均分到环中，对于每个 key，先做 hash 然后对环长度取余，得到在环中的位置，然后从此位置顺时针许找第一个遇到的节点，就是数据真实落的节点。 -![一致性hash示意图](http://sqiniupic.fleyx.com/blog/20210718115447.png) +![一致性hash示意图](http://qiniupic.fleyx.com/blog/20210718115447.png) 如上图所示，一致性哈希中，如果去掉了 cache 服务器 2,那么原本落到服务器 2 的数据就会全部落到服务器 3,对另外两个节点无影响。缺点也很明显，如果节点数比较少，删除一个节点会知道数据分布严重不均匀，比如上图中服务器 3 的数据量会是其他节点的两倍