网上有很多的atomikos的分布式事务管理的配置，但是大多数都是同一类型的数据库，并没有跨数据库类型的配置。使用的数据库是Oracle和mysql。

配置文件代码如下：

<bean id="propertyConfigurer" class="*.*.*.DBConfigurer"><property name="order" value="1" /><property name="ignoreUnresolvablePlaceholders" value="true" />     <property name="location" value="WEB-INF/DBconfig.properties"/> </bean><bean id="mysqlDataSource" class="com.atomikos.jdbc.AtomikosDataSourceBean" 
        init-method="init" destroy-method="close"><!-- Set unique name for this DataSource -->  <property name="uniqueResourceName"><value>bpm</value></property><!-- Set XADatasource class name-->  <property name="xaDataSourceClassName" value="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource" /><property name="xaProperties"><props><prop key="user">${connection.username}</prop><prop key="password">${connection.password}</prop><prop key="url">${connection.url}</prop></props></property><!-- set properties for datasource connection pool -->  <property name="poolSize" value="3" /><!-- 管理 Connection 被占用的时间 --><!-- 如果不设置这个值，Atomikos使用默认的300秒(即5分钟)，那么在处理大批量数据读取的时候，一旦超过5分钟，就会抛出类似 Resultset is close 的错误 --><property name="reapTimeout"><value>20000</value></property>  </bean><bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean"><property name="dataSource" ref="mysqlDataSource" /><property name="packagesToScan"><list><value>smtcl.mocs.pojos.device</value><value>smtcl.mocs.pojos.authority</value><value>smtcl.mocs.pojos.job</value></list></property><property name="hibernateProperties"><props><!-- 			    <prop key="hibernate.connection.url">${connection.url}</prop> --><prop key="hibernate.connection.driver_class">${connection.driver}</prop><!--                 <prop key="hibernate.connection.username">${connection.username}</prop> --><!--                 <prop key="hibernate.connection.password">${connection.password}</prop> --><prop key="hibernate.dialect">${connection.dialect}</prop><prop key="hibernate.show_sql">${connection.show.sql}</prop><prop key="hibernate.connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</prop></props></property></bean><!-- atomikos事务管理器 --><bean id="atomikosTransactionManager" class="com.atomikos.icatch.jta.UserTransactionManager" 
        init-method="init" destroy-method="close"><property name="forceShutdown"><value>true</value></property></bean><bean id="atomikosUserTransaction" class="com.atomikos.icatch.jta.UserTransactionImp"><property name="transactionTimeout" value="300" /></bean><!-- spring 事务管理器 --><bean id="springTransactionManager"
        class="org.springframework.transaction.jta.JtaTransactionManager"><property name="transactionManager" ref="atomikosTransactionManager"/><property name="userTransaction" ref="atomikosUserTransaction" /><property name="allowCustomIsolationLevels" value="true"/> </bean><!-- 使用annotation定义事务，对于要加入事物的类，只需对该类加 @Transactional  --><tx:annotation-driven transaction-manager="springTransactionManager" /><!--     hibernate Dao层模板 --><!--     <bean id="transactionManager" --><!--         class="org.springframework.orm.hibernate3.HibernateTemplate"> --><!--         <property name="sessionFactory" ref="sessionFactory"></property> --><!--     </bean> --><bean id="transactionManager"
		class="org.springframework.orm.hibernate3.HibernateTransactionManager"><property name="sessionFactory" ref="sessionFactory" /></bean>

<bean id="erpPropertyConfigurer" class="*。*。*.ERPDBConfigurer"><property name="order" value="2" /><property name="ignoreUnresolvablePlaceholders" value="true" />     <property name="location" value="WEB-INF/ERPDBconfig.properties"/> </bean><bean id="oracleDataSource" class="com.atomikos.jdbc.AtomikosDataSourceBean"><property name="uniqueResourceName"><value>chh</value></property><property name="xaDataSourceClassName" value="oracle.jdbc.xa.client.OracleXADataSource"/><property name="xaProperties"><props><prop key="user">${connection.username}</prop><prop key="password">${connection.password}</prop><prop key="URL">${connection.url}</prop></props></property><property name="poolSize"><value>1</value></property><property name="borrowConnectionTimeout"><value>60</value></property></bean><bean id="erpSessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean"><property name="dataSource" ref="oracleDataSource" /><property name="packagesToScan"><list><value>smtcl.mocs.pojos.erp</value></list></property><property name="hibernateProperties"><props><!-- 			    <prop key="hibernate.connection.url">${erp.connection.url}</prop> --><prop key="hibernate.connection.driver_class">${erp.connection.driver}</prop><!--                 <prop key="hibernate.connection.username">${erp.connection.username}</prop> --><!--                 <prop key="hibernate.connection.password">${erp.connection.password}</prop> --><prop key="hibernate.dialect">${erp.connection.dialect}</prop><prop key="hibernate.show_sql">${erp.connection.show.sql}</prop><prop key="hibernate.connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</prop></props></property></bean><!-- 	 <bean id="erpTransactionManager" --><!--         class="org.springframework.orm.hibernate3.HibernateTemplate"> --><!--         <property name="sessionFactory" ref="erpSessionFactory"></property> --><!--     </bean> --><bean id="erpTransactionManager"
		class="org.springframework.orm.hibernate3.HibernateTransactionManager"><property name="sessionFactory" ref="erpSessionFactory" /></bean>

 分布式事务在连接Oracle数据时，可能会报错，错误信息如下：

