超级快递——如何用系统来保证快递准时送达

本文涉及的产品
对象存储 OSS,20GB 3个月
文件存储 NAS,50GB 3个月
日志服务 SLS,月写入数据量 50GB 1个月
简介: 随着电商的发展,人们对快递的准时性的要求不断提高,而日增量数以亿级的快递状态信息的存储、异常状态的检测都是令人头疼的问题。在本文中,我们使用分布式NoSQL数据库TableStore与全托管的消息服务来解决这个难题。

去年,一部《超级快递》给大家带来了不少欢乐,除了欢笑,我们也看到了准时送达作为一种增值服务或者高端服务在快递物流行业中可能性和市场。而每天上亿的快递数量靠人肉来保证已经几无可能,在这里,我们从系统的角度来看看如何搭建一个保证快递能够准时到达的系统。

要保证快递能准时到达收件人手里,就需要能够主动及时的发现那些可能会迟到的快递,并在第一时间进行查看和处理,比如联系到快递小哥确认状态等等。

在这里,我们将快递在整个流转的过程进行拆分,当快递达到一个状态之后,确定下一个状态以及达到时间,在规定的时间内没有到达则需要通知相关的负责人进行处理,我们将快递的每一次状态的更新都写入数据库中,然后采取下面两种方案进行简单的处理:

方案一

每次更新快递的状态时与前一次状态进行比较,中间的时间差超出期望时间则报警。

ems_solution1

方案二

定时对所有的快递状态进行检查,最近一次状态更新的时间距当前时间超出期望则报警。

ems_solution2

__方案一__只在快递更新时做处理,对系统的压力最小,但是需要依赖快递的到达时间触发,时效性太差,快递到的越晚就越晚才发现快递迟到,往往是发现快递不能准时送达的时候快递就已经迟到了。

__方案二__发现可能迟到的快递的时效性取决去检查的周期,最坏情况下就是快递在检查之后马上就超时了,等到下次检查才能发现,而且对日均千万甚至亿级别的快递状态进行存储本来就是一个非常头疼的问题,再扫全库进行查询又会大大增加数据库的负担,很有可能查询的时间就会超过快递的超时时间。

所以,我们选用了阿里云的表格存储消息服务的延时队列功能来解决这个难题。

快递状态存储

首先,我们将快递的每一个状态都存储在表格存储中。

表格存储很好的解决了数据规模与读写并发上的问题,单表能够支撑到万亿级数据规模,自动负载均衡能够让用户不需要做任何动作就可以将数据表的读写并发扩展到百万级别,按量付费又可以避免资源的浪费。同时,读写性能不受数据规模的影响,也不用担心数据积累之后的性能问题。

异常快递检测机制

ems_solution_ots

首先,我们根据业务情况在消息服务上创建多个不同的队列,每个队列设置不同的DelaySeconds,进入该队列的消息将在设置的DelaySeconds之后才会被消费者取到。

在每一个快递状态更新时,一方面将该快递状态写入到表格存储中,以提供实时在线查询。同时,根据快递状态的超时时间创建一条消息,包括快递单号、超时时间等信息,将该消息发送到对应的队列中,比如处于揽件的某个快递需要在2小时内到达中转站,则将该快递的信息push进 __2小时揽件队列__。

超时检查系统从上述队列中取消息进行检查,根据消息中的 快递单号 在表格存储中查询该快递的最近一次状态信息,如果查到的最新状态时间大于消息中的时间,则说明该快递在超时时间内达到了下一个状态,否则该快递则有不能按时到达的风险,迅速进行报警处理。

架构优势

  1. 表格存储消息服务都是高并发、按量付费产品,不需要评估业务的访问情况,再购买相应的规格,按量付费也不会出现资源的浪费。
  2. 表格存储的高并发优势可以在几十万的QPS下依然提供毫秒级的读写延时,从容应对超时检查系统以及来自真实用户的快递查询需求。
  3. 快递到达超时时间之后能够立刻被消费者也就是超时检查系统看到,大大提高了处理的实时性。
  4. 一个队列可以对应多个消费者,每个消息只会被一个消费者取到,所以查看队列里面的消息堆积情况,包括未到唤醒时间的消息和已经唤醒等待处理的消息数量,当等待处理的消息数量过多则说明系统处理的慢了,这个时候就可以动态增加处理节点了,节点间没有状态引入,直接去获取消息时间处理即可,部署架构又大大简化。
