单点登录与消息队列以及在J2EE中的实现方案

前言

这次为大家简单介绍两个在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发起请求后,会有以下几种情形:

  1. B含有session,C含有Cookie,且session和Cookie中的token一致,那么不需要向A求助
  2. C中对于B无Cookie或Cookie过期或session与Cookie不一致,将向A发起请求。之后根据A的情形,有以下情况:
    • A中session与C中Cookie的token一致,重新生成凭证信息返回给B,B重新写入Cookie与session
    • A中Cookie过期或信息不一致,将重定向到登录页面
  3. 对于登录情形,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中加入以下依赖

<dependency>
        <groupId>org.springframework.data</groupId>
        <artifactId>spring-data-redis</artifactId>
        <version>1.4.2.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-pool2</artifactId>
        <version>2.3</version>
    </dependency>
    <dependency>
        <groupId>redis.clients</groupId>
        <artifactId>jedis</artifactId>
        <version>2.6.2</version>
    </dependency>

在ApplicationContext.xml的头部插入schema

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

在ApplicationContext中加入Redis的配置

<!-- 配置redis池,依次为最大实例数,最大空闲实例数,(创建实例时)最大等待时间,(创建实例时)是否验证 -->
    <bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
        <property name="maxTotal" value="${redis.maxTotal}"/>
        <property name="maxIdle" value="${redis.maxIdle}"/>
        <property name="maxWaitMillis" value="${redis.maxWaitMillis}"/>
        <property name="testOnBorrow" value="${redis.testOnBorrow}"/>
    </bean>

    <!-- 配置数据源-->
    <bean id="redisConnectionFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
        <property name="hostName" value="127.0.0.1"></property>
        <property name="port" value="6379"></property>
        <property name="usePool" value="true"></property>
    </bean>    

    <!-- 配置数据操作 -->
    <bean id="redisTemplate" class="org.springframework.data.redis.core.RedisTemplate">
        <property name="connectionFactory" ref="redisConnectionFactory"></property>
    </bean>
    <bean id="jdkSerializer" class="org.springframework.data.redis.serializer.JdkSerializationRedisSerializer" />

    <bean id="messageListener" class="org.springframework.data.redis.listener.adapter.MessageListenerAdapter">
        <property name="delegate" ref="messageDelegateListener" /> <!--这里的messageDelegateListener在后面的文件中注解的,这里对应的具体消息处理类的实现-->
        <property name="serializer" ref="jdkSerializer" />
    </bean>     

    <!-- 将消息handler注册 -->
    <redis:listener-container>
        <redis:listener ref="messageListener" method="handleMessage" serializer="jdkSerializer" topic="java"/>
    </redis:listener-container>

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

<bean id="messageDelegateListener" class="***.***.***" />

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

import java.io.Serializable;

import org.springframework.stereotype.Component;

@Component(value="messageDelegateListener")
public class ListenMessage {
    public void handleMessage(Serializable message){
        System.out.println(message);
    }
}
时间: 2024-08-03 08:40:32

单点登录与消息队列以及在J2EE中的实现方案的相关文章

消息队列feed程序实现中的问题