javax.transaction.xa.XAException 
at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:526) 
at com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl.recover(WSRdbXaResourceImpl.java:1038) 
at com.ibm.ws.Transaction.JTA.XARminst.recover(XARminst.java:138) 
at com.ibm.ws.Transaction.JTA.XARecoveryData.recover(XARecoveryData.java:687) 
at com.ibm.ws.Transaction.JTA.PartnerLogTable.recover(PartnerLogTable.java:524) 
at com.ibm.ws.Transaction.JTA.RecoveryManager.resync(RecoveryManager.java:1859) 
at com.ibm.ws.Transaction.JTA.RecoveryManager.run(RecoveryManager.java:2580) 
at java.lang.Thread.run(Thread.java:810)

 可以在Oracle数据库中执行sql语句：

1.grant select on sys.dba_pending_transactions to  username;   
2.grant select on sys.pending_trans$ to username;   
3.grant select on sys.dba_2pc_pending to username;   
4.grant execute on sys.dbms_system to username;  

转自：http://hi.baidu.com/xianyang1981/item/20d68be050a50aaccf2d4f8e

一、ftp的port和pasv模式的工作方式
       FTP使用2个TCP端口，首先是建立一个命令端口（控制端口），然后再产生一个数据端口。国内很多教科书都讲ftp使用21命令端口和20数据端口，这个应该是教书更新太慢的原因吧。实际上FTP分为主动模式和被动模式两种，ftp工作在主动模式使用tcp 21和20两个端口，而工作在被动模式会工作在大于1024随机端口。FTP最权威的参考见RFC 959，有兴趣的朋友可以仔细阅读 ftp://nic.merit.edu/documents/rfc/rfc0959.txt的文档了解FTP详细工作模式和命令。目前主流的FTP
Server服务器模式都是同时支持port和pasv两种方式，但是为了方便管理安全管理防火墙和设置ACL了解FTP Server的port和pasv模式是很有必要的。

1.1 ftp port模式（主动模式）
       主动方式的FTP是这样的：客户端从一个任意的非特权端口N（N>1024）连接到FTP服务器的命令端口(即tcp 21端口)。紧接着客户端开始监听端口N+1，并发送FTP命令“port N+1”到FTP服务器。最后服务器会从它自己的数据端口（20）连接到客户端指定的数据端口（N+1），这样客户端就可以和ftp服务器建立数据传输通道了。ftp port模式工作流程如下图所示：

针对FTP服务器前面的防火墙来说，必须允许以下通讯才能支持主动方式FTP：
1、客户端口>1024端口到FTP服务器的21端口 （入：客户端初始化的连接 S<-C）
2、FTP服务器的21端口到客户端>1024的端口（出：服务器响应客户端的控制端口 S->C） 
3、FTP服务器的20端口到客户端>1024的端口（出:服务器端初始化数据连接到客户端的数据端口 S->C）
4、客户端>1024端口到FTP服务器的20端口（入：客户端发送ACK响应到服务器的数据端口 S<-C）

1.2 ftp pasv模式（被动模式）
       在被动方式FTP中，命令连接和数据连接都由客户端。当开启一个FTP连接时，客户端打开两个任意的非特权本地端口（N > 1024和N+1）。第一个端口连接服务器的21端口，但与主动方式的FTP不同，客户端不会提交PORT命令并允许服务器来回连它的数据端口，而是提交 PASV命令。这样做的结果是服务器会开启一个任意的非特权端口（P > 1024），并发送PORT P命令给客户端。然后客户端发起从本地端口N+1到服务器的端口P的连接用来传送数据。ftp pasv模式工作流程如下图所示： 

对于服务器端的防火墙来说，必须允许下面的通讯才能支持被动方式的FTP: 
1、客户端>1024端口到服务器的21端口 （入：客户端初始化的连接 S<-C） 
2、服务器的21端口到客户端>1024的端口 （出：服务器响应到客户端的控制端口的连接 S->C） 
3、客户端>1024端口到服务器的大于1024端口 （入：客户端初始化数据连接到服务器指定的任意端口 S<-C） 
4、服务器的大于1024端口到远程的大于1024的端口（出：服务器发送ACK响应和数据到客户端的数据端口 S->C）

memcached协议

旧版： http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt

新版： https://github.com/memcached/memcached/blob/master/doc/protocol.txt

一、协议

        memcached的客户端使用TCP连接同memcached进行交互，memcached服务器监听指定的端口(默认端口是11211)。Client连接到memcached服务器，发送指令，获取数据，然后关闭连接。

        通常没有必要发送任何命令来关闭某个会话。客户端可以在任何时候关闭不需要的连接。然而，通常鼓励客户端缓存这些连接，因为memcached服务器本身就被设计成为一个可以支持成百上千个连接的服务器，而客户端缓存了连接后，就可以避免重复的建立连接的开销。

        memcached协议中包含两部分数据，文本行和非结构化数据。前者是来自客户端的命令或来自服务器端的响应，后者代表客户端存取的数据。命令以\r\n结尾，数据可以是\r，\n或者\r\n结尾来标识各自部分的结束。

二、键

        memcached一般通过key来存储，一个key的长度一般不能超过250字符。key不能包含控制字符或空白字符

三、命令

有三种类型的命令：

    1、存储命令：set、add、replace、append、prepend、cas

    2、读取命令：get、gets

    3、第三种命令，不涉及到非结构化数据。客户端发出这样的命令，服务端会返回响应结果

1、过期时间

        过期时间的取值，有两种：一种是Unix时间(自1970.1.1开始到现在的秒数)，另一种是相对当前时间的秒数。如果过期时间的秒数大于60*60*24*30(即30天)，则服务端认为是Unix时间。

2、错误设置

        客户端发出的每个命令，服务端可能会返回错误提示字符。错误提示字符有如下三种：

      1)  ERROR\r\n ：表示客户端发送的命令不存在

      2)  CLIENT_ERROR <error>\r\n ：表示客户端的输入有错误

      3)  SERVER_ERROR <error>\r\n ：服务器端的错误

