- Spring,控制翻转，依赖注入；通过xml文件的配置实现对于对象生命周期的控制，以及依赖注入的实现；Spring将Java的所有类都看作JavaBean，而IoC的目标就是管理Beans
- MyBatis：sqSessionFactoryBuilder，sqlSessionFactory，sqlSession，Mapper；Pojo，Mapper（接口、XML）
- 控制反转就是通过描述（XML或者注解），并通过第三方去产生或获取特定对象的方式
- Spring-Bean的装配方式【IoC容器，控制反转容器】
- 在XML中显示的配置
- 通过注解装配Bean:(@component,@Value)、@Bean、@Autowired（@Primary、@Qualifier）
- 通过Spring表达式注入
- 装配第三方对象Bean，推荐使用XML的方式、装配本地Bean对象推荐使用注解的方式
- Spring-AOP的应用
- 在数据库事务操作中，将数据库资源的申请，回收，事务的提交和回滚切片化，并且抽出
- SpringAOP只支持方法拦截
- Spring-Mybatis本地数据库项目搭建
- 使用SpringBean配置数据源【数据源类库可以有多种选择：jdbc模板，c3p0等等】
- 使用SpingIoc注入配置SqlSessionFactoryBean
- 使用SpingIoc注入配置MapperScannerConfigurer，配置搜索导入mapper的规则
- Spring事务实现方式
- XML形式，已经不推荐了
- 注解@Transactional是目前主流的方式
- @Transactional的主要配置是：传递性Propagation、隔离性isolation的配置
- Propagation：REQUIRED（默认，当前有其他事务就沿用其他事务，如果没有就创建新的）、REQUIRES_NEW（创建新的事务）、Nested等等
- isolation：脏读 < 读写提 < 可重复 < 序列化【事务并发的隔离级别,从左到右越来越严格】
- 当发生事务嵌套的时候，子事务与外围事务不要处于同一个Service类中，这样会触发自调用的陷阱，事务会失效【@Transactional的实现原理是基于AOP的原因】
- 被标记@Transactional的方法指导运行结束的时候Spring才会释放数据库事务资源，所以一些耗时的但是与数据库无关的操作不要放置到Service中完成，而是放在Controller中完成
- Servlet 执行以下主要任务：
- 读取客户端（浏览器）发送的显式的数据。这包括网页上的 HTML 表单，或者也可以是来自 applet 或自定义的 HTTP 客户端程序的表单。
- 读取客户端（浏览器）发送的隐式的 HTTP 请求数据。这包括 cookies、媒体类型和浏览器能理解的压缩格式等等。
- 处理数据并生成结果。这个过程可能需要访问数据库，执行 RMI 或 CORBA 调用，调用 Web 服务，或者直接计算得出对应的响应。
- 发送显式的数据（即文档）到客户端（浏览器）。该文档的格式可以是多种多样的，包括文本文件（HTML 或 XML）、二进制文件（GIF 图像）、Excel 等。
- 发送隐式的 HTTP 响应到客户端（浏览器）。这包括告诉浏览器或其他客户端被返回的文档类型（例如 HTML），设置 cookies 和缓存参数，以及其他类似的任务。
- Spring + Spring MVC + Spring Integration + Mybatis 架构概述
- Spring提供IOC和AOP的能力，一切的支撑技术
- Spring MVC 提供web页面访问框架能力
- Spring Integration, 采用订阅发布模型，实现了一个消息驱动的框架。将复杂的代码逻辑解耦；主体概念，
- Message消息主题。默认提供payload、header两个可操纵的字段
- int:Channel，管道，实现消息传播流动的载体
- int:Chain， 将不同管道连接的链条，控制消息流动方向
- int-http 配置外部网络请求响应的规则
- Spring-Mybatis 提供数据配置注入的能力、以及支持数据库事务
- Mybatis SQLSessionFactory的配置依赖于Spring的注入；提供数据库的访问接入（Mapper、Dao）
- 后台代码架构
- Command层是业务逻辑的处理层，持有并调用Servive完成业务逻辑的处理
- Service封装对Dao层数据访问的调用，提供事务的能力
- Dao是底层实际操作数据的接口（Mybatis支持）
- Vo（Value Object）数据模型实体
- 梳理“存入”页面操作的完成后台调用流程
- httpRequestRouterChannel是入站的管道，httpRequestChannel默认的管道输出的管道，即登录后发生的网络调用
- httpRequestChannel到signStateRouterChannel的链路，链路中设置RSA解密的filter
- signStateRouterChannel管道，将一些不需要验证toke的请求，直接输送到后续的流程中，此外的请求，输送到verifyTokenChannel中
- verifyTokenChannel到serviceRequestChannel的链路中，设置RequestChannelFilter，验证token，并将一些账户相关的数据，例如Trade_Account_NO装填到payload中
- serviceRequestChannel到successChannel的链路中，设置serviceRouterChannel的网关，将请求路由到真这正处理的Channel中，调用实际的Command的Api
- successChannel到responseChannel的链路中，通过transfer将Command返回的数据结构统一封装为ResultMessage
- responseChannel到jsonTransferChannel的链路，根据自定义的header[‘content’]字段选择结果数据结构的transfer，默认为jsonTransferChannel
- 定义trasfer将object转换为json数据，到此输出为httpResponseChannel，完成一次网络请求的处理，将结果返回
- 高并发业务架构设计
- 无效请求的屏蔽
- 验证码（图形、短信验证码），并将验证服务防止到负载均衡服务器上去完成，减轻业务Web服务的压力
- 实名制
- 封闭僵尸账户、屏蔽IP
- 业务Web系统设计
- 水平分法，将服务按照业务处理类型进行分类，部署到不同Web服务器中分流请求
- 垂直分法，部署多套相同的服务到不同的Web服务器上面，按照服务器的处理能力进行分流
- 水平与垂直相结合，先按照业务进行分类，局部按照垂直的方式进行分布式
- 数据库优化
- 分表分库
- 优化SQL
- 动态数据和静态数据分离
- CDN
- HTTP静态服务器
- 锁和高并发
- 悲观锁是一种利用数据库内部机制提供的锁的方法，也就是对更新的数据加锁，这样在并发期间一旦有一个事务持有了数据库记录的锁，其他的线程将不能再对数据进行更新，这就是悲观锁的实现方式【for update】
- 乐观锁是一种不会阻塞其他线程并发的机制，他不会使用数据库的锁积极性实现，它的设计里面由于不阻塞其他线程，所以并不会引发线程频繁挂起和恢复，这样便能够提高并发能力。乐观锁使用的CAS原理，对于多个线程共享的资源，先保存一个旧值，然后经过一定的逻辑处理，当需要修改共享值的时候，先比较当前的值和旧值是否一致，如果一直则进行修改，否则就放弃【失败】或者重试【可重入，一般限制时间或者限制次数】
- 使用Redis进行原子性的保障
- 无效请求的屏蔽