因项目需要, 构建了很多消息队列还排队处理任务, 相应的每个队列也配有一个feed程序来feed消息 一开始很简单地这样做: while (true){ $msg = $query->bPop(); //消息处理程序 } 这种方式下feed程序一开始运行就永远不会退出,  乍看没有问题, 但存在一个问题, 一旦消息处理程序发生变化, 如果不手动kill进程后重启进程, 改动就不会被加载. 另: 据说PHP进程运行过久就会产生垃圾难以回收, 需要终止进程来回收进程垃圾. 所以我讲feed程序都改成

信号量,消息队列,共享内存中ket_t键值的生成函数ftok。

在System V中,我们经常用用key_t的值来创建或者打开信号量,共享内存和消息队列.这个在IPC的环境中十分的重要,比如说,服务器创建了一个消息队列,等待 客户机发送请求.那么如何创建或者打开已有的消息队列呢?一般而言,我们对于服务器使用的路径和项目id(proj_id)是已知的,所以客户机可以获取 相同的key来打开 消息队列并进行操作.下面就是ftok的使用原型: ftok函数   函数ftok把一个已存在的路径名和一个整数标识得转换成一个key_t值,称为IPC键: # includ

MQ消息队列在软件开发中的作中

MQ的作用是非常之大的. 1.解耦. 当一个大型的系统.比如,商城系统.包括以下的功能: 1.发邮件 2.发短信 3.抽奖 4.搜索等 如果你都用一台服务器,做到一个程序里,代码会非常庞大,不利于维护.同时一台服务器的机器性能也跟不上. 我们用MQ来做,它们之间的通信,直接用MQ. 2.销峰. 假如你的秒杀活动,同时有一大批人在抢购,这个时候,如果你每个人都等待走完整的流程,那么系统会非常的延迟.我们也没有办法保证一定是按顺序执行的.有可能会多买,两个用户同时中奖等,数据不完.如果我们可以把用户

项目分布式部署那些事(1):ONS消息队列、基于Redis的Session共享,开源共享

因业务发展需要现在的系统不足以支撑现在的用户量,于是我们在一周之前着手项目的性能优化与分布式部署的相关动作. 概况 现在的系统是基于RabbitHub(一套开源的开发时框架)和Rabbit.WeiXin(开源的微信开发SDK)开发的一款微信应用类系统,主要业务是围绕当下流行的微信元素,如:微官网.微商城.微分销.营销活动.会员卡等. 关于RabbitHub详情请戳: .NET 平台下的插件化开发内核(Rabbit Kernel) RabbitHub开源情况及计划 关于Rabbit.WeiXin详

大型网站架构系列:消息队列

出处:ITFLY8 网址:http://www.cnblogs.com/itfly8/p/5156155.html 一.消息队列概述 消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题.实现高性能,高可用,可伸缩和最终一致性架构.是大型分布式系统不可缺少的中间件. 目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等. 二.消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景.异

单点登录技术:微软Passport单点登录协议和自由联盟规范

随着互联网络应用的普及,越来越多的人开始使用互联网上提供的服务.然而目前提供服务的网站大多采用用户名.口令的方式来识别用户身份,这使得用户需要经常性的输入自己的用户名.口令.显然这种认证方式存在着弊端:随着用户网络身份的增多,用户相应的需要记忆多组用户名.口令,这给用户造成记忆上的负担:另外频繁的输入用户名.口令,会相应的增大用户的口令密码被破解的机率.为了改变这一现状,单点登录技术应运而生. 单点登录技术的核心思想是通过一定的方式使得各提供服务的网站之间建立某种联系,用户只需要在其中一个认证网

大型网站架构之分布式消息队列

以下是消息队列以下的大纲,本文主要介绍消息队列概述,消息队列应用场景和消息中间件示例(电商,日志系统). 本次分享大纲 消息队列概述 消息队列应用场景 消息中间件示例 JMS消息服务 常用消息队列 参考(推荐)资料 本次分享总结 一.消息队列概述 消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题.实现高性能,高可用,可伸缩和最终一致性架构.是大型分布式系统不可缺少的中间件. 目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,K

转:消息队列的使用场景

一.消息队列概述 消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题.实现高性能,高可用,可伸缩和最终一致性架构.是大型分布式系统不可缺少的中间件. 目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等. 二.消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景.异步处理,应用解耦,流量削锋和消息通讯四个场景. 2.1异步处理 场景说明:用户注册后,需要发注册邮件和注册短信.传统

关于消息队列的使用

一.消息队列概述消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构.目前使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ 二.消息队列应用场景以下介绍消息队列在实际应用中常用的使用场景.异步处理,应用解耦,流量削锋和消息通讯四个场景. 2.1异步处理场景说明:用户注册后,需要发注册邮件和注册短信.传统的做法有两种 1.串行的方式:2.并行方式a.串行方式:将