3、存储命令：

命令格式：<command name> <key><flags> <exptime> <bytes> [noreply]\r\n

命令名：如set、add、replace、append、prepend

flags：一个任意的32位(旧版本是16位)无符号整数

exptime：过期时间，如果为0，表示永不过期。单位秒

bytes：表示将要存储的数据的字节数，可以为0。要存储的内容的字节数，必须等于该值，不能大于也不能小于。

例子：将一个整数12，存放到memcache中，key为var，flags为1，过期时间为1000，字节数为2

用telnet连接memcached服务器端：

输入命令如下：set var 1 1000 2，然后按回车，之后输入要存储是数据：12，按回车，服务器返回STORED，如下：

通过get命令查看刚才存储的内容：

4、获取命令

格式：

      get  <key>*\r\n

      gets <key>*\r\n

<key>*，表示可以有多个key，各个key之间用空格隔开。

执行该命令，服务器返回0个或多个item，每个item的格式如下：

      VALUE <key> <flags><bytes> [<cas unique>]\r\n

      <data block>\r\n

bytes为数据内容的长度，data block为key对应的数据内容

例子：

5、删除命令

格式： delete <key> [noreply]\r\n

noreply参数，告诉服务器不用发送响应

该命令的返回结果，可能是：

       DELETE\r\n       表示删除成功

       NOT_FOUND\r\n   没有对应的key

例子：

6、增加/减少命令

命令格式：

       incr <key> <value> [noreply]\r\n   或   decr <key> <value> [noreply]\r\n

value为要增加或减少的值。

操作成功，服务器返回操作之后的值。

对于decr操作，如果操作之后的值小于0，则置为0

不能直接使用incr和decr，必须先set或者add后再使用，而且值为数字类型，在增加时，存储的区域会扩展。

例子：

7、touch

该命令用来更新已存在的item的过期时间，格式如下：(低版本不支持该命令)

      touch <key> <exptime> [noreply]\r\n

执行该命令后，如果返回”TOUCHED\r\n”，则执行成功

8、统计命令

命令格式：

    1)    stats\r\n         查看通用的统计信息

    2)    stats <args>\r\n

通用统计信息，例子：

具体含义：

9、item统计信息

stats命令后面带上参数：items。  返回存储在每个slab的item信息，格式如下：

       STAT items:<slabclass>:<stat><value>\r\n

例子：

10、itemsize统计信息

stats命令后面带上参数sizes，返回存储在cache中的总体大小及item数目。

注意：该命令会锁住cache，它会遍历每个item并计算大小，在此之间，我们是无法访问server的，因此要慎重使用该命令。

返回结果的格式如下：

     <size> <count>\r\n

其中：

     'size' is an approximate size of the item,within 32 bytes.

     'count' is the amount of items that existwithin that 32-byte range.

例子：

11、slab统计信息

stats命令带上参数slabs，返回memcached运行期间创建的每个slab的信息。

数据格式：STAT <slabclass>:<stat> <value>\r\n

例子：

item存放在slab中，该slab的大小大于或等于该item的大小。mem_requested表示一个slab中所有item的大小。

total_chunks * chunk_size – mem_requested，表示一个slab中所浪费的内存大小。如果有很多浪费，则需要考虑调整slab因子

12、其他命令

     1)   flush_all ：执行该命令，将导致memcache中所存在的所有item都失效。也可以指定在一段时间之后失效。例子：

    2)   version ： 查看memcache的版本号

    3）quit ：关闭连接

最近准备自己根据raphael学习和网上查阅到得知识，实现一个jbpm4风格的web流程设计器。有部分功能参考了CSDN网友 wow4464提供的一个控件连线的实例，下载地址： http://download.csdn.net/detail/wow4464/7549803。

连线的方式使用的是raphael拖拽的特性来实现的，发现在firefox下有问题，其他浏览器正常支持。除了raphael和jquery的javascript库之外，没有借助于任何第三方的库函数或插件。源码见附件。

一、    控制hive任务中的map数: 

1.    通常情况下，作业会通过input的目录产生一个或者多个map任务。 
主要的决定因素有： input的文件总个数，input的文件大小，集群设置的文件块大小(目前为128M, 可在hive中通过set dfs.block.size;命令查看到，该参数不能自定义修改)；

2.    举例： 
a)    假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块（6个128m的块和1个12m的块），从而产生7个map数
b)    假设input目录下有3个文件a,b,c,大小分别为10m，20m，130m，那么hadoop会分隔成4个块（10m,20m,128m,2m）,从而产生4个map数
即，如果文件大于块大小(128m),那么会拆分，如果小于块大小，则把该文件当成一个块。

3.    是不是map数越多越好？ 
答案是否定的。如果一个任务有很多小文件（远远小于块大小128m）,则每个小文件也会被当做一个块，用一个map任务来完成，
而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。
而且，同时可执行的map数是受限的。

4.    是不是保证每个map处理接近128m的文件块，就高枕无忧了？ 
答案也是不一定。比如有一个127m的文件，正常会用一个map去完成，但这个文件只有一个或者两个小字段，却有几千万的记录，
如果map处理的逻辑比较复杂，用一个map任务去做，肯定也比较耗时。

针对上面的问题3和4，我们需要采取两种方式来解决：即减少map数和增加map数；

