资讯专栏INFORMATION COLUMN

单点登录与消息队列

Jioby / 860人阅读

摘要:前言很久都没有写博客了,这次为大家简单介绍两个在开发中经常使用的概念单点登录和消息队列以及具体到中的一些实现方案。单点登录的实质就是安全上下文或凭证在多个应用系统之间的传递或共享。

前言

很久都没有写博客了,这次为大家简单介绍两个在WEB开发中经常使用的概念——单点登录和消息队列以及具体到J2EE中的一些实现方案。本文原创性的工作比较少,主要是一些总结概括和自己的理解。

单点登录SSO SSO的业务场景

所谓单点登录就是在一个站点登录之后可以授信给其他站点,这样就可以做到一次登录,到处操作。单点登录的实质就是安全上下文(Security Context)或凭证(Credential)在多个应用系统之间的传递或共享。

大部分的网站采用Cookie作为登录的一种简单实现方案,在同一个一级域名下面,这样做并无问题,不需要对各个子系统分别验证。但是Cookie无法跨域传递。将用户的登录、凭证取得等解耦处理多带带作为一个子系统是合理的选择。

SSO的核心要素

共享同一个身份认证系统,也就是说所有站点的身份验证操作在同一个系统下完成

每个子系统从共同的身份认证系统中取得用户凭证,包含用户的身份、权限信息等

示意图如下:

SSO的一种简单实现方案

下面以采用Cookie的一种方案为例来解释:

我们首先定义授信服务器A,受信服务器B,客户C;当前的业务是B需要验证C的身份。需要注意的是B和C都会保有session来记录C的登录状态,均会向C 的Header中写入对应自己域名的Cookie以存储凭证信息。Cookie中含有tokenId来标示C,也就是说对于A和B他们的Cookie中对应于同一个C,其tokenId应该一致。

C向B发起请求后,会有以下几种情形:

B含有session,C含有Cookie,且session和Cookie中的token一致,那么不需要向A求助

C中对于B无Cookie或Cookie过期或session与Cookie不一致,将向A发起请求。之后根据A的情形,有以下情况:

A中session与C中Cookie的token一致,重新生成凭证信息返回给B,B重新写入Cookie与session

A中Cookie过期或信息不一致,将重定向到登录页面

对于登录情形,A将更新Cookie与session,然后C再向B发起请求,这时就会变成2中第一种情况,导致A和B的信息完成同步。

消息队列 MQ的业务场景

消息队列本身是简单的,可以直接看做一个队列,重点是如何定义存储在队列中的数据格式,以满足我们对应的操作需求。MQ常常应用于那些并发量大而对于实时性要求不高的情况。举个例子,比如一个用户量较大的社交网站的评论发布,为什么这么说呢?对于这个任务,队列中只用存储评论相关信息,对于从队列中取的一方,只需要进行插入操作,符合前面所说的并发量大且可以有延时,同时并不难实现。

MQ的两种模式

消息队列在WEB开发中主要有两种模式:

生产者/消费者模式:对于一则消息,只有一个消费者线程会去处理它,适用于我们上面所说的评论系统

发布者/订阅者模式:对于所有订阅者,它可以读取所有在它加入之后发布的消息

在J2EE中加入消息队列,我个人认为应该是这样的:对于特定的HTTP请求,调用生产者/发布者的接口,入队必要消息,这个并不困难。大有蹊跷的我觉得在于处理消息的一方,可以实现listener将其交由容器管理,也可以自己开辟池来调度。举例来说明,对于前者Spring-redis实现的pub/sub模式队列就是直接在配置文件中设定RedisListener的实现类,对于后者,你可以直接独立出来写离线脚本来监听队列。

MQ的实现方案

目前业界有比较成熟的MQ解决产品,如下:

RabbitMQ

ActiveMQ

kafka

Redis

MQ的Spring+Redis实现简单示例

在Pom.xml中加入以下依赖

    
        org.springframework.data
        spring-data-redis
        1.4.2.RELEASE
    
    
        org.apache.commons
        commons-pool2
        2.3
    
    
        redis.clients
        jedis
        2.6.2
     

在ApplicationContext.xml的头部插入schema

xmlns:redis="http://www.springframework.org/schema/redis"

在ApplicationContext中加入Redis的配置

    
    
        
        
        
        
    


    
    
        
        
        
        

    
    
        
            
    
    

    
         
        
         
    
    
    
        
    
               

上文在定义Listener的时候采用了注解对象作为实现类,也可以手动在配置文件中再写一个bean,如下

    

最后我们给出一个接收方的实现

import java.io.Serializable;

import org.springframework.stereotype.Component;

@Component(value="messageDelegateListener")
public class ListenMessage {
    public void handleMessage(Serializable message){
        System.out.println(message);
    }
}

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/64540.html

相关文章

  • 消息系统设计实现「上篇」

    摘要:原文链接消息系统设计与实现上篇由于文章篇幅较长,而作者精力有限,不希望这么早就精尽人亡,故分成上下篇来写消息系统的设计与实现。更新于关联文章消息系统设计与实现下篇如果本文对您有用请不要吝啬你们的与这会大大支持我们继续创作 原文链接:Bluesun | 消息系统设计与实现「上篇」 由于文章篇幅较长,而作者精力有限,不希望这么早就精尽人亡,故分成上下篇来写消息系统的设计与实现。上篇主要讲...

    v1 评论0 收藏0
  • 《大型网站系统Java中间件》读书笔记(上)

    摘要:另一个用户请求过来,负载均衡器指派这个请求到服务器。这样就平摊了请求这种方式就叫做轮询策略还有很多种,就看你想怎么实现了,反正这个逻辑的代码放在负载均衡器上。 前言 只有光头才能变强。文本已收录至我的GitHub仓库,欢迎Star:https://github.com/ZhongFuCheng3y/3y 这本书买了一段时间了,之前在杭州没带过去,现在读完第三章,来做做笔记 showI...

    baukh789 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<