互联网架构订单流程技术选型比较_笔记

业务架构：
业务中台：
1.业务都是在，一个业务的聚合层。把业务中台处理，业务中台，绝大部分的互联网的结构。回到我们的订单服务，

2.订单状态机，图，
用户收到话务后，订单完成后订单完成后，设计模式里面，设计状态机模式。一定会存在的，大型的互联网公司订单如何扭转呢？
可以有工作流，每一种工作流都要非常完成，电商模式分为C2C ,B2c,B2b,o2o,等模式，C2c淘吧。对应的系统场景，来说，涉及非常多的状态扭转，我们来一下
分析一下主要流程，待付款，订单确认页，只有当我们提交订单之后，创建数据库。去买电影表，锁定电影座位，预留资源，创建一个订单，通常是放置到事务内。
订单待付款，完成，座位的人，导致电影票，一定会涉及到现金流，付款时间也是非常短的。怎么来实现订单的充值取消。

3.业务实现方案：
延时队列mq，redis,定时任务，在淘宝中也会用哪些。我们看源码，任务扫描，订单扫描方法，专门执行调度任务，默认的是0,1-待付款，这几种状态，时效性比较差，每过15分钟。
下了一点，刚刚好过期，我才能否锁定取消，

2.
使用redis,肯定会全表扫描，行锁的情况的发生。Paran 订阅的chanel的话，订阅所有的库，partain的，创建一个容器，redis 的连接工厂，传过来，bean,new 一个contailner ,
把一个工厂设置进来，轮训接口，返回return.
   监听的效果来实现，随着容器的启动和启动，会去start 方法，要去实现 redis,如果要用key ，失效开启c,cd redis 目录，有一个keystbase,保证设置为ES，我们这边发布一个key,
   打印出来，通过redis 发布与订阅，端口被占用了，如果后台被设置成一个keyvalue,，订单被设置成。
   代码工程的方法，放置到时间key,value,但是呢？
   redis 发布到所有订阅者，所有的人去取消订单，引入分布式锁，挂掉了怎么办呢，无法释放资源。
   所有的key 都会进入chancel,去执行。redis key 失效机制，维护在一个字典表里面中的。reids 单线程的去get/set 之外，是不是维护这个词典表中，维护这个随机抽取20%
   的key 出来，哪些key 是失效的，key 会存在的，锁单一边会维护连续扫描五次，有可能会失效掉，为什么不用优先队列呢？ 所以的话，
   
   
 3.定时任务：
 时效性差，性能差。
   
   
 
 1.原生的能够支持原生队列，这里主要分为2个，rocketmq,rabbtimq 的化，如果支持15 分钟级别的，修改源码当中的10分钟，1o
 启动roketmq 启动之后，引入springboot-rabir mq 的包，生产者发送消息，消费者消费消息，丢到这个类，指的是延时级别，10s ,对应的10s 种之后告诉我们，
下完之后马上racketmq 之后，rocketmq 之后，我们去监听和接受发现on个消息，配置一个监听器，去监听消息，延时消息，消息发送，等待10s 之后消费，取消订单，
工作方式，消息的重试机制，基于我们的ACK机制，被拉取过来了，我在执行过程中，成功的服务上，ack 机制，但是呢，不保证，消费成功呢，状态不可知，视为无效的。
尝试的工作，内置的之后，5-10次数之后，才能 丢弃到成功队列。

ACK机制：
已经由于网络抖动把消息同时，同时会锁定2张表，重复消费的可能，没有更好的解决方案，主键会逐一的方法，唯一的表示呢，全局的ID ,哪些做法呢?
可以把reids+日期+平台+支付方式+原子自增序列号，UUID的方法，snowflak，重复消费的可能。

事务消息，开始保证删除购物车，两个操作，假设订单是一个订单库，购物车的化，通过发异步额去删除，先删除创建
订单呢，还是发消息？如果说，下单失败了，发消息失败了，能删除吗？发消息失败了，
使用事务消息。