如何合并小文件，减少map数？ 
    假设一个SQL任务：
         Select count(1) from popt_tbaccountcopy_mes where pt = ‘2012-07-04’;
         该任务的inputdir  /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04
         共有194个文件，其中很多是远远小于128m的小文件，总大小9G，正常执行会用194个map任务。
         Map总共消耗的计算资源： SLOTS_MILLIS_MAPS= 623,020

         我通过以下方法来在map执行前合并小文件，减少map数：

         set mapred.max.split.size= 8000000000000 ;
                    set mapred.min.split.size.per.node= 8000000000000 ;
                    set mapred.min.split.size.per.rack= 8000000000000 ;
                    set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
                 再执行上面的语句，用了74个map任务，map消耗的计算资源：SLOTS_MILLIS_MAPS= 333,500
         对于这个简单SQL任务，执行时间上可能差不多，但节省了一半的计算资源。
         大概解释一下，100000000表示100M, set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;这个参数表示执行前进行小文件合并，
         前面三个参数确定合并文件块的大小，大于文件块大小128m的，按照128m来分隔，小于128m,大于100m的，按照100m来分隔，把那些小于100m的（包括小文件和分隔大文件剩下的），
         进行合并,最终生成了74个块。
         
如何适当的增加map数？ 

         当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加Map数，来使得每个map处理的数据量减少，从而提高任务的执行效率。
         假设有这样一个任务：
         Select data_desc,
                count(1),
                count(distinct id),
                sum(case when …),
                sum(case when ...),
                sum(…)
        from a group by data_desc
                   如果表a只有一个文件，大小为120M，但包含几千万的记录，如果用1个map去完成这个任务，肯定是比较耗时的，这种情况下，我们要考虑将这一个文件合理的拆分成多个，
                   这样就可以用多个map任务去完成。
                   set mapred.reduce.tasks=10;
                   create table a_1 as 
                   select * from a 
                   distribute by rand(123); 
                   
                   这样会将a表的记录，随机的分散到包含10个文件的a_1表中，再用a_1代替上面sql中的a表，则会用10个map任务去完成。
                   每个map任务处理大于12M（几百万记录）的数据，效率肯定会好很多。
    
   看上去，貌似这两种有些矛盾，一个是要合并小文件，一个是要把大文件拆成小文件，这点正是重点需要关注的地方，
   根据实际情况，控制map数量需要遵循两个原则：使大数据量利用合适的map数；使单个map任务处理合适的数据量；

二、    控制hive任务的reduce数： 

1.    Hive自己如何确定reduce数： 
reduce个数的设定极大影响任务执行效率，不指定reduce个数的情况下，Hive会猜测确定一个reduce个数，基于以下两个设定：
hive.exec.reducers.bytes.per.reducer（每个reduce任务处理的数据量，默认为1000^3=1G） 
hive.exec.reducers.max（每个任务最大的reduce数，默认为999）
计算reducer数的公式很简单N=min(参数2，总输入数据量/参数1)
即，如果reduce的输入（map的输出）总大小不超过1G,那么只会有一个reduce任务；
如：select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt; 
            /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04 总大小为9G多，因此这句有10个reduce

2.    调整reduce个数方法一： 
调整hive.exec.reducers.bytes.per.reducer参数的值；
set hive.exec.reducers.bytes.per.reducer=500000000; （500M）
select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt; 这次有20个reduce
         
3.    调整reduce个数方法二； 
set mapred.reduce.tasks = 15;
select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt;这次有15个reduce

4.    reduce个数并不是越多越好； 
同map一样，启动和初始化reduce也会消耗时间和资源；
另外，有多少个reduce,就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；

5.    什么情况下只有一个reduce； 
很多时候你会发现任务中不管数据量多大，不管你有没有设置调整reduce个数的参数，任务中一直都只有一个reduce任务；
其实只有一个reduce任务的情况，除了数据量小于hive.exec.reducers.bytes.per.reducer参数值的情况外，还有以下原因：
a)    没有group by的汇总，比如把select pt,count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04' group by pt; 写成 select count(1) from popt_tbaccountcopy_mes where pt = '2012-07-04';
这点非常常见，希望大家尽量改写。
b)    用了Order by
c)    有笛卡尔积
通常这些情况下，除了找办法来变通和避免，我暂时没有什么好的办法，因为这些操作都是全局的，所以hadoop不得不用一个reduce去完成；

    同样的，在设置reduce个数的时候也需要考虑这两个原则：使大数据量利用合适的reduce数；使单个reduce任务处理合适的数据量；

第一部分 Shiro构架介绍

一、什么是Shiro 

Apache Shiro是一个强大易用的Java安全框架，提供了认证、授权、加密和会话管理等功能： 

• 认证 - 用户身份识别，常被称为用户“登录”；
• 授权 - 访问控制；
• 密码加密 - 保护或隐藏数据防止被偷窥；
• 会话管理 - 每用户相关的时间敏感的状态。

      对于任何一个应用程序，Shiro都可以提供全面的安全管理服务。并且相对于其他安全框架，Shiro要简单的多。

二、Shiro的架构介绍 
首先，来了解一下Shiro的三个核心组件：Subject, SecurityManager 和 Realms. 如下图： 

Subject：即“当前操作用户”。但是，在Shiro中，Subject这一概念并不仅仅指人，也可以是第三方进程、后台帐户（Daemon Account）或其他类似事物。它仅仅意味着“当前跟软件交互的东西”。但考虑到大多数目的和用途，你可以把它认为是Shiro的“用户”概念。 Subject代表了当前用户的安全操作，SecurityManager则管理所有用户的安全操作。 

SecurityManager：它是Shiro框架的核心，典型的Facade模式，Shiro通过SecurityManager来管理内部组件实例，并通过它来提供安全管理的各种服务。 

Realm： Realm充当了Shiro与应用安全数据间的“桥梁”或者“连接器”。也就是说，当对用户执行认证（登录）和授权（访问控制）验证时，Shiro会从应用配置的Realm中查找用户及其权限信息。 
从这个意义上讲，Realm实质上是一个安全相关的DAO：它封装了数据源的连接细节，并在需要时将相关数据提供给Shiro。当配置Shiro时，你必须至少指定一个Realm，用于认证和（或）授权。配置多个Realm是可以的，但是至少需要一个。

    Shiro内置了可以连接大量安全数据源（又名目录）的Realm，如LDAP、关系数据库（JDBC）、类似INI的文本配置资源以及属性文件等。如果缺省的Realm不能满足需求，你还可以插入代表自定义数据源的自己的Realm实现。