相关实践学习
消息队列+Serverless+Tablestore:实现高弹性的电商订单系统
基于消息队列以及函数计算,快速部署一个高弹性的商品订单系统,能够应对抢购场景下的高并发情况。
阿里云表格存储使用教程
表格存储(Table Store)是构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务,根据99.99%的高可用以及11个9的数据可靠性的标准设计。表格存储通过数据分片和负载均衡技术,实现数据规模与访问并发上的无缝扩展,提供海量结构化数据的存储和实时访问。 产品详情:https://www.aliyun.com/product/ots
相关文章
|
6月前
|
JavaScript Java 新能源
基于Java的新能源充电系统的设计与实现(亮点:完整合理的充电流程,举报反馈机制、余额充值、在线支付、在线聊天)
基于Java的新能源充电系统的设计与实现(亮点:完整合理的充电流程,举报反馈机制、余额充值、在线支付、在线聊天)
275 1
|
消息中间件 JavaScript 小程序
支付系统就该这么设计,稳的一批!!
支付系统就该这么设计,稳的一批!!
|
机器人
电话机器人并发与OKCC呼叫并发是什么?
在语音通信领域,呼叫并发是一个常用但并不友好的名词,往往叫人难以理解,也不知道有什么作用。 呼叫并发,通俗讲,是指系统上同时进行的呼叫数量。 那么,与通信系统上的用户数量有什么区别呢?
|
安全
程序人生 - 防疫期间能不能点外卖
程序人生 - 防疫期间能不能点外卖
103 0
程序人生 - 防疫期间能不能点外卖
|
API 定位技术 数据安全/隐私保护
“电话回拨”模式,能解决O2O最后一公里痛点吗?
“电话回拨”模式,能解决O2O最后一公里痛点吗?
|
存储 运维 负载均衡
如何保障“双11”期间亿万买家和卖家愉快地聊天
在刚刚过去的 2020 双 11 购物节,Tablestore 第一次全面支持集团 IM(钉钉、手淘&天猫&千牛客服聊天、饿了么等)并平稳度过,保障亿万买家和卖家之间更为顺畅的交流。本文将介绍钉钉 IM 存储架构、表格存储 Tablestore 为了满足迁移在稳定性、功能、性能上做的一系列工作。
5040 0
如何保障“双11”期间亿万买家和卖家愉快地聊天
|
双11 数据库
提前拆快递的快乐来了​!
今天,我们都是尾款人!!!
5840 0
提前拆快递的快乐来了​!
|
机器学习/深度学习 自然语言处理 供应链
履约时间预估:如何让外卖更快送达?
相信大部分人都有点过外卖的经历。在饿了么,为了让骑手能够准时准点将外卖送到每位用户的手中,让每位用户吃上一口热乎饭,阿里本地生活智慧物流团队对外卖履约时间预估这一问题进行了深入研究,并给出了有效的解决方案,本文将为大家做一个简要介绍。
1587 0
履约时间预估:如何让外卖更快送达?
|
供应链 API
在平台上添加发快递上门取件的功能-快递物流上门取件API对接
上门取件,是电商平台为寄件用户提供的通过一键下单到快递员,并在2小时上门取件的寄件服务。适用于散客在线寄件、电商退货上门取件等业务场景;通过API指令由系统自动将消息发送给物流公司和快递员,由快递员上门取货揽件与在线收款; 快递鸟上门预约取件api接口 解决寄件客户不用线下找快递员、不用苦苦等待,通过上门取件服务让客户可以轻松选择约定时间、地点完成寄件需求。
1779 0
在平台上添加发快递上门取件的功能-快递物流上门取件API对接