这是一种基于 Spring AOP 和 Servlet 过滤器的安全框架。它提供全面的安全性解决方案,同时在 Web 请求级和方法调用级处理身份确认和授权。在 Spring Framework 基础上,Spring Security 充分利用了依赖注入(DI,Dependency Injection)和面向切面技术。
1.1.8. 网站并发量
Nginx 的并发量大致在 3-5 万。
1.1.9. 订单 ID 是怎么生成的?
订单 ID 首先是不能重复的,鉴于此,我们可以使用商品 ID+当前时间戳,或者通过userId+当前时间戳通过 MD5 加密的方式,来获取一个唯一的订单号,主要还是看需求,并保证订单 ID 的唯一性。
2、服务的时间:当 Servlet 创建初始化完成之后,就开始一直在提供服务,用户通过浏览器只要访问这个 Servlet 程序,那么就一定会调用这个 Servlet 的 service 方法。每次访问都会调用 service 方法。Servlet 中的 service 方法是专门提供出来给用户服务的。
而 IOC 能做到什么呢,就是 service 不再利用 web 层去获取,而是通过 spring 容器创建bean 对象来自动的为我们注入。这样的话整个过程就反过来了,以前是 web 层去 new 一个service,现在是 service 主动被设置到 web 层中去了,这就是反转控制的由来。
通过 IOC,我们就可以在不修改任何代码的情况下,就可以进行实现类的切换,当然前提还是必须得写一个 service 的实现类。这样我们只需要在配置文件配置一下就 ok 了,而不需要再一个个的写工厂来获取了。
这就是 IOC 为我们带来的模块的松耦合和应用的便利性。
DI 注入:
依赖注入,在 spring 框架创建 bean 对象时,动态的动态的将依赖对象注入到 bean 组件。
举例:HelloServiceImpl 内部需要依赖 info 属性
传统方法和依赖注入的区别:
IOC 和 DI 的区别:
IOC 控制反转指的是对象的创建权,被反转到了 spring 容器来管理。DI 依赖注入,指spring 容器在创建对象的过程中将对象依赖的属性通过配置文件进行注入。表面是先有控制反转,再有依赖注入。实际是一个事件,两种不同时期的称呼。DI 实际上也可以理解为就是实现 IOC 的方式。就比如将一个 B 对象注入到另外一个 A对象中,即实现了控制反转(不再在 A 对象中创建 B 对象,而是通过配置文件主动配置),也实现了 DI 注入(将 B 对象作为 A 对象的属性,利用配置文件注入到 A 对象中)。
假设 Web 服务器 A 是所有用户登陆的服务器,那么当用户验证登陆一下,session 数据就会写到 A 服务器里,那么就可以自己写脚本或者守护进程来自动把 session 数据同步到其他 Web 服务器,那么当用户跳转到其他服务器的时候,那么 session 数据是一致的,自然就能够直接进行服务无须再次登陆了。缺点是,可能会速度慢,不稳定。如果是单向同步的话,登陆服务器出现问题,那么其他服务器也无法服务,当然也可以考虑双向同步的问题。
这个方式与 NFS 的方式类似,也是采用一台 Mysql 服务器做共享服务器,把所有的 session的数据保存到 Mysql 服务器上,所有 Web 服务器都来这台 Mysql 服务器来获取 Session 数据。缺点也是依赖性太强,Mysql无法工作了影响所有的 Web 服务器。当然,可以考虑多台 Mysql 数据库来共享 session,使用同步 Mysql 数据的方式。