Shiro完整架构图： 

除前文所讲Subject、SecurityManager 、Realm三个核心组件外，Shiro主要组件还包括： 
Authenticator ：认证就是核实用户身份的过程。这个过程的常见例子是大家都熟悉的“用户/密码”组合。多数用户在登录软件系统时，通常提供自己的用户名（当事人）和支持他们的密码（证书）。如果存储在系统中的密码（或密码表示）与用户提供的匹配，他们就被认为通过认证。 

Authorizer ：授权实质上就是访问控制 - 控制用户能够访问应用中的哪些内容，比如资源、Web页面等等。 

SessionManager ：在安全框架领域，Apache Shiro提供了一些独特的东西：可在任何应用或架构层一致地使用Session API。即，Shiro为任何应用提供了一个会话编程范式 - 从小型后台独立应用到大型集群Web应用。这意味着，那些希望使用会话的应用开发者，不必被迫使用Servlet或EJB容器了。或者，如果正在使用这些容器，开发者现在也可以选择使用在任何层统一一致的会话API，取代Servlet或EJB机制。 

CacheManager :对Shiro的其他组件提供缓存支持。

第二部分 Shiro认证

       认证就是验证用户身份的过程。在认证过程中，用户需要提交实体信息(Principals)和凭据信息(Credentials)以检验用户是否合法。最常见的“实体/凭证”组合便是“用户名/密码”组合。

一、Shiro认证过程 

1、收集实体/凭据信息 

//Example using most common scenario of username/password pair:
UsernamePasswordToken token = new UsernamePasswordToken(username, password);
//”Remember Me” built-in:
token.setRememberMe(true);

UsernamePasswordToken支持最常见的用户名/密码的认证机制。同时，由于它实现了RememberMeAuthenticationToken接口，我们可以通过令牌设置“记住我”的功能。 

但是，“已记住”和“已认证”是有区别的： 
已记住的用户仅仅是非匿名用户，你可以通过subject.getPrincipals()获取用户信息。但是它并非是完全认证通过的用户，当你访问需要认证用户的功能时，你仍然需要重新提交认证信息。 
这一区别可以参考亚马逊网站，网站会默认记住登录的用户，再次访问网站时，对于非敏感的页面功能，页面上会显示记住的用户信息，但是当你访问网站账户信息时仍然需要再次进行登录认证。 

2、提交实体/凭据信息 

Subject currentUser = SecurityUtils.getSubject();
currentUser.login(token);

3、认证处理 

try {
    currentUser.login(token);
} catch ( UnknownAccountException uae ) { ...
} catch ( IncorrectCredentialsException ice ) { ...
} catch ( LockedAccountException lae ) { ...
} catch ( ExcessiveAttemptsException eae ) { ...
} ... catch your own ...
} catch ( AuthenticationException ae ) {
    //unexpected error?
}

二、登出操作 
登出操作可以通过调用subject.logout()来删除你的登录信息，如：

currentUser.logout(); //removes all identifying information and invalidates their session too.

三、认证内部处理机制 

以上，是Shiro认证在应用程序中的处理过程，下面将详细解说Shiro认证的内部处理机制。

如上图，我们通过Shiro架构图的认证部分，来说明Shiro认证内部的处理顺序： 
1、应用程序构建了一个终端用户认证信息的AuthenticationToken 实例后，调用Subject.login方法。 
2、Sbuject的实例通常是DelegatingSubject类（或子类）的实例对象，在认证开始时，会委托应用程序设置的securityManager实例调用securityManager.login(token)方法。 
3、SecurityManager接受到token(令牌)信息后会委托内置的Authenticator的实例（通常都是ModularRealmAuthenticator类的实例）调用authenticator.authenticate(token). ModularRealmAuthenticator在认证过程中会对设置的一个或多个Realm实例进行适配，它实际上为Shiro提供了一个可拔插的认证机制。 
4、如果在应用程序中配置了多个Realm，ModularRealmAuthenticator会根据配置的AuthenticationStrategy(认证策略)来进行多Realm的认证过程。在Realm被调用后，AuthenticationStrategy将对每一个Realm的结果作出响应。 
注：如果应用程序中仅配置了一个Realm，Realm将被直接调用而无需再配置认证策略。 
5、判断每一个Realm是否支持提交的token，如果支持，Realm将调用getAuthenticationInfo(token); getAuthenticationInfo 方法就是实际认证处理，我们通过覆盖Realm的doGetAuthenticationInfo方法来编写我们自定义的认证处理。 

四、使用多个Realm的处理机制： 

1、Authenticator 
默认实现是ModularRealmAuthenticator,它既支持单一Realm也支持多个Realm。如果仅配置了一个Realm，ModularRealmAuthenticator 会直接调用该Realm处理认证信息，如果配置了多个Realm，它会根据认证策略来适配Realm，找到合适的Realm执行认证信息。 
自定义Authenticator的配置： 

[main]
...
authenticator = com.foo.bar.CustomAuthenticator
securityManager.authenticator = $authenticator

2、AuthenticationStrategy（认证策略） 

• 在所有Realm被调用之前
• 在调用Realm的getAuthenticationInfo 方法之前
• 在调用Realm的getAuthenticationInfo 方法之后
• 在所有Realm被调用之后

Shiro有3中认证策略的具体实现： 

