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

大德大威宝宝天龙 · 发表于 2021-9-1 08:18:10

本帖最后由大德大威宝宝天龙于 2021-9-1 08:43 编辑

大德大威宝宝天龙 · 发表于 2021-9-1 08:19:13

本帖最后由大德大威宝宝天龙于 2021-9-2 11:58 编辑

day10_用户中心0.学习目标

ALISMS
实现数据校验功能
实现SMS发送功能
实现查询用户功能

1.ALISMS服务

之前我们已经学习过了ALISMS服务，但是大家真的掌握了SMS发送的正确方式吗？来看看我们在LYSHOP中，如何实现SMS发送功能。

1.1.demo

注册页面上有SMS发送的按钮，当用户点击发送短信，我们需要生成YZM，发送给用户。我们将使用ALI提供的SMS发送。

1.2.创建SMS微服务

在以前，我们都是把发SMS功能抽取一个工具类，任何地方需要，直接调用工具类发送SMS即可。这样的方式存在以下缺点：

发送SMS代码与业务代码耦合
SMS发送功能会影响业务功能执行

如果在业务代码中，嵌入发送SMS的代码，那就是功能的耦合，不方便后期的维护。而且

因为SMS发送是调用第三方的云服务，API调用成功与否、执行时长都是不确定的。如果执行发SMS时，因为网络问题导致阻塞，那么我们自己的业务也会阻塞。

为了解决上述问题，提高程序的响应速度，SMS发送我们都将采用异步发送方式，即：

SMS服务监听MQ消息
收到消息后发送SMS，根据消息routing_key不同，发送不同类型的SMS
其它服务要发送SMS时，通过MQ通知SMS微服务。

大德大威宝宝天龙 · 发表于 2021-9-2 09:54:18

本帖最后由大德大威宝宝天龙于 2021-9-2 11:49 编辑

学习目标

了解什么是无状态登录
了解JWT原理
实现登录授权功能
实现首页登录状态判断

1.无状态登录原理1.1.什么是有状态？

有状态服务，即服务端需要记录每次会话的客户端信息，从而识别客户端身份，根据用户身份进行请求的处理，典型的设计如tomcat中的session。

例如登录：用户登录后，我们把登录者的信息保存在服务端session中，并且给用户一个cookie值，记录对应的session。然后下次请求，用户携带cookie值来，我们就能识别到对应session，从而找到用户的信息。

缺点是什么？

服务端保存大量数据，增加服务端压力
服务端保存用户状态，无法进行水平扩展
客户端请求依赖服务端，多次请求必须访问同一台服务器

1.2.什么是无状态

微服务集群中的每个服务，对外提供的都是Rest风格的接口。而Rest风格的一个最重要的规范就是：服务的无状态性，即：

服务端不保存任何客户端请求者信息
客户端的每次请求必须具备自描述信息，通过这些信息识别客户端身份

带来的好处是什么呢？

客户端请求不依赖服务端的信息，任何多次请求不需要必须访问到同一台服务
服务端的集群和状态对客户端透明
服务端可以任意的迁移和伸缩
减小服务端存储压力

1.3.如何实现无状态

无状态登录的流程：

当客户端第一次请求服务时，服务端对用户进行信息认证（登录）
认证通过，将用户信息进行加密形成token，返回给客户端，作为登录凭证
以后每次请求，客户端都携带认证的token
服务端对token进行解密，判断是否有效。

整个登录过程中，最关键的点是什么？

token的安全性

token是识别客户端身份的唯一标示，如果加密不够严密，被人伪造那就完蛋了。

采用何种方式加密才是安全可靠的呢？

我们将采用JWT来生成token，保证token的安全性

空蒙 · 发表于 2021-9-2 10:34:37

2021年8月开始，我们对活动帖做了一些要求，希望大家的打卡内容不要仅仅是上传一张图片或一两句简单的话。除了分享美照、截图、视频等内容外，还可以用简短的文字说明下当时的想法哦。如仅有一张图片，无任何文字内容，或记录文字均为“我今天吃了早饭，是两个包子”等无实质意义的内容，我们将判定为纯水帖，当日打卡无效哦~

大德大威宝宝天龙 · 发表于 2021-9-3 09:03:21

本帖最后由大德大威宝宝天龙于 2021-9-3 17:04 编辑

今天自习,摸鱼梦幻刷个维摩诘去

恶心,神佑

大德大威宝宝天龙 · 发表于 2021-9-4 08:07:51

学习目标

理解网关登录拦截业务
理解如何退出登录
理解如何刷新token

1.登录超时控制

一般登录状态都有一个超时时间，超过时间后登录状态会失效。目前我们给用户颁发的JWT令牌并未设置超时时间，也就是说用户只要不关闭浏览器，登录状态就一直有效。

那么，我们该如何实现登录超时控制呢？

1.1.思路分析

登录超时控制有两种实现思路：

思路一：在颁发给用户的JWT中设置超时时间，每次校验JWT顺便校验时间
思路二：在服务端记录用户登录超时时间，即便jwt有效，服务端过期依然算登录失效

两种思路都可以，我们选择哪一种呢？

思路一的优点是过期时间在JWT中就有，无需服务端记录，减轻服务端压力；缺点是由于JWT的签名机制，一旦生成后不能修改，所以登录续期实现起来很麻烦。

思路二的优点是过期时间由服务端记录，控制用户的登录过期、续期、登出都很方便；缺点是给服务端带来了存储压力。

两种方案都可以，本例中我们采用思路二。

因此，这里我们需要完成两部分内容：

登录时配置超时时间：
- 用户登录时记录JWT，并设置超时时间到redis中，采用string数据类型
- key是用户id，值是JWT中的jti，并且设置过期时间，比如30分钟
用户访问时更新超时时间
- 用户每次访问服务端，都更新redis的有效期

大德大威宝宝天龙 · 发表于 2021-9-5 08:18:20

0.学习目标

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

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

需求描述：

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

1.2.业务分析

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

未登录购物车

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

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

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

已登录购物车

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

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

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

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

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

取错了名 · 发表于 2021-9-5 09:03:12

别光学习不练上几段代码

大德大威宝宝天龙 · 发表于 2021-9-5 17:54:09

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

贴了给谁看啊

大德大威宝宝天龙 · 发表于 2021-9-6 08:36:08

学习目标

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

1.订单数据结构

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

大德大威宝宝天龙 · 发表于 2021-9-7 12:27:27

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

大德大威宝宝天龙 · 发表于 2021-9-8 08:27:59

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

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

1.什么是分布式事务

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

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

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

1.1.本地事务

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

原子性（A）

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

一致性（C）

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

隔离性（I）

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

持久性（D）

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

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

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

1.2.分布式事务

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

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

大德大威宝宝天龙 · 发表于 2021-9-9 08:19:29

学习目标

微信支付下单
生成二维码
实现支付回调
实现支付状态查询
chapter6_5_1.jpg (81.35 KB, 下载次数: 7)

下载附件

2021-9-9 08:19 上传

一朝瑾秋色 · 发表于 2021-9-9 09:07:44

加油

大德大威宝宝天龙 · 发表于 2021-9-10 08:45:34

学习目标

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

1.业务需求

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

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

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

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

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

2.延迟队列

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

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

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

2.1.什么是延迟队列

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

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

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

[玩家投稿] 【梦幻夜话】生活随笔+辞职转行学Java9月篇

浏览过的版块