【梦幻夜话】生活随笔+辞职转行学Java9月篇

大德大威宝宝天龙

大德大威宝宝天龙

休息

空蒙

LZ你好，活动需要分享自己的游戏或者生活动态，类似于朋友圈，这样复制粘贴PPT知识点是不行的哦~

大德大威宝宝天龙

.清理订单

学完了各种延迟队列的实现，不知道大家最喜欢哪一种？

本例中我们会选择RabbitMQ来作为延迟队列，综合起来比较有优势。

3.1.业务分析

首先，我们需要在项目中声明队列和交换机，与上面demo类似：

两个交换机：

• ly.order.exchange：一个普通的topic类型的交换机
• ly.dead.exchange：一个普通topic类型的交换机，但是作为死信交换机来用
  
  

两个队列：

• ly.dead.order.queue：死信队列，设置过期时间为30分钟（测试可以用20S），
  • 与ly.order.exchange交换机绑定，接收消息，routing_key为 order.evict
  • 指定x-dead-letter-exchange为ly.dead.exchange这个死信交换机
  • 设置x-message-ttl为30分钟
    
    
• ly.evict.order.queue：普通任务队列，接收死信交换机转发过来的消息
  • 与ly.dead.exchange交换机绑定，接收消息，routing_key为 order.evict
    
    
  
  

来看下业务流程：

首先修改下单业务：

• 下单业务的最后，向ly.order.exchange这个交换机发送消息，携带订单id
  
  

然后一个独立的消费者，需要监听ly.evict.order.queue这个队列，业务：

• 接收到订单id信息
• 根据id查询订单状态，判断是否是未支付
  • 如果未支付则需要关闭订单，设置状态为5（已关闭），注意幂等处理
  • 如果已支付，则无需处理
    
    
• 如果关闭订单了，还要查询对应OrderDetail，得到其中的商品和数量信息
• 调用商品微服务，恢复库存，注意分布式事务问题
  
  

大德大威宝宝天龙

自习一天.......肝不动了

大德大威宝宝天龙

学习目标

• 了解Java的DelayQueue原理
• 理解Redis实现延迟队列原理
• 理解RabbitMQ死信队列原理
• 能实现清理订单业务
  
  

1.业务需求

之前我们讨论过扣减库存的问题，下单减库存和支付减库存各自有一定的优势和缺陷，我们选择了下单减库存的方案。

订单创建之后，就会扣减库存，并且生成了支付的二维码，但是如果用户一直不支付，就会导致商品库存被占用，而不能形成有效交易，会损害商家的利益，流失真正的具有购买意向的客户。

因此，如果有客户下单超过一定的时间没有付款，我们必须关闭订单，释放库存。

那么问题来了，我们如何得知哪些订单时超时未支付的订单呢？

订单下单后，需要等待一段时间后再判断是否支付，到底是关闭还是继续。这样的延时执行的业务，称为延时任务。

2.延迟队列

与延时关闭订单这样的业务类似，还有很多需要延时执行的任务，例如：

• 订餐通知:下单成功后60s之后给用户发送短信通知。
• 当订单一直处于未支付状态时，如何及时的关闭订单，并退还库存？
• 如何定期检查处于退款状态的订单是否已经退款成功？
• 新创建店铺，N天内没有上传商品，系统如何知道该信息，并发送激活短信？
  
  

而解决这一类延时任务问题，一般都会通过延迟队列来解决

2.1.什么是延迟队列

延迟队列，首先是队列，例如我们学习的MQ，是消息队列，也就是一个存放消息的容器。延迟队列就是延迟消费的消息队列。队列中存储的是延时消息，所谓“延时消息”是指当消息被发送以后，并不想让消费者立即拿到消息，而是等待指定时间后，消费者才拿到这个消息进行消费,(延迟送达)。

延迟队列不仅仅要实现消息的延迟消费，最好还要满足下面的几点要求：

• 可靠性：消息进入到延迟队列后， 保证至少被消费&32;一次。
• 高可用性：至少得支持多实例部署。挂掉一 个实例后，还有后备实例继续提供服务。
• 实时性：允许存在一定的时间误差，希望在秒级。
• 支持消息删除：业务使用方，可以随时删除指定消息。
  
  