ModularRealmAuthenticator 内置的认证策略默认实现是AtLeastOneSuccessfulStrategy 方式，因为这种方式也是被广泛使用的一种认证策略。当然，你也可以通过配置文件定义你需要的策略，如：

[main]
...
authcStrategy = org.apache.shiro.authc.pam.FirstSuccessfulStrategy
securityManager.authenticator.authenticationStrategy = $authcStrategy
...

因此，如果Realm的顺序对你使用的认证策略结果有影响，那么你应该在配置文件中明确定义Realm的顺序，如：  

blahRealm = com.company.blah.Realm
...
fooRealm = com.company.foo.Realm
...
barRealm = com.company.another.Realm

securityManager.realms = $fooRealm, $barRealm, $blahRealm

第三部分 Shiro授权

授权即访问控制，它将判断用户在应用程序中对资源是否拥有相应的访问权限。 
如，判断一个用户有查看页面的权限，编辑数据的权限，拥有某一按钮的权限，以及是否拥有打印的权限等等。

一、授权的三要素 

授权有着三个核心元素：权限、角色和用户。 

权限 
权限是Apache Shiro安全机制最核心的元素。它在应用程序中明确声明了被允许的行为和表现。一个格式良好好的权限声明可以清晰表达出用户对该资源拥有的权限。 
大多数的资源会支持典型的CRUD操作（create,read,update,delete）,但是任何操作建立在特定的资源上才是有意义的。因此，权限声明的根本思想就是建立在资源以及操作上。 
而我们通过权限声明仅仅能了解这个权限可以在应用程序中做些什么，而不能确定谁拥有此权限。 
于是，我们就需要在应用程序中对用户和权限建立关联。 
通常的做法就是将权限分配给某个角色，然后将这个角色关联一个或多个用户。 

权限声明及粒度 
Shiro权限声明通常是使用以冒号分隔的表达式。就像前文所讲，一个权限表达式可以清晰的指定资源类型，允许的操作，可访问的数据。同时，Shiro权限表达式支持简单的通配符，可以更加灵活的进行权限设置。 
下面以实例来说明权限表达式。 
可查询用户数据 
User:view 
可查询或编辑用户数据 
User:view,edit 
可对用户数据进行所有操作 
User:* 或 user 
可编辑id为123的用户数据 
User:edit:123 

角色 
Shiro支持两种角色模式： 
1、传统角色：一个角色代表着一系列的操作，当需要对某一操作进行授权验证时，只需判断是否是该角色即可。这种角色权限相对简单、模糊，不利于扩展。 
2、权限角色：一个角色拥有一个权限的集合。授权验证时，需要判断当前角色是否拥有该权限。这种角色权限可以对该角色进行详细的权限描述，适合更复杂的权限设计。 
下面将详细描述对两种角色模式的授权实现。 

二、授权实现 

Shiro支持三种方式实现授权过程： 

• 编码实现
• 注解实现
• JSP Taglig实现

1、基于编码的授权实现 

1.1  基于传统角色授权实现 

当需要验证用户是否拥有某个角色时，可以调用Subject 实例的hasRole*方法验证。 

Subject currentUser = SecurityUtils.getSubject();
if (currentUser.hasRole("administrator")) {
    //show the admin button
} else {
    //don't show the button?  Grey it out?
}

相关验证方法如下： 

断言支持 
Shiro还支持以断言的方式进行授权验证。断言成功，不返回任何值，程序继续执行；断言失败时，将抛出异常信息。使用断言，可以使我们的代码更加简洁。 

Subject currentUser = SecurityUtils.getSubject();
//guarantee that the current user is a bank teller and
//therefore allowed to open the account:
currentUser.checkRole("bankTeller");
openBankAccount();

断言的相关方法： 

1.2 基于权限角色授权实现 
相比传统角色模式，基于权限的角色模式耦合性要更低些，它不会因角色的改变而对源代码进行修改，因此，基于权限的角色模式是更好的访问控制方式。 
它的代码实现有以下几种实现方式： 

1、基于权限对象的实现 
创建org.apache.shiro.authz.Permission的实例，将该实例对象作为参数传递给Subject.isPermitted（）进行验证。 

Permission printPermission = new PrinterPermission("laserjet4400n", "print");
Subject currentUser = SecurityUtils.getSubject();
if (currentUser.isPermitted(printPermission)) {
    //show the Print button
} else {
    //don't show the button?  Grey it out?
}
Permission printPermission = new PrinterPermission("laserjet4400n", "print");
Subject currentUser = SecurityUtils.getSubject();
if (currentUser.isPermitted(printPermission)) {
    //show the Print button
} else {
    //don't show the button?  Grey it out?
}

相关方法如下： 

2、 基于字符串的实现 
相比笨重的基于对象的实现方式，基于字符串的实现便显得更加简洁。 

Subject currentUser = SecurityUtils.getSubject();
if (currentUser.isPermitted("printer:print:laserjet4400n")) {
    //show the Print button
} else {
    //don't show the button?  Grey it out?
}

使用冒号分隔的权限表达式是org.apache.shiro.authz.permission.WildcardPermission 默认支持的实现方式。 
这里分别代表了 资源类型：操作：资源ID 

类似基于对象的实现相关方法，基于字符串的实现相关方法： 
isPermitted(String perm)、isPermitted(String... perms)、isPermittedAll(String... perms) 

基于权限对象的断言实现 

Subject currentUser = SecurityUtils.getSubject();
//guarantee that the current user is permitted
//to open a bank account:
Permission p = new AccountPermission("open");
currentUser.checkPermission(p);
openBankAccount();

基于字符串的断言实现 

Subject currentUser = SecurityUtils.getSubject();
//guarantee that the current user is permitted
//to open a bank account:
currentUser.checkPermission("account:open");
openBankAccount();

断言实现的相关方法 

