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

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

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

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

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

方案一

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

ems_solution1

方案二

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

ems_solution2

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

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

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

快递状态存储

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

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

异常快递检测机制

ems_solution_ots

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

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

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

架构优势

  1. 表格存储消息服务都是高并发、按量付费产品,不需要评估业务的访问情况,再购买相应的规格,按量付费也不会出现资源的浪费。
  2. 表格存储的高并发优势可以在几十万的QPS下依然提供毫秒级的读写延时,从容应对超时检查系统以及来自真实用户的快递查询需求。
  3. 快递到达超时时间之后能够立刻被消费者也就是超时检查系统看到,大大提高了处理的实时性。
  4. 一个队列可以对应多个消费者,每个消息只会被一个消费者取到,所以查看队列里面的消息堆积情况,包括未到唤醒时间的消息和已经唤醒等待处理的消息数量,当等待处理的消息数量过多则说明系统处理的慢了,这个时候就可以动态增加处理节点了,节点间没有状态引入,直接去获取消息时间处理即可,部署架构又大大简化。
相关实践学习
阿里云表格存储使用教程
表格存储(Table Store)是构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务,根据99.99%的高可用以及11个9的数据可靠性的标准设计。表格存储通过数据分片和负载均衡技术,实现数据规模与访问并发上的无缝扩展,提供海量结构化数据的存储和实时访问。 产品详情:https://www.aliyun.com/product/ots
相关文章
|
存储 消息中间件 NoSQL
亿级消息系统的核心存储:Tablestore发布Timeline 2.0模型
互联网快速发展的今天,社交类应用、消息类功能大行其道,占据了大量网络流量。大至钉钉、微信、微博、知乎,小至各类App的推送通知,消息类功能几乎成为所有应用的标配。根据场景特点,我们可以将消息类场景归纳成三大类:IM(钉钉、微信)、Feed流(微博、知乎)以及常规消息队列。
16924 0
|
存储 NoSQL 应用服务中间件
如何高效存储海量GPS数据
GPS数据使用越来越广,但如何高性能存储海量GPS数据仍然具有挑战,本文会介绍一种非常适合存储GPS数据的存储系统:阿里云NoSQL数据库TableStore,同时会介绍多个不同场景的技术方案。
23833 0
|
存储 NoSQL 开发工具
基于Tablestore实现海量摩托车轨迹管理
基于TableStore轻松实现亿量级轨迹管理与地理围栏
7076 0
基于Tablestore实现海量摩托车轨迹管理
|
存储 SQL 传感器
基于 Tablestore 时序存储的物联网数据存储方案
背景物联网时序场景是目前最火热的方向之一。海量的时序数据如汽车轨迹数据、汽车状态监控数据、传感器实时监控数据需要存放进入数据库。一般这类场景下存在如下需求数据高写入,低读取需要对写入数据进行基础的图表展示对写入数据进行聚合分析传统的关系型数据库并不适合此类场景,时序数据库脱颖而出。表格存储时序实例支持时序数据的存储,其具有如下特点:Serverless,分布式,低成本高写入支持优秀的索引能力对数据
1799 0
基于 Tablestore 时序存储的物联网数据存储方案
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
背景订单系统存在于各行各业,如电商订单、银行流水、运营商话费账单等,是一个非常广泛、通用的系统。对于这类系统,在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展,以及各企业对数据的重视,需要存储和持久化的订单量越来越大,数据的重视程度与数据规模的膨胀带来了新的挑战。首先,订单量对于数据的存储、持久化、访问带来了挑战,这不仅增加了开发面对的困难,也为系统的运维带来了挑战。其次,随着大数据技
3348 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
|
NoSQL 数据库 索引
海量结构化数据存储技术揭秘:Tablestore表设计最佳实践
前言 表格存储Tablestore是阿里云自研的面向海量结构化数据存储的Serverless NoSQL多模型数据库。在处理海量数据时,方案设计非常重要,合理的设计才能够发挥出数据库的性能水平。本文主要介绍Tablestore在表设计方面的一些实践经验,供大家参考。
10749 1
|
存储 消息中间件 NoSQL
现代IM系统中的消息系统架构 - 架构篇
前言 IM全称是『Instant Messaging』,中文名是即时通讯。在这个高度信息化的移动互联网时代,生活中IM类产品已经成为必备品,比较有名的如钉钉、微信、QQ等以IM为核心功能的产品。当然目前微信已经成长为一个生态型产品,但其核心功能还是IM。
28217 3
|
存储 NoSQL 关系型数据库
药品监管系统架构揭秘:海量溯源数据存储与查询
前言 在刚刚过去的2018年,“毒疫苗”事件再次触及了大众的敏感神经,因为十年前的“毒奶粉”事件还历历在目。我们急需创建一个全国性的药品(食品)监控追踪体系。与此同时,近年来随着国家对医药行业的大力支持,中国的医疗事业也出现了跨越式的发展,大量的新型药品上市,极大的丰富了患者和消费者的选择范围。
7033 1