微信点餐项目总结

发表于 | 分类于 | 次

微信点餐

全局异常的处理

@ControllerAdvice

AOP验证微信是否登录

@Aspect

定义一个切面，每一个请求调用，都需要判断是否携带有token.

分布式session

uuid作为token存储在redis中

微信公众号授权过程

通过AppId和AppSecret和code==>获得access_code

Access_code ==> openId

转发到returnUrl?openid=***

微信支付流程

发起支付=>收到微信的异步通知=>根据payResponse返回的信息，判断并修改订单状态

退款=>需要一个证书

完成订单后，可以进行微信模版消息推送

redis分布式锁的实现

key为productId，value为当前时间+超时时间

redis缓存

@cacheable

缓存，但update,它并不更新

@cacheEvict

执行下面的update，进而调用save方法之后，清除掉redis里的内容删除。

微信点餐（微服务升级）

Ribbon: 负载均衡

ServerList: 首选获取所有的服务列表

ServerListFilter：过滤掉一部分地址

通过IRule选择一个实例

应用通信

Feign的使用

统一配置中心

Spring Cloud Bus 自动刷新配置（rabbitmq）

git配置web-hook，访问/bus-refresh

原始流程，下单

  1. 查询商品信息（调用商品服务）
  2. 计算总价（生成订单详情）
  3. 商品服务扣库存（调用商品服务）
  4. 订单入库（生成订单）

异步扣减库存(修改为秒杀场景的思考)

1.读redis

2.减库存并将新值重新设置进redis

（1、2需要分布式锁，考虑多线程并发）

3.订单入库异常，手动回滚redis(try-catch)

网关服务

Cookie 和 动态路由

限流：令牌桶，放100个令牌

鉴权：

​ order/create 只能买家访问

​ order/finish 只能卖家访问

服务容错

服务降级：超市触发降级

断路器：错误率达到一定程度，触发断路器

​ 10000秒

​ 10滚动窗口中，有7次 70%>60%,会触发断路器

​ 60%

rpc框架，dubbo简单理解

dubbo作为rpc框架，实现的效果就是调用远程的方法就像在本地调用一样。如何做到呢？

就是本地有对远程方法的描述，包括方法名、参数、返回值，在dubbo中是远程和本地使用同样的接口；

然后呢，要有对网络通信的封装，要对调用方来说通信细节是完全不可见的，网络通信要做的就是将调用方法的属性通过一定的协议（简单来说就是消息格式）传递到服务端；

服务端按照协议解析出调用的信息；执行相应的方法；在将方法的返回值通过协议传递给客户端；客户端再解析；

在调用方式上又可以分为同步调用和异步调用；简单来说基本就这个过程。

秒杀场景（交易性能优化）

性能瓶颈

  • 交易验证完全依赖数据库
  • 库存行锁
  • 后置处理逻辑

库存行锁优化

  • 扣减库存缓存化
  • 异步同步数据库
  • 库存数据库最终一致性保证

扣减库存缓存化

方案(1)：

  1. 活动发布 同步库存进缓存
  2. 下单交易减缓存库存

问题：

  1. 数据库记录不一致

方案(2)：

  1. 活动发布 同步库存进缓存
  2. 下单交易减缓存库存
  3. 异步消息扣减数据库内库存

事务型消息

投递一个prepare状态的消息

问题：

  1. 异步消息发送失败
  2. 扣减操作执行失败
  3. 下单失败无法正确回补库存

本质：

没有库存流水

方案：

  1. 引入库存操作流水
  2. 引入事务性消息机制

rocketmq如何保证消息不丢失？

一、大体可以从三方面来说：

分别从Producer发送机制、Broker的持久化机制，以及消费者的offSet机制来最大程度保证消息不易丢失

  1. 从Producer的视角来看：如果消息未能正确的存储在MQ中，或者消费者未能正确的消费到这条消息，都是消息丢失。
  2. 从Broker的视角来看：如果消息已经存在Broker里面了，如何保证不会丢失呢（宕机、磁盘崩溃）
  3. 从Consumer的视角来看：如果消息已经完成持久化了，但是Consumer取了，但是未消费成功且没有反馈，就是消息丢失

从Producer分析：如何确保消息正确的发送到了Broker?

  1. 默认情况下，可以通过同步的方式阻塞式的发送，check SendStatus，状态是OK，表示消息一定成功的投递到了Broker，状态超时或者失败，则会触发默认的2次重试。此方法的发送结果，可能Broker存储成功了，也可能没成功
  2. 采取事务消息的投递方式，并不能保证消息100%投递成功到了Broker，但是如果消息发送Ack失败的话，此消息会存储在CommitLog当中，但是对ConsumerQueue是不可见的。可以在日志中查看到这条异常的消息，严格意义上来讲，也并没有完全丢失
  3. RocketMQ支持 日志的索引，如果一条消息发送之后超时，也可以通过查询日志的API，来check是否在Broker存储成功

从Broker分析：如果确保接收到的消息不会丢失?

  1. 消息支持持久化到Commitlog里面，即使宕机后重启，未消费的消息也是可以加载出来的
  2. Broker自身支持同步刷盘、异步刷盘的策略，可以保证接收到的消息一定存储在本地的内存中
  3. Broker集群支持 1主N从的策略，支持同步复制和异步复制的方式，同步复制可以保证即使Master 磁盘崩溃，消息仍然不会丢失。

从Cunmser分析：如何确保拉取到的消息被成功消费？

  1. 消费者可以根据自身的策略批量Pull消息
  2. Consumer自身维护一个持久化的offset（对应MessageQueue里面的min offset），标记已经成功消费或者已经成功发回到broker的消息下标
  3. 如果Consumer消费失败，那么它会把这个消息发回给Broker，发回成功后，再更新自己的offset
  4. 如果Consumer消费失败，发回给broker时，broker挂掉了，那么Consumer会定时重试这个操作
  5. 如果Consumer和broker一起挂了，消息也不会丢失，因为consumer 里面的offset是定时持久化的，重启之后，继续拉取offset之前的消息到本地。

微服务之间分布式事务

链接：使用spring cloud alibaba seata解决分布式事务