2、基于注解的授权实现 

Shiro注解支持AspectJ、Spring、Google-Guice等，可根据应用进行不同的配置。 

相关的注解： 
@ RequiresAuthentication 
可以用户类/属性/方法，用于表明当前用户需是经过认证的用户。 

@RequiresAuthentication
public void updateAccount(Account userAccount) {
    //this method will only be invoked by a 
    //Subject that is guaranteed authenticated
    ...
}

@ RequiresGuest 
表明该用户需为”guest”用户 

@ RequiresPermissions 
当前用户需拥有制定权限 

@RequiresPermissions("account:create")
public void createAccount(Account account) {
    //this method will only be invoked by a Subject
    //that is permitted to create an account
    ...
}

@RequiresRoles 
当前用户需拥有制定角色 

@ RequiresUser 
当前用户需为已认证用户或已记住用户 

3、基于JSP  TAG的授权实现 
Shiro提供了一套JSP标签库来实现页面级的授权控制。 
在使用Shiro标签库前，首先需要在JSP引入shiro标签： 

<%@ taglib prefix="shiro" uri="http://shiro.apache.org/tags" %>

下面一一介绍Shiro的标签： 
guest标签 
验证当前用户是否为“访客”，即未认证（包含未记住）的用户 

<shiro:guest>
    Hi there!  Please <a href="login.jsp">Login</a> or <a href="signup.jsp">Signup</a> today!</shiro:guest>

user标签 
认证通过或已记住的用户

<shiro:user>
    Welcome back John!  Not John? Click <a href="login.jsp">here<a> to login.</shiro:user>

 
 authenticated标签 

<shiro:authenticated><a href="updateAccount.jsp">Update your contact information</a>.</shiro:authenticated>

notAuthenticated标签 
未认证通过用户，与authenticated标签相对应。与guest标签的区别是，该标签包含已记住用户。 

<shiro:notAuthenticated>
    Please <a href="login.jsp">login</a> in order to update your credit card information.</shiro:notAuthenticated>

principal 标签 
输出当前用户信息，通常为登录帐号信息 

Hello, <shiro:principal/>, how are you today?

hasRole标签 
验证当前用户是否属于该角色 

<shiro:hasRole name="administrator"><a href="admin.jsp">Administer the system</a></shiro:hasRole>

lacksRole标签 
与hasRole标签逻辑相反，当用户不属于该角色时验证通过 

<shiro:lacksRole name="administrator">
    Sorry, you are not allowed to administer the system.</shiro:lacksRole>

hasAnyRole标签 
验证当前用户是否属于以下任意一个角色。 

<shiro:hasAnyRoles name="developer, project manager, administrator">
    You are either a developer, project manager, or administrator.</shiro:lacksRole>

hasPermission标签 
验证当前用户是否拥有制定权限 

<shiro:hasPermission name="user:create"><a href="createUser.jsp">Create a new User</a></shiro:hasPermission>

lacksPermission标签 
与hasPermission标签逻辑相反，当前用户没有制定权限时，验证通过  

<shiro:hasPermission name="user:create"><a href="createUser.jsp">Create a new User</a></shiro:hasPermission>

三、Shiro授权的内部处理机制 
 
1、在应用程序中调用授权验证方法(Subject的isPermitted*或hasRole*等) 
2、Sbuject的实例通常是DelegatingSubject类（或子类）的实例对象，在认证开始时，会委托应用程序设置的securityManager实例调用相应的isPermitted*或hasRole*方法。 
3、接下来SecurityManager会委托内置的Authorizer的实例（默认是ModularRealmAuthorizer 类的实例，类似认证实例，它同样支持一个或多个Realm实例认证）调用相应的授权方法。 
4、每一个Realm将检查是否实现了相同的 Authorizer 接口。然后，将调用Reaml自己的相应的授权验证方法。 

当使用多个Realm时，不同于认证策略处理方式，授权处理过程中： 
1、当调用Realm出现异常时，将立即抛出异常，结束授权验证。 
2、只要有一个Realm验证成功，那么将认为授权成功，立即返回，结束认证。 

第四部分 Ralm的实现

在认证、授权内部实现机制中都有提到，最终处理都将交给Real进行处理。因为在Shiro中，最终是通过Realm来获取应用程序中的用户、角色及权限信息的。通常情况下，在Realm中会直接从我们的数据源中获取Shiro需要的验证信息。可以说，Realm是专用于安全框架的DAO. 

一、认证实现 
正如前文所提到的，Shiro的认证过程最终会交由Realm执行，这时会调用Realm的getAuthenticationInfo(token)方法。 
该方法主要执行以下操作: 
1、检查提交的进行认证的令牌信息 
2、根据令牌信息从数据源(通常为数据库)中获取用户信息 
3、对用户信息进行匹配验证。 
4、验证通过将返回一个封装了用户信息的AuthenticationInfo实例。 
5、验证失败则抛出AuthenticationException异常信息。 

而在我们的应用程序中要做的就是自定义一个Realm类，继承AuthorizingRealm抽象类，重载doGetAuthenticationInfo ()，重写获取用户信息的方法。 

protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken authcToken) throws AuthenticationException {
		UsernamePasswordToken token = (UsernamePasswordToken) authcToken;
		User user = accountManager.findUserByUserName(token.getUsername());
		if (user != null) {
			return new SimpleAuthenticationInfo(user.getUserName(), user.getPassword(), getName());
		} else {
			return null;
		}
}

  二、授权实现 

protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
		String userName = (String) principals.fromRealm(getName()).iterator().next();
		User user = accountManager.findUserByUserName(userName);
		if (user != null) {
			SimpleAuthorizationInfo info = new SimpleAuthorizationInfo();
			for (Group group : user.getGroupList()) {
				info.addStringPermissions(group.getPermissionList());
			}
			return info;
		} else {
			return null;
		}
}

 第五部分 Shiro配置说明

Apache Shiro的配置主要分为四部分： 

• 对象和属性的定义与配置
• URL的过滤器配置
• 静态用户配置
• 静态角色配置

其中，由于用户、角色一般由后台进行操作的动态数据，因此Shiro配置一般仅包含前两项的配置。 

Apache Shiro的大多数组件是基于POJO的，因此我们可以使用POJO兼容的任何配置机制进行配置，例如：Java代码、Sping XML、YAML、JSON、ini文件等等。下面，以Spring XML的配置方式为例，并且对其中的一些配置参数进行一些简单说明。 

Shiro对象的配置： 
主要是对Shiro各个组件的实现进行定义配置，主要组件在前文已做过简单介绍，这里不再一一说明。

<bean id="securityManager" class="org.apache.shiro.mgt.DefaultSecurityManager"><property name="cacheManager" ref="cacheManager"/><property name="sessionMode" value="native"/><!-- Single realm app.  If you have multiple realms, use the 'realms' property instead. --><property name="realm" ref="myRealm"/><property name="sessionManager" ref="sessionManager"/> </bean>

  Shiro过滤器的配置 

<bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean"><property name="securityManager" ref="securityManager"/><property name="loginUrl" value="/login.jsp"/><property name="successUrl" value="/home.jsp"/><property name="unauthorizedUrl" value="/unauthorized.jsp"/> --><property name="filterChainDefinitions"><value>
            # some example chain definitions:
            /admin/** = authc, roles[admin]
            /docs/** = authc, perms[document:read]
            /** = authc
            # more URL-to-FilterChain definitions here</value></property></bean>

URL过滤器配置说明： 
Shiro可以通过配置文件实现基于URL的授权验证。FilterChain定义格式： 
URL_Ant_Path_Expression = Path_Specific_Filter_Chain 
每个URL配置，表示匹配该URL的应用程序请求将由对应的过滤器进行验证。 
例如： 
[urls] 
/index.html = anon 
/user/create = anon 
/user/** = authc 
/admin/** = authc, roles[administrator] 
/rest/** = authc, rest 
/remoting/rpc/** = authc, perms["remote:invoke"] 

URL表达式说明 
1、URL目录是基于HttpServletRequest.getContextPath()此目录设置 
2、URL可使用通配符，**代表任意子目录 
3、Shiro验证URL时，URL匹配成功便不再继续匹配查找。所以要注意配置文件中的URL顺序，尤其在使用通配符时。 

Filter Chain定义说明 
1、一个URL可以配置多个Filter，使用逗号分隔 
2、当设置多个过滤器时，全部验证通过，才视为通过 
3、部分过滤器可指定参数，如perms，roles 

Shiro内置的FilterChain 

本文转载自kdboy的博客的系列文章，文章地址为： http://kdboy.iteye.com/blog/1154644

get和load方式是根据id取得一个记录
下边详细说一下get和load的不同，因为有些时候为了对比也会把find加进来。

1.从返回结果上对比：
load方式检索不到的话会抛出org.hibernate.ObjectNotFoundException异常
get方法检索不到的话会返回null

2.从检索执行机制上对比：
get方法和find方法都是直接从数据库中检索
而load方法的执行则比较复杂
■ 首先查找session的persistent Context中是否有缓存，如果有则直接返回
■ 如果没有则判断是否是lazy，如果不是直接访问数据库检索，查到记录返回，查不到抛出异常
■ 如果是lazy则需要建立代理对象，对象的initialized属性为false，target属性为null
■ 在访问获得的代理对象的属性时,检索数据库，如果找到记录则把该记录的对象复制到代理对象的target上，并将initialized=true，如果找不到就抛出异常。

3.根本区别说明
■ 如果你使用load方法，hibernate认为该id对应的对象（数据库记录）在数据库中是一定存在的，所以它可以放心的使用，它可以放心的使用代理来延迟加载该对象。在用到对象中的其他属性数据时才查询数据库，但是万一数据库中不存在该记录，那没办法，只能抛异常。所说的load方法抛异常是指在使用该对象的数据时，数据库中不存在该数据时抛异常，而不是在创建这个对象时(注意：这就是由于“延迟加载”在作怪)。

由于session中的缓存对于hibernate来说是个相当廉价的资源，所以在load时会先查一下session缓存看看该id对应的对象是否存在，不存在则创建代理。所以如果你知道该id在数据库中一定有对应记录存在就可以使用load方法来实现延迟加载。

■ 对于get方法，hibernate会确认一下该id对应的数据是否存在，首先在session缓存中查找，然后在二级缓存中查找，还没有就查数据库，数据库中没有就返回null。

对于load和get方法返回类型：虽然好多书中都这么说：“get()永远只返回实体类”，但实际上这是不正确的，get方法如果在 session缓存中找到了该id对应的对象，如果刚好该对象前面是被代理过的，如被load方法使用过，或者被其他关联对象延迟加载过，那么返回的还是原先的代理对象，而不是实体类对象，如果该代理对象还没有加载实体数据（就是id以外的其他属性数据），那么它会查询二级缓存或者数据库来加载数据，但是返回的还是代理对象，只不过已经加载了实体数据。

get方法首先查询session缓存，没有的话查询二级缓存，最后查询数据库；反而load方法创建时首先查询session缓存，没有就创建代理，实际使用数据时才查询二级缓存和数据库。

4.简单总结

总之对于get和load的根本区别，一句话，hibernate对于load方法认为该数据在数据库中一定存在，可以放心的使用代理来延迟加载，如果在使用过程中发现了问题，只能抛异常；而对于get方法，hibernate一定要获取到真实的数据，否则返回null。