运单服务
在该服务中用到了什么技术 --> 美团Leaf
什么是美团Leaf
美团Leaf是有美团开源的 , 用于处理分布式环境中保证ID的唯一性 , 通过该技术能够实现Id的全局唯一性 , 高可用性 , 趋势递增性以及容灾性.
美团leaf主要通过两种方式实现业务
- 雪花算法
该方式区别于传统的雪花算法 , 通过Zookeeper避免传统模式对时间戳的强依赖
- 号段模式
该模式通过数据库来实现字段的趋势递增与唯一性 , 但是区别于传统递增方案 , 美团Leaf通过缓存的方式大大减少对数据库的访问压力 , 并通过双buffer机制 , 提高容灾性避免突刺情况发生
概述调度服务是做什么的
调度服务是在快递员揽收快件之后 , 通过rabbitMQ接受快递员端发送的信息 , 通过订单生成运单并对相同路线的运单进行合并 , 放入相同队列中;
一. 订单是如何生成运单的?
- 幂等性校验
- 参数校验
- 唯一ID生成
- 路线查询
- 相同网点运单处理
二. 如何实现相同路线运单的合并
调度中心接收到运单消息后 , 判断运单的当前节点与下一个节点位置 , 通过指定前缀与两个节点ID拼接作为键 , 使用redis的list结构作为队列(从左插入 , 从右取出) , 同时按照相同模式运用set结构存储一份运单ID的信息队列用于幂等性判断
ps: 这里的运单合并并非采用全轨迹的合并 , 而是每次调度只针对当前节点与下个节点相同的运单进行合并 , 在该运输完毕后会重新更具节点信息规划调度任务
三. 调度中心的作用是什么
- 推动运单流转
- 调度车辆运输
- 分配快递员取派件
推动运单流转
当运单生成或者说某运单到达一个节点后都会通过RabbitMQ发送消息给调度中心 , 调度中心接搜到消息后会对运单进行处理 , 放入运输队列 , 推动物流进一步流转
调度车辆运输
调度中心会通过xxljob定时查询当前的空闲车辆分配运输任务
四. 运单有哪些核心字段
- 运单ID --> SL+十三位数字(通过美团Leaf生成)
- 当前节点
- 下一节点
- 运输路线
- 货物信息
你们的运单号是怎么生成的？如何确保性能？
由于快件运单号有其特殊的构成 , 如顺风(SL+13位数字) , 所以在我们的项目中也采取该种格式
但市场上现有的唯一ID方案并不能满足无码的需求 , 如UUID包含字母,而雪花算法需要19位都不满足 , 因此我们采用了美团Leaf组件生成唯一ID
美团Leaf是有美团开源的 , 用于处理分布式环境中保证ID的唯一性 , 通过该技术能够实现Id的全局唯一性 , 高可用性 , 趋势递增性以及容灾性.
美团leaf主要通过两种方式实现业务
- 雪花算法
该方式区别于传统的雪花算法 , 通过Zookeeper避免传统模式对时间戳的强依赖
- 号段模式
该模式通过数据库来实现字段的趋势递增与唯一性 , 但是区别于传统递增方案 , 美团Leaf通过缓存的方式大大减少对数据库的访问压力 , 并通过双buffer机制 , 提高容灾性避免突刺情况发生
双buffer机制:
假如我们设置的号段长度为1000 , 那么该机制就会取号段长度的10%作为阈值 , 一单达到该临界点就会调用一个异步线程再次生成1000的号段 . 在该机制的保护下就不会发生当号段被全部消耗完需要再次从数据库查询而造成延迟现象
能说一下订单转运单的业务逻辑吗？生成运单后如何与调度中心整合在一起的？
在快递员接收到用户快件后 , 在快递员端点击接受 , 就会发送消息给运单所在服务 , 接受到该消息后就会通过订单数据生成运单 , 具体流程如下
-
幂等性判断
因为订单与运单是一一对应关系 , 即一个订单只能生成一个运单 . 所以我们可以通过该关系使用订单号去运单表中查询判断是否已经存在 , 由此校验幂等性
-
通过传入的订单查询订单数据并对数据就行校验
-
通过美团Leaf生成运单ID
-
通过订单起始位置调用路线规划服务生成运输路线
-
封装所有数据保存运单
-
发送消息给调度中心处理运单调度
合并运单为什么使用Redis的List作为队列？如何确保消息的幂等性的？
合并运单为什么使用Redis的List作为队列？
- 使用redis作为队列可以避免集群环境中内存无法共享的问题
- Redis的List结构支持有方向存取数据 , 可以保证数据先后顺序
如何确保消息的幂等性的？
因为订单与运单是一一对应关系 , 即一个订单只能生成一个运单 . 所以我们可以通过该关系使用订单号去运单表中查询判断是否已经存在 , 由此校验幂等性
