也参与了项目数据库的选择以及对数据库的设计，选择得当的持久层框架，之前常用的数据库有关系型数据库oracle、 mysql，非关系数据库Mongodb、redis等，特殊是redis除了利用外我也做过一些其他的研究，比如说它作为缓存技能的利用、nginx和tomcat以及redis的集议论况搭建等。
考虑到开拓项目的高效性，也利用了一些常用的主流java技能，如webservice、httpclient、jsonp、dubbo+zookeeper等技能框架，还有POI导入导出技能、ECharts报表技能等。为了向干系职员定时发送关照，用到了Spring定时器和JavaMail邮件发送、短信发送技能，对项目进行测试利用junit技能。
利用过Eclipse、MyEclipse、Idea等开拓工具，为了方便项目的打包支配，还用到了maven进行干系jar包的依赖管理，同时利用业余韶光熟习了Linux操作系统。也能闇练利用powerdesigner数据库建模等工具的一些基本操作。
几年开拓，紧张涉及的行业项目包括电子商务、OA办公正台等。
接下来我给您大略先容一下我的上一个项目吧？
【项目一】欢快购商城电商系统1：项目简介
上个项目，我卖力的是一个电商项目叫欢快购购物商城，该商城是采取分布式架构支配的一个中小型网上购物商城系统。本系统分前台系统和后台管理系统。前台系统紧张卖力商城的页面的显示功能，这里采取的面向做事的办法，pc端手机端只卖力显示页面，业务逻辑都在做事层实现，客户端调用做事端接口来实现显示功能。
2：剖析
前台系统紧张有： 积分商城、商品展示、商品信息搜索框、购物车、商品秒杀、订单查询、浏览记录、商品排行、客服做事、留言评论、商品品牌展示、会员注册及登录等；
后台系统紧张有： 商品管理、用户管理、活动管理、订单管理、WMS（仓库管理系统）、财务管理、报表统计、系统管理、运营管理、店铺管理、支付管理、推广管理等
实在当时我紧张卖力的也挺多模块的，前台系统里面有购物车(redis)、商品信息搜索框(solr)、商品秒杀、留言评论(MongoDB)；后台系统这一块我紧张卖力WMS（仓库管理）、商品管理模块、统计剖析模块、推广管理模块、权限的管理、订单管理(拆单)、财务管理。
本系统前台界面设计采取的easyUI的设计，后台采取springMVC、spring、mybatis框架，maven管理的多模块项目，采取java措辞编程。
我在项目中除了紧张卖力的购物车模块和订单模块之外,对其它模块也是有一定的理解的.接下来我给大家先容一下.
3：详细实现
3.1：项目的搭建
这里采取maven多模块管理全体项目。上风两点：1、maven可以管理全体项目工程，方便热支配项目，项目发布方便。2、maven管理jar包具有很大的上风，可以自动下载所需的jar包，只需定义好版本即可，其他maven自动下载。
下面便是利用SSM框架来搭建工程了：利用框架搭建工程紧张分两步：框架所依赖的jar包，框架的配置文件。弄清了这两点就好办了。框架紧张分三层：mapper层（mybatis）（紧张是与数据库交互）、service层（spring）（紧张是卖力调用dao/mapper层，实现业务逻辑的编写）、controller层（springMVC）（这里紧张调用service层，根据jsp页面的内容，将jsp的内容通报到service层，然后将数据显示到jsp页面）。以是这里的配置文件也就有：spring将mybatis整合起来的spring-common.xml（配置数据源，与数据库的连接），其余配置了jdbc.properties（把链接数据库配置信息提取出来方便管理），spring-base.xml（将service的文件包引入工程，以及配置事务管理器），还有spring-mvc.xml（表明扫描，前端掌握器，视图解析器），还有log4j.properties（日志记录）。
框架搭建完成后，利用mybatis的逆向工程（generator）天生各个表的model文件。
3.2详细的功能的实现逻辑
（1）后台系统功能实现
（这里紧张讲商品的查询、添加）
实在对付功能模块的剖析紧张有三点：
从哪个数据表获取（紧张mapper实现）；页面通报是否有参数，页面的url是什么（controller实现）；返回值是什么（即页面展示的格式是什么样子的，这个根据jsp利用的框架来决定，比如这里的easyUI，可以查询它的api文档，找到其返回值类型）；
A、商品的查询逻辑剖析：实在对付商品的查询紧张便是从数据库中将所有商品查询出来。这大略的查询很大略，可是在页面分页显示出来这便是一个问题了。这里到了mybatis的分页插件pageHelper来实现。
传入参数：Easyui页面默认有page、rows参数通报。
返回值：easyui的格式即datagrid的格式，专门编写一个对应的pojo类放入专门工具类中利用，返回格式即这个pojo。
逻辑：mapper层：mapper层用mybatis的逆向工程
Service调用mapper的查询和分页实现逻辑。
Controller即将参数通报过去，url写好
B、商品添加：商品添加即将商品信息写入数据库，页面通报的内容当点击提交按钮时直接写入数据库，只需补全没有的字段即可。
这里涉及到商品的类目选择、上面的图片上传、商品的描述信息。
类目选择首先得将类目展示出来，这里利用的异步树的格式。查询api创造异步树的返回值的格式。紧张思路是：根据parentId来查询类目表，默认从0开始，异步树有个特点，便是每次获取到的id，如果有子节点，会发送url再次要求，如果没有子节点则不发送要求，以是可以都遍历到所有节点。（这个是tree的特点，自动要求）
异步树的特点：从最顶层开始读取，先读顶层节点，如果是闭合状态，发送要求给做事器读取子节点，子节点的状态依赖于父节点，当展开一个封闭的节点时，如果节点没有加载子节点，它将会把节点的id的值作为http要求参数并命名为id，通过url发送到做事器上检索子节点。以是遍历一次后，如果父节点还是父节点（即存在子节点）则检索下面的子节点的内容，将子节点的id作为parentId来检索下面的节点。如果不是父节点了，则打开下面列表。也便是说这些实现都是 异步树自动实现的，我们只须要判断父节点的状态即可，下面的检索根据这个状态进行。
图片上传功能：由于商城的图片非常多，以是我们将这么多的图片保存在图片做事器中，然后将图片在做事器中的详细url写入数据库，供前台调用。前台获取到这个url既可获取到这个图片。这里图片上传到做事器的功能：师长西席成图片的名称，然后天生图片保存的格式，然后利用ftpUtil将图片上传到做事器，返回一个url链接。
（2）前台功能实现
首页大广告位的实现：这里是从数据库中获取广告位的图片，然后展示在页面。但是前台跟后台是不一样的端口，如何从前台访问后台呢，可以利用jsonp的形式。但是我们这里系统是采取面向做事的编程，以是采取rest风格调用后台接口，这里用的dubbo+zookeeper来调用接口。
（3）SSO单点登录系统：
这里是利用了sso的接口文档，即校验接口、注册、登录接口、根据token查询用户接口、安全退出接口。
这个的调用做事层是利用jsonp的形式访问的做事接口，实现跨域访问。客户端全部在jsp页面实现的。
详细流程：
当用户点击注册的时候，跳转到注书页面，即用户信息的保存功能。考验用户名是否存在、手机号和邮箱不能为空。
当用户点击登录按钮的时候，用户输入用户名和密码，考验用户名是否在数据库中存在，然后用户名密码是否精确。这里的密码是用了spring的MD5加密技能。当全部成功后，给用户颁发一个token令牌（利用uuid实现），然后将token存入到redis中（token的key是它天生的号，值是用户的名字），然后设置在redis的过期韶光。这相称于用户的session。
然后将token写入cookie中，前台页面利用jsonp调用，根据cookie中的token的值，调用sso的根据token查询用户的做事，查看用户是否有效，如果有效则将用户返回前台页面，前台页面获取用户的用户名显示在首页，表示已上岸。
这里的cookie是设置了共享域，即全部子系统都可以访问到cookie。
当用户登录其他子系统时，先从从cookie中获取token信息，根据token信息获取用户信息，判断用户信息是否有效，如果有效则放行，如果无效，则利用拦截器拦截跳转到登录页面。用户再次登录的时候刷新redis的韶光，重新设置有效期。
（4）购物车功能：
将商品加入到购物车，当用户没有登录的时候，也可以将商品加入到购物车，是将商品信息加入到客户端浏览器的cookie当中，当用户点击加入购物车按钮的时候，会向后台提交一个要求把商品的ID和要加入的数量通报过去，首先获取到cookie当中购物车商品的信息，判断是否有商品，如果有，在根据商品ID和前台传入的商品ID进行比较，看是否有同一商品，如果有则直接在原有的数量少加上通报的数量即可，如果没有，则设置商品数量并将商品加入到list凑集当中，然后把list凑集转化为json数据放入cookie当中，并设置cookie的有效韶光，
cookie数据是存在客户端浏览器上，cookie也可以存放一些信息，用到的时候直接从cookie当中取，可以减轻做事器的压力。
利用cookie的好处：1、实现大略 ，2、不须要占用做事端存储空间。
缺陷:1、存储容量有限， 2、改换设备购车信息不能同步 3、Cookie禁用，不供应保存。
项目采取的是maven的多模块构建，各个模块之间调用就须要用到中间件，我们采取的是dubbo+zookeeper作为中间件，Dubbo是alibaba开源的分布式做事框架，它最大的优点可以使各层之间解耦，提高项目的拓展性，dubbo中有：Provider: 暴露做事的做事供应方。Consumer: 调用远程做事的做事消费方。Registry: 做事注册与创造的注册中央。Monitor: 统计做事的调用次数和调用韶光的监控中央。Container: 做事运行容器。做事容器卖力启动，加载，运行做事供应者，做事供应者在启动时，向注册中央注书籍身供应的做事，注册中央采取的是zookeeper，须要在配置文件中配置做事，分别有做事注册者名称，做事供应者的地址，暴露的端口号，以及供应做事的接口和实现类，做事消费者在启动时，向注册中央订阅自己所需的做事，注册中央返回做事供应者地址列表给消费者，做事消费者根据地址列表找到对应的做事供应者完成相应的调用。
当用户登录账号之后，会将cookie当中购物车中的商品同步到该账号中，把cookie当中的商品信息传入到后台，与原有的购物车中商品信息进行比对，有相同的商品的话直接在原有的数量上加上cookie中该商品的数量，如果没有则直接加入，购物车中的信息可以存放在数据库中也可以放在redis缓存中，这里采取了redis缓存，由于用户可能会频繁的更新购物车信息，如果将购物车商品数据放在数据库中的话会增加数据库的压力，以是采取了redis缓存，redis是一个高性能的key/value分布式内存数据库，基于内存运行，还支持数据的持久化，redis不仅仅支持大略的key/value类型的数据，同时还供应了String、list、set、zset、hash等数据构造的存储，还支持数据的备份，主从同步等。
redis供应了两种持久化办法，一种是rdb，一种是aof:RDB办法是一种快照式的持久化方法，将某一时候的数据持久化到磁盘中redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件更换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，由于快照文件总是完全可用的。对付RDB办法，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。如果须要进行大规模数据的规复，且对付数据规复的完全性不是非常敏感，那RDB办法要比AOF办法更加的高效。。aof：AOF办法是将实行过的写指令记录下来，在数据规复时按照丛前到后的顺序再将指令实行一遍。AOF命令以redis协议追加保存每次写的操作到文件末端.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），由于在这种情形下，redis仍旧可以保持很好的处理性能，纵然redis故障，也只会丢失最近1秒钟的数据。如果在追加日志时，恰好碰着磁盘空间满、inode满或断电等情形导致日志写入不完全，也没有关系，redis供应了redis-check-aof工具，可以用来进行日志修复
rdb优点：1.RDB是一个单一的紧凑文件,它保存了某个韶光点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保过去30天的数据,这样纵然出了问题你也可以根据需求规复到不同版本的数据集.2.RDB是一个紧凑的单一文件,方便传送，适用于灾害规复.3.RDB在保存RDB文件时父进程唯一须要做的便是fork出一个子进程,接下来的事情全部由子进程来做，父进程不须要再做其他IO操作，以是RDB持久化办法可以最大化redis的性能.4.与AOF比较,在规复大的数据集的时候，RDB办法会更快一些.
缺陷：1.Redis意外宕机,可能会丢失几分钟的数据（取决于配置的save韶光点）。RDB办法须要保存全体数据集，是一个比较繁重的事情，常日须要设置5分钟或者更久做一次完全的保存。2.RDB 须要常常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能相应客户真个要求.如果数据集巨大并且CPU性能不是很好的情形下,这种情形会持续更久。
aof优点：1.利用AOF 会让Redis数据更加耐久: 你可以利用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.利用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端要求),一旦涌现故障，你最多丢失1秒的数据.2.AOF文件是一个只进行追加的日志文件,以是不须要写入seek,纵然由于某些缘故原由(磁盘空间已满，写的过程中宕机等等)未实行完全的写入命令,你也也可利用redis-check-aof工具修复这些问题.3.Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了规复当前数据集所需的最小命令凑集。 全体重写操作是绝对安全的，由于 Redis 在创建新 AOF 文件的过程中，会连续将命令追加到现有的 AOF 文件里面，纵然重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。4.AOF 文件有序地保存了对数据库实行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常随意马虎被人读懂， 对文件进行剖析也很轻松
缺陷：1.对付相同的数据集来说，AOF 文件的体积常日要大于 RDB 文件的体积。2.根据所利用的 fsync 策略，AOF 的速率可能会慢于 RDB 。 在一样平常情形下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速率和 RDB 一样快， 纵然在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以供应更有担保的最大延迟韶光。
aof同步策略有三种，分别为always everysec no 重写机制相同数据集的数据而言aof文件要远大于rdb文件，规复速率慢与rdb；Aof运行效率要慢与rdb，每秒同步策略效率较好，
在项目当中用jedis链接redis，配置IP和端口号，通过redis命令来操作完成相应的功能。
（5）订单模块：
订单的创建须要用户登录，这里用到了拦截器在springMVC中配置下拦截办法即可。
去购物车结算，判断是否上岸，利用拦截器拦截，实现HandlerInterceptor，从cookie中获取token，如果没有token，跳转到上岸页面，并拼接url通报到上岸页面，如果有token，通过token查询redis中有没有用户信息，如果没有，或过期，都返回上岸页面，否则，则上岸跳转到订单页面
1）订单创建逻辑：
当点击去购物车结算时，显示购物车的列表，当选中购物车的商品点击去结算的时候，显示商品的提交订单之前的一系列信息（也便是结算页）：针对数据库三张表：订单基本信息表、订单明细表（购买的商品信息）、订单配送（收货人的地址电话信息）
传入参数：由于创建订单也便是向数据库中插入一系列的信息，而对应的是数据库中的三个表，以是根据页面的内容，传入的参数也便是三个pojo类，然后页面填写的+补全页面上在数据库中没有的字段。以是紧张是对数据库中的三个表进行插入操作。做事接口是卖力吸收这三个pojo类，以是客户端要想办法将这三个pojo类通报过来。
根据接口文档，返回的是一个json格式的数据，即这三张表的数据是在一个json串中，以是这里要想办法将这三个表单独建立一个pojo来保存这个返回值。这样就将三个表放到了一个pojo类中
接下来便是数据的插入操作了，这个在service层实现：逐个表的插入数据库即可，然后返回一个订单号即订单的id。
controller层通报的便是这个pojo类，然后返回给客户端。
客户端也是将这个pojo类通报给做事接口，返回一个订单号给客户端。提交订单的时候显示订单提交成功页面时候，看下jsp页面显示哪些字段，然后用ModelMap通报给页面
2）拦截器配置利用：
<!--拦截器--><mvc:interceptors> <mvc:interceptor> <!--拦截所有order要求--> <mvc:mapping path=\"大众/order/\公众/> <!--配置拦截器的实现类--> <bean class=\"大众com.mr.order.interceptor.OrderInterceptor\"大众/> </mvc:interceptor></mvc:interceptors>
去购物车结算，判断是否上岸，利用拦截器拦截，实现HandlerInterceptor，从cookie中获取token，如果没有token，跳转到上岸页面，并拼接url通报到上岸页面，如果有token，通过token查询用户信息，如果未上岸，或过期，都返回上岸页面，否则，则上岸跳转到订单页面
（6）秒杀系统
由于秒杀活动只是我们网站营销的一个附加活动，这个活动具有短韶光、高并发的特点，如果和原有的网站支配在一起的话，一定会对现有的业务造成冲击，稍有不慎有可能会导致全体网站崩溃，以是我们会将这个模块独立支配。用户在秒杀开始前，为了担保不错过秒杀的机会，会一直的刷新浏览器页面，这样会一直的访问运用做事器、和数据库，从而对做事器和数据库造成一定的压力，以是我们不该用原来商品的详情页面，重新设计了秒杀商品的页面，并将页面静态化，这样用户的要求就不会经由运用做事。我们还须要租赁做事器宽带，然后再秒杀活动开始之前，用户只能浏览秒杀的商品不能购买，我们可以将购买按钮设置成灰色，无法点击，为了避免用户直接访问下单页面，我们可以不才单页面URL前加入由做事端天生的随机数作为参数，只有在秒杀活动开始时才会天生，这样纵然是秒杀系统的开拓者也无法在秒杀活动开始前访问下单页面。然后利用springMVC定时器来掌握秒杀韶光.
（7）商品信息搜索框（solr）：
我当时做商品信息查询搜索框的时候，由于我们是电商项目考虑到商品的数据量比较大，普通的搜索查询须要到数据库进行查询，加大了数据库的压力，以是我采取的是solr搜索引擎，solr是一个基于Lucene的全文搜索做事器，比较Lucene更高效、利用更便捷，在进行模糊匹配的时候，他可以 用来替代数据库中的like ,从而在匹配准确性以及性能进行大幅度的提高。在建立索引的时候我们通过在schema.xml配置IK分词器来完成中文分词。 从而实现了高亮显示关键词，分页，排序，多字段，多条件的高性能搜索。在从数据中取数据天生索引的时候，由于表中的数据量比较大，防止一次取出所导致内存溢出问题，我采取了分段批量提取的办法进行，除此之外我们对后续增加的数据根据优先级的不同采纳不同的策略，对付那些须要及时显示的数据我们通过spring定时器 在短韶光内(30分钟)进行增量索引的天生，对付那些不须要及时展示的数据,我们通过spring定时器在做事器相对空闲的时候（比如每天晚上凌晨）进行索引的重新天生。
此外我们为了提高solr搜索的性能对其进行了主从配置。
被动说：
1.我们solr利用的是solr4.7版本2.通过修正schema.xml来添加要进行索引的字段以及增加ik分词器3.通过solrj将数据库中的数据天生solr中的索引文件，注：solrj是java程序调用solr做事所用的jar包。4.通过在solrconfig.xml中配置requestHandler name=“/Replication”来进行主从同步的配置，在从solr中通过masterUrl指明要从哪些主solr做事器中同步数据
（8）留言评论
评论这一块实在也挺主要的，他紧张是指的顾客在网站上购买过该产品后，对该产品撰写的产品评论，紧张内容实在便是购买过程和利用过程的表示，还有产品本身的评价，还有物流速率，做事态度等。实在全体电商平台很多模块紧张是环绕着营销来运营的，好多用户现在便是买商品的同时，先会看一下商批驳论。
商批驳论这一块紧张涉及到的内容有，属性集，产品和属性集关联，产品评论，其余便是和产品、产品sku关联，评论属性评分，产品评论和客户，评论回答，产品统计；其余还有便是标签（或称为话题），附件，匿名评论。
由于订单交易完成后须要评论，考虑到评论不断增加，后期评论数据比较大，以是评论这块我们采取了mongodb数据库，之以是采取mongodb是由于:MongoDB是NoSQL的非关系型数据库，易于扩展，可以进行分布式文件存储，适用于大数据量、高并发、弱事务的互联网运用，因此我在项目中利用它来存储电商产品详情页的评论信息（评论id,商品id,标题，评分，内容，评论人信息，评论的发布韶光，评论标签组）并且为了提高可用性和高并发用了3台做事器做了mongodb的副本集，个中一台作为主节点，其余两台作为副本节点，这样在任何一台mongodb做事器宕机时就会自动进行故障转移，不会影响运用程序对mongodb的操作，为了减轻主节点的读写压力过大的问题，我还对mongodb副本集做了读写分离，使写操作在主节点进行，读取操作在副本节点进行。为了掌握留言，我们留言的界面设置在了订单状态，只有状态为5，也便是交易成功收货后才能评论，并在评论成功后将订单状态改为6。
【项目二】OA办公系统项目解释 ：hroms人力资源外包管理系统
技能选型：
核心框架：Spring Boot
安全框架：Apache Shiro 1.3
视图框架：Spring MVC 4.3
持久层框架：MyBatis 3.3
数据库连接池：Druid 1.0
日志管理：SLF4J 1.7、Log4j
页面交互：Vue2.x
1：Shiro
Shiro简介
apache Shiro是一个强大且易用的Java安全框架,实行身份验证、授权、密码学和会话管理。利用Shiro的易于理解的API,您可以快速、轻松地得到任何运用程序,从最小的移动运用程序到最大的网络和企业运用程序。
紧张功能
三个核心组件：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实现。
在项目中利用
1：导入坐标
shiro-core shiro-web shiro-spring三个jar包
2：在web.xml文件中添加shiroFilter
shiro过滤器，DelegatingFilterProxy会从spring容器中找shiroFilter
filter名字叫shiroFilter，拦截所有路径
3：自定义realm类
（1）继续 AuthorizingRealm
（2）重写三个方法
getName() 获取当前realm的名
doGetAuthorizationInfo(PrincipalCollection principals) 授权
doGetAuthenticationInfo(AuthenticationToken token) 认证
4：创建 applicationContext-shiro.xml 配置文件
1)在spring中注入自定义的realm
2)在spring中注入securityManager
在securityManager中通过property引入自定义的realm类
3)在spring中注入定义的ShiroFilter
id必须和web.xml中定义的 shiroFilter 同等
在ShiroFilter中通过property引入securityManager
定义登录方法的访问路径
定义没有授权的方法跳转的路径，常日是提示用户没有权限访问
定义拦截的规则
anon:匿名拦截器，即不须要登录即可访问；一样平常用于静态资源过滤；
authc:表示须要认证(登录)才能利用; / = authc表示所有的要求都会被shiroFilter拦截认证
logout:退出拦截器，紧张属性：redirectUrl：退出成功后重定向的地址（/）;示例“/logout=logout”
5：在自定义realm中添加认证
1）从token中获取到用户名
2）通过用户名去数据库中查询工具
3）如果不存在则返回null
4）如果存在，则将信息存放在SimpleAuthenticationInfo(当前工具、查询的密码、当前realm的名) ，然后将info返回；
6：登录失落败的非常信息
1>UnknownAccountException：代表账户不存在
2>IncorrectCredentialsException：代表密码缺点
7：登出
logout:退出拦截器，紧张属性：redirectUrl：退出成功后重定向的地址（/）;示例“/logout=logout”
8：授权
剖析三种办法
1）编程式，缺陷：必须进入要求方法中才能判断是否有权限，放弃
2）jsp标签办法， 缺陷：虽然在页面上没有显式要求按钮，但是可以通过浏览器地址栏中输入要求访问， 放弃
3）表明办法：优点，可以在要求进入方法之提高行权限掌握。 推举
jsp标签+表明结合利用
jsp标签
首先tglib定义shiro的标签
<shiro:authenticated> 登录之后<shiro:notAuthenticated> 不在登录状态时<shiro:guest> 用户在没有RememberMe时<shiro:user> 用户在RememberMe时<shiro:hasAnyRoles name=\"大众abc,123\公众 > 在有abc或者123角色时<shiro:hasRole name=\"大众abc\"大众> 拥有角色abc<shiro:lacksRole name=\"大众abc\"大众> 没有角色abc<shiro:hasPermission name=\"大众abc\公众> 拥有权限资源abc<shiro:lacksPermission name=\"大众abc\公众> 没有abc权限资源<shiro:principal> 显示用户身份名称<shiro:principal property=\公众username\"大众/> 显示用户身份中的属性值
查询sql
（1）通过用户id查询角色的sql
<select id=\"大众selectRolesByUserId\公众 resultType=\"大众String\公众> select sn from role where id in (select role_id from user_role where user_id = #{id}) </select>
(2)通过用户id查询权限的sql
<select id=\"大众selectPermissionByUserId\公众 resultType=\公众String\公众> select resource from permission where id in ( select permission_id from role_permission where role_id in( select id from role where id in ( select role_id from user_role where user_id = #{id} ))) </select>
MyRealm中的授权
获取当前工具getPrimaryPrincipal()
通过用户查询相对应的权限、角色
将权限和角色放入SimpleAuthorizationInfo中
9：缓存
授权完毕之后，每次访问都会调用授权的方法，查询数据库，我们可以将权限存放在缓存中，授权一次之后，再次查询就不会再次进入授权。
1）导入jar包 ehcache-core shiro-ehcache
2）配置缓存管理器 引入了shiro-ehcache.xml
3）securityManager中添加缓存管理器
4）添加 shiro-ehcache.xml 缓存的配置
清空缓存：
如果用户正常退出，缓存自动清空。
如果用户非正常退出，缓存自动清空。
如果修正了用户的权限，而用户不退出系统，修正的权限无法立即生效。
当用户权限修正后，用户再次上岸shiro会自动调用realm从数据库获取权限数据，如果在修正权限后想立即打消缓存则可以调用realm的 clearCache 方法打消缓存。
10：加密
1：先修正数据库中的密码为密文
利用md5加密，加上盐值，还有加密的次数，防止暴力破解
2：在配置文件中添加加密器
3：在自定义realm的bean中引入加密器
4：认证方法中添加盐值
11：shiro框架与springboot整合
1.Pom.xml中导入shiro-spring依赖。
2.在Application能扫描到的包下创建一个配置类(@Configuration),在该类等分别声明1.(@Bean)ShiroFilterFactoryBean(shiro过滤器工厂,
filterChainDefinitionMap.put来写入须要被拦截的路径(key)及访问所需权限(value).
配置不被拦截的路径(util/,anon),
登录路径shiroFilterFactoryBean.setLoginUrl(/login),
登录成功后跳转路径shiroFilterFactoryBean.setSuccessUrl(/index)等等
),
myShiroRealm(自定义的Realm类)
hashedCredentialsMatcher凭据匹配器(散列方法,次数)
securityManager(安全管理器)
开启shiro aop表明支持。
3.自定义myShiroRealm类。与Spring整合的写法同等，继续AuthorizingRealm抽象类，重载doGetAuthenticationInfo()，重写获取用户信息的方法（用token的username信息到数据库取出User工具,拿该工具的username,userpwd,solt,及该realm的name进行认证）以及获取用户权限的方法(将用户保存在数据库中的角色信息及权限信息加到用户信息中)。
【项目三】P2P网贷我最近做了一个P2P网贷的项目。这个项目紧张目的是针对个体（个人、企业或组织）和个体之间通过互联网平台实现的直接借贷。全体项目分为前台系统(用户访问平台)与后台管理系统两个项目。
前台项目紧张涉及的模块：是债券模块（展示债券以及用户购买时天生订单）、出借模块、借款模块、推广模块、信息表露模块、用户管理模块（登录注册、个人中央）。判断如果为新用户还涉及到一个新手勾引流程。
后台系统的模块：则分为用户管理模块，业务管理模块（债券的发布、高下架及调度、条约的POI导出），推广管理模块、统计管理模块（HighCharts报表完成用户登录及注册次数的统计、逐日购买量的统计、资金统计等等）基本设置(前台信息表露模块中展示的公司基本信息)、财务管理（紧张涉及到用户充值管理，线下充值，提现管理，用户信用管理，用户包管管理，不良债权转让管理，商城的退款管理，平台调账管理）等等。
我在项目中紧张卖力的是前台的债券模块、出借模块、借款模块、业务管理、财务管理模块。
2.1债券模块：
首先是将后台上架的债权信息展示给前台，购买流程为当用户点击购买某个债权时首先判断债券剩余的数量是否足够，如果足够则天生订单(此时订单状态为0未付款)并在库存中减去相应的数量，该订单如果在15分钟内未完成付款操作,则自动取消。天生订单后根据用户录入的银行卡信息调出相应的银行接口让用户进行付款（这里也可以添加新的银行卡）。用户这边付款后再通过银行接口返回的流水号查询是否付款成功。付款成功则将订单状态修正为1已付款,购买成功并关照用户，同时关照后台客服对订单做出处理。
如果两个用户同时购买了100份库存只有100的债权?
如果两个用户同时购买了100份库存只有100的债权。则只会有一个用户购买成功。由于此处利用RabbitMQ行列步队的缘故原由。行列步队是根据日志信息从左到右实行的。以是纵然是同时发出了天生订单的要求,在实行完左侧天生的订单之后,由于数据库中库存已经不足了,以是第二个订单天生是不会成功的。
业务管理模块中紧张涉及的有债券管理，催收管理，条约管理，借款管理。
2.2 债券管理：
比如债券的发布、高下架及调度，当债权信息有了更新往后。在业务逻辑层直接调用前台项目中重新天生静态化页面(freemarker)的方法将之前的债券展示信息更换掉。更换成功后才会提交事务，避免前台展示的数据与后台数据库中的数据涌现偏差。
催收管理模块：紧张是根据用户还款的韶光来及时给用户提醒。通过定时器来每天进行一次判断。比如说在间隔还款还有一周的时候，调用短信接口（httpclient）来给用户发送提示短信进行关照，在还款当天再次提醒用户过时将会产生违约金等。在过时三天之后会提醒客服对客户进行催收以及对催收情形的统计。过时一个月以上的用户可添加至黑名单。
订单天生后会自动添加到条约列表中。在条约管理中可以进行详情查看以及直接将条约导出为Word文档进行打印。
借款管理：首先用户选择相应的借款类型,在用户发出了借款申请后。首先是由审核部门对该用户信用级别（黑名单中的用户无法发出申请/信用等级越高的用户可申请的额度就越高,同时也根据抵押物来判断申请借款的金额）以及抵押物的一个审核。（此时默认状态为审核中），在审核通过后状态变更为已审核未发布，此时业务部门可以进行该借款的发布。发布往后前台用户就可以看到该信息并且借贷给该用户。当金额足够往后将状态变更为“已满标”。同时由财务部门将钱打给申请借款的用户。
2.3 财务管理：
我在这个模块中紧张卖力充值管理，线下充值，提现管理这几个模块。
充值管理与线下充值管理：紧张是对用户充值到此平台上的金额的一个记录的展示。考虑到安全问题,在该平台中只能对它进行查询而不能进行变动操作。且在该用户余额进行购买债券或借出操作时会有一个审核。
提现管理：用户在前台系统发出提现申请后，该条信息就会在提现管理中展示出来（状态为：申请提现），首先由业务部门核实后变动状态为（已审核，未打款），然后由财务部门进行打款。将状态变动为已提现。
后台管理系统包括：会员管理，业务管理，系统管理，财务管理，统计管理，推广管理等紧张模块
2.4会员管理：
是对会员信息统计和管理（包括个人信息，企业信息，机构信息），会员的认证管理，留言管理等。
会员认证管理：通过该功能新注册用户可以通过必要的用户认证后得到非0的借款信用额度而拥有有效的借款申请权限，在通过非必须、额外的用户认证来更进一步提高用户的借款信用额度，利用户可以在同一韶光取得更大额度的借款。
必要的用户认证：紧张包括：身份证认证，事情认证，收入认证，芝麻信用报告认证等。
额外的用户认证：紧张包括：学历认证，房产认证，技能职称认证，购车证明等。
留言管理：紧张是针对会员在“帮助中央”的留言，及时进行规复。
2.5 业务管理：
是我们网贷的核心模块，紧张有理财管理，借款管理，催收管理，条约管理等
2.6 理财管理：
有在线债券的管理和线上债券的转让管理。
2.7 借款管理：
有借款管理、个人借款意向管理和企业借款意向管理。借款管理中紧张是卖力对借款申请的审批（紧张卖力审查用户的借款类型和抵押物以及其他申请是否合理），并卖力在前台展示借款信息的页面进行招标。招收到的资金已满的话，后台进行审核后，做放款处理。
2.8 催收管理：
代还款列表，催收记录，黑名单。
代还款列表展示的是借贷用户的信息，便于后台职员的统计和催收的关照，催收的实现利用的是定时器+Webservice来实现的，正常还款的用户通过利用定时器，在还款期限前三天通过调用Webservice短信接口，发送短信给用户，提醒用户还款。对付过时3—7天用户，通过定时器实现线上的催收（发送短信，还款期限已过时），对付过时7天以上的用户，通过定时器关照后台管理职员，通过Poi技能导出相对应的过时用户信息，通过线下催款的办法催收贷款。对付严重过时的用户，线下催收的同时加入黑名单，不在供应做事给该用户。
2.9 系统管理：
紧张有后台账号，系统日志，业务推广等，须要利用shiro权限框架.
后台账号紧张分为业务员账号管理，管理员账号管理，用户账号管理等，在这模块中要实现登任命户的权限限定。
由于涉及到资金的安全，以是我们做了日志记录的统计，所有增编削的操作都要天生相应的日志，做一个日志的统计，方便任务到人。
业务推广板块紧张是对一些活动的推广，发送邮件和站内推广信给用户。
2.10 财务管理：
紧张有资金管理，资金明细等。
资金管理中包括：充值管理，线下充值管理，提现管理，放款管理，用户信用管理，用户包管管理等
资金的明细紧张是对平台资金的流向做相应的统计，通过Poi导出到做线下的会议利用。
2.11 统计管理：
紧张有用户统计，资金统计，业务统计，统计报表等（利用highcharts技能），紧张用于业务的推广办法。
用户统计：紧张是针对用户注册的办法的统计，方便后期的业务推广。
资金统计：是看平台的资金的流动情形和盈亏情形。
业务统计：平台业务情形的查看，以及业务后期的推广重心。
2.12 推广管理：
推广褒奖，褒奖金管理，活动管理等。
