江的福与小项目day12

前言：
1、同一个账户可不可以在不同的客户端登录。
可以，web网站的账号可以再不同的客户端同时登录。
2、在我们点击结算按钮时，后台的购物车数据结构是否被删除，订单数据结构是否生成。
没有生成，结算按钮不调用后台的service数据库服务。结算页面只是用户用来确认送货清单和选择地址信息的页面。
3、点击提交订单的按钮时，后台的购物车数据结构是否被删除，订单数据结构是否生成。
4、提交订单是对服务器的写操作，一般不用表单提交，而是直接从缓存或者数据库，查询用户所要购买的商品，转化成订单。

提交订单业务：

订单结算页面：
1、用户确认自己的订单信息
2、用户选择收货地址。
为了保证同一用户不能将同一订单反复提交，采取交易码的方式。
即在用户点击去结算时，生成交易码，并将其存入redis缓存，当用户提交订单时首先校验该页面携带的交易码，是否能通过校验，若通过校验继续，若不通过校验，不能让用户继续业务。

注意：校验时，会因为高并发而产生bug。
当一用户及其短的时间内，连续提交订单，会使得前面的交易码判定为success后，还没来得及删除，后面的校验码也被判定成功。

为了避免这种情况的发生， 采用lua脚本的方式，只要1校验成功，就直接key给删除。

SpringBoot+Thyemleaf开发环境正常，打包jar发到服务器就报错Template might not exist or might not be accessible

在controller层请求处理完了返回时，没有使用@RestController或@ResponseBody而返回了非json格式

分布式事务

事务：在分布式环境下，如何保证数据的一致性。

不同业务，同一时间提交、回滚。

性能解决方法：

1、在xa协议(事务管理器，资源管理器之间的协议)下，提交一个事务需要经过两个阶段。
阶段一：预备提交。
阶段二：提交。

2、xa两段式提交的进阶：tcc
需要在业务层实现，try，confirm和cancle接口，
弊端：入侵性太强。

3、基于消息的，最终一致性策略的分布式事务。（消息队列MQ）
在一个事务正在进行的同时，发出消息给其他的事务。
如果消息发送失败，或者消息的执行失败，则回滚消息，重复执行。
反复执行失败后，记录失败消息，后期补充性的处理
在消息系统中开启事务，消息的事务是指，保证消息被正常消费，否则回滚的一种机制。

消息队列中间件
1、activeMq，有Apache开发，基于ims的接口规则
2、rabbitMq，c开发局域amqp协议
3、kafka，大数据的消息中间件
4、zeroMq，基于socket协议
5、mateMq ，阿里的产品