一朝瑾秋色

加油

大德大威宝宝天龙

学习目标

• 微信支付下单
• 生成二维码
• 实现支付回调
• 实现支付状态查询
• 
  

大德大威宝宝天龙

day14_分布式事务
0.学习目标

• 了解分布式事务产生的原因
• 知道几种分布式事务解决方案
• 知道分布式事务各种解决方案的优缺点和使用场景
• 学会使用Seata来解决分布式事务
  
  

1.什么是分布式事务

我们已经完成了下单的业务，但是下单业务中会包含多个微服务的调用，例如：

• 订单微服务：新增订单、订单详情、订单物流
• 商品微服务：扣减库存
• 优惠券服务：扣减用户优惠券
• ...
  
  

要了解分布式事务，必须先了解本地事务。

1.1.本地事务

事务，是指传统的单机数据库事务，必须具备ACID原则：

• 原子性（A）
  
  

所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。

• 一致性（C）
  
  

事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有500元，如果在一个事务里A成功转给B50元，那么不管发生什么，那么最后A账户和B账户的数据之和必须是1000元。

• 隔离性（I）
  
  

所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。

• 持久性（D）
  
  

所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。

因为在传统项目中，项目部署基本是单点式：即单个服务器和单个数据库。这种情况下，数据库本身的事务机制就能保证ACID的原则，这样的事务就是本地事务。

概括来讲，单个服务与单个数据库的架构中，产生的事务都是本地事务。

1.2.分布式事务

分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务：

• 跨数据源的分布式事务
• 跨服务的分布式事务
• 综合情况
  
  

大德大威宝宝天龙

休息日  怎么睡到快11点了还困

大德大威宝宝天龙

学习目标

• 了解订单表设计
• 实现减库存功能
• 实现下单功能
• 实现查询订单功能
  
  

1.订单数据结构

加入购物车后，自然就要完成用户下单，订单属于对事务要求较高的业务，肯定不能写入MongoDB，应该写入MySQL数据库中。

大德大威宝宝天龙

取错了名 发表于 2021-9-5 09:03
别光学习不练 上几段代码

贴了给谁看啊

取错了名

别光学习不练 上几段代码

大德大威宝宝天龙

0.学习目标

• 了解购物车功能流程
• 能使用Localstorage做数据存储
• 能使用SpringData操作MongoDB
• 能理解ThreadLocal的作用
• 能实现已登录时购物车功能
  
  

1.购物车功能分析1.1.需求

需求描述：

• 用户可以在登录状态下将商品添加到购物车
• 用户可以在未登录状态下将商品添加到购物车
• 用户可以使用购物车一起结算下单
• 用户可以查询自己的购物车
• 用户可以在购物车中可以修改购买商品的数量。
• 用户可以在购物车中删除商品。
• 用户可以在购物车中看到商品满足的优惠信息
• 用户可以看到购物车商品价格变化
• 用户可以看到购物车商品是否下架
• 用户可以看到购物车商品库存是否充足
• 用户可以对商品批量结算下单
  
  

1.2.业务分析

在需求描述中，不管用户是否登录，都需要实现加入购物车功能，那么已登录和未登录下，购物车数据应该存放在哪里呢？

未登录购物车

用户如果未登录，将数据保存在服务端存在一些问题：

• 无法确定用户身份，需要借助与客户端存储识别身份
• 服务端数据存储压力增加，而且可能是无效数据
  
  

那么我们应该用把数据保存在客户端（浏览器），这样每个用户保存自己的数据，就不存在身份识别的问题了，而且也解决了服务端数据存储压力问题。

已登录购物车

用户登录时，数据保存在哪里呢？

大家首先想到的应该是数据库，不过购物车数据比较特殊：

• 读和写都比较频繁
• 数据安全性要求不高
• 数据没有事务需求
  
  

这样的数据存储数据库有些浪费。因此我们可以考虑存入NoSql库中，例如：Redis、Elasticsearch、MongoDB等。

这里我们采用MongoDB作为购物车存储方案。