CN112163002A - 一种跨境电商通关数据的处理方法和系统 - Google Patents

Abstract

本发明提供了一种一种跨境电商通关数据的处理方法和系统，涉及数据处理技术领域，主要解决了对电商数据的数据库进行解压的技术问题。该发明包括：后台服务器接收用户页面端发送的当前申报阶段的申报数据；后台服务器将申报数据作逻辑处理后，存储至数据库中；后台服务器在缓存中设置当前申报阶段的状态信息，以及，在数据库中设置当前申报阶段的状态信息；若当前申报阶段为非首次申报阶段，则后台服务器在缓存中提取上一申报阶段的状态信息，并将数据库中上一申请阶段的状态信息更新为提取出的状态信息。本发明将频繁需要进行修改的数据状态放到缓存中，等状态固定后，再保存到数据库，从而达到提高响应效率的目的。

Description

一种跨境电商通关数据的处理方法和系统

技术领域

本发明涉及数据处理技术领域，尤其涉及一种跨境电商通关数据的处理方法和系统。

背景技术

通常，跨境电商系统架构主要包含三部分：页面，后台，数据库。页面是和用户交互的界面，后台是处理页面的用户请求，如增删改查数据等。数据库则是用来长期存放用户数据的。此系统直接将用户数据保存到数据库，这是种常见且稳当的做法，在数据量和并发量都不高的情况下，这是一个最简单的系统架构。

然而，跨境电商的业务非常多，例如通关业务，其中所涉及的数据信息、操作信息和回执信息等，往往达到几十万甚至几百上千万条。所以，现有技术中，此系统的缺点是：随着用户数据量的增加，并发上升，数据库的压力就会增大。具体体现为：

(1)并发能力差。用户对数据的每次操作，都是直接更新到数据库。在高峰期时，如果数据库的同一条数据进行频繁修改，增加了额外的性能消耗。

(2)性能差。在数据入库阶段数据库为了要保证数据的一致性，所以在对数据进行修改时会对相关的数据进行上锁。频繁对数据库同一条数据进行修改，会延长锁等待的时间，导致数据库处理数据的效率降低，进而影响整个系统的响应速度。

(3)死锁频繁。如频繁对同一行数据进行修改，就会出现争夺锁的情况，如果涉及需要修改的数据很多很复杂，则还有数据库表死锁的几率，严重时会出现死锁的表无法插入数据。

发明内容

本发明其中一个目的是为了提出一种跨境电商通关数据的处理方法和系统，解决了现有技术中对电商数据的数据库进行解压的技术问题。本发明优选实施方案中能够达到诸多有益效果，具体见下文阐述。

为实现上述目的，本发明提供了以下技术方案：

本发明的一种跨境电商通关数据的处理方法，其包括：

后台服务器接收用户页面端发送的当前申报阶段的申报数据；

所述后台服务器将所述申报数据作逻辑处理后，存储至数据库中；

所述后台服务器在缓存中设置所述当前申报阶段的状态信息，以及，在所述数据库中设置所述当前申报阶段的状态信息；

若所述当前申报阶段为非首次申报阶段，则所述后台服务器在缓存中提取上一申报阶段的状态信息，并将所述数据库中上一申请阶段的状态信息更新为所述提取出的状态信息。

进一步的，还包括：

所述后台服务器获取所述当前申报阶段的审核信息，并在所述缓存中，将所述当前申报阶段的状态信息更新为所述审核信息。

进一步的，还包括：

若所述当前申报阶段为最后一次申报阶段，则所述后台服务器，在所述数据库中，将所述当前申报阶段的状态信息更新为所述审核信息。

进一步的，所述后台服务器获取所述当前申报阶段的审核信息，包括：

所述后台服务器接收海关的反馈数据，所述反馈数据中包含所述当前申报阶段的审核信息；

所述后台服务器从所述反馈数据中获取所述当前申报阶段的审核信息。

进一步的，所述反馈数据包括：回执数据；或者，状态同步数据。

进一步的，所述反馈数据的数据标识为第一数据标识，所述缓存和所述数据库中的数据的数据标识为第二数据标识，所述方法还包括：

所述后台服务器建立所述第一数据标识与所述第二数据标识之间的对应关系，并将所述对应关系存储到所述缓存中，以根据所述对应关系对所述反馈数据对应的数据进行处理。

进一步的，所述第一数据标识包括：企业编码和订单号；和/或，

所述第二数据标识包括：整车数据标识和清单标识；和/或，

所述对应关系在缓存中采用键值结构存储，其中，关键词为所述第一数据标识，值为所述第二数据标识。

进一步的，所述缓存中的数据结构为键值结构或者哈希表结构。

进一步的，所述申报阶段包括：三单申报阶段、清单申报阶段、总分单申报阶段、离境单申报阶段。

本发明的一种跨境电商通关数据的处理系统，其包括：

用户页面端，后台服务器，缓存和数据库；

所述用户页面端，用于发送的当前申报阶段的申报数据；

所述后台服务器，用于接收所述申报数据；将所述申报数据作逻辑处理后，存储至数据库中；在缓存中设置所述当前申报阶段的状态信息，以及，在所述数据库中设置所述当前申报阶段的状态信息；若所述当前申报阶段为非首次申报阶段，则所述后台服务器在缓存中提取上一申报阶段的状态信息，并将所述数据库中上一申请阶段的状态信息更新为所述提取出的状态信息。

本发明提供的一种跨境电商通关数据的处理方法和系统至少具有如下有益技术效果：

通过当前申报阶段的状态信息缓存的方法，将频繁需要进行修改的数据状态放到缓存中，等状态固定后，再保存到数据库，从而达到提高响应效率的目的。因为缓存的数据处理时在硬件的内存中进行，所以效率比在数据库中做数据处理要高很多。本发明还具有以下优点：

1.降低对数据库数据的操作次数，减少不必要的并发请求。通过本发明，并发的请求在缓存中就可以得到处理，无需频繁发送请求给数据库。

2.提高系统性能，减少数据库的压力。通过本发明，将本来需要读写磁盘的操作，变成只需要读写内存，提高响应速度。

3.避免数据库死锁，降低数据库卡死的风险。通过本发明，减少在数据库中反复修改数据的频率，基本是等数据的状态稳定后才请求数据库进行数据保存，所以可以有效减少死锁的出现。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明的跨境电商通关数据的处理方法的流程示意图；

图2是本发明的跨境电商通关数据的处理系统的结构示意图。

图中1-用户页面端，2-后台服务器，3-缓存，4-数据库。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将对本发明的技术方案进行详细的描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施方式，都属于本发明所保护的范围。

参见图1，本发明的一种跨境电商通关数据的处理方法，其包括：

S1：后台服务器接收用户页面端发送的当前申报阶段的申报数据；

S2：所述后台服务器将所述申报数据作逻辑处理后，存储至数据库中；

S3：所述后台服务器在缓存中设置所述当前申报阶段的状态信息，以及，在所述数据库中设置所述当前申报阶段的状态信息；

S4：若所述当前申报阶段为非首次申报阶段，则所述后台服务器在缓存中提取上一申报阶段的状态信息，并将所述数据库中上一申请阶段的状态信息更新为所述提取出的状态信息。

需要说明的是，用户页面端是跟用户交互的界面，用于显示提示性文字，展示数据等；

后台服务器是对用户页面端提交的申报数据进行逻辑处理，如数据校验，数据补填，数据匹配等；将申报数据作逻辑处理后，存储至数据库中，并在数据库中设置当前申报阶段的状态信息；将当前申报阶段的状态信息放入缓存中。

本发明通过当前申报阶段的状态信息缓存的方法，将频繁需要进行修改的数据状态放到缓存中，等数据状态固定后，再保存到数据库，从而达到提高响应效率的目的。因为缓存的数据处理时在硬件的内存中进行，所以效率比在数据库中做数据处理要高很多。

本发明还包括：

所述后台服务器获取所述当前申报阶段的审核信息，并在所述缓存中，将所述当前申报阶段的状态信息更新为所述审核信息。

优选地，所述后台服务器获取所述当前申报阶段的审核信息，包括：

所述后台服务器接收海关的反馈数据，所述反馈数据中包含所述当前申报阶段的审核信息；

所述后台服务器从所述反馈数据中获取所述当前申报阶段的审核信息。

优选地，所述反馈数据包括：回执数据；或者，状态同步数据。

本发明还包括：

若所述当前申报阶段为最后一次申报阶段，则所述后台服务器，在所述数据库中，将所述当前申报阶段的状态信息更新为所述审核信息。

需要说明的是，用户在用户页面端操作当前申报阶段的申报数据，即用户申报三单(指申报订单，运单和支付单)，后台服务器将申报数据进行逻辑处理，存储至数据库，并将此申报数据的“已申报”状态存储至数据库，还将此申报数据的“已申报”状态存储至缓存。

海关收到申报数据后，对申报数据进行审核，通过用户页面端发送对申报数据的反馈数据，反馈数据中包含审核信息。若审核通过，则后台服务器将缓存中的申报数据的“已申报”状态更新为“审核通过”状态，并同步更新至数据库，即将数据库中的申报数据的“已申报”状态更新为“审核通过”状态。若审核不通过，则后台服务器不更新缓存中和数据库的申报数据的“已申报”状态，且反馈回执数据至用户页面端，以使用户重新操作当前申报阶段的申报数据。

其中，涉及海关中对申报数据的多段审核，此处以两段审核为例，具体过程如下：

若第一段审核通过，则后台服务器将缓存中的申报数据的“已申报”状态更新为“第一段审核通过”状态，进行第二段审核(此时，数据库的申报数据的状态不做任何操作)。若第一段审核不通过，则后台服务器不更新缓存中和数据库的申报数据的“已申报”状态，且反馈回执数据至用户页面端，以使用户重新操作当前申报阶段的申报数据。

若第二段审核通过，则后台服务器将缓存中的申报数据的“第一段审核通过”状态更新为“第二段审核通过”状态，并同步更新至数据库，即将数据库中的申报数据的“第一段审核通过”状态更新为“第二段审核通过”状态(此时，第二段审核为最后一次申报阶段，则需要将缓存中的申报数据的状态同步更新至数据库)。若第二段审核不通过，则后台服务器不更新缓存中和数据库的申报数据的“已申报”状态，且反馈回执数据至用户页面端，以使用户重新操作当前申报阶段的申报数据。

本发明的缓存使用的服务是Redis，其原理如下：

所述反馈数据的数据标识为第一数据标识，所述缓存和所述数据库中的数据的数据标识为第二数据标识，所述方法还包括：

所述后台服务器建立所述第一数据标识与所述第二数据标识之间的对应关系，并将所述对应关系存储到所述缓存中，以根据所述对应关系对所述反馈数据对应的数据进行处理。

其中，所述第一数据标识包括：企业编码和订单号；和/或，

所述第二数据标识包括：整车数据标识和清单标识；和/或，

所述对应关系在缓存中采用键值结构存储，其中，关键词为所述第一数据标识，值为所述第二数据标识。

优选地，所述缓存中的数据结构为键值结构或者哈希表结构。

优选地，所述申报阶段包括：三单申报阶段、清单申报阶段、总分单申报阶段、离境单申报阶段。

需要解释的是，三单申报阶段中的三单为申报订单，运单和支付单。

需要说明的是，缓存中存储了第一数据标识与第二数据标识之间的对应关系，第一数据标识包括：企业编码和订单号，第二数据标识包括：整车数据标识(以下简称uecId)和清单标识(以下检查id)。

缓存使用的服务是Redis。使用的是键值结构(简称key-value)和哈希表(hash表)这两种数据结构。具体数据结构设置如下：

(1)key-value结构设置值：set key value，如set testKey testValue。

(2)key-value结构取值：get key返回对应的value，如get testKey则根据(1)的设值会返回testValue。

(3)hash表结构设置值：hset hash field value，如hset testHash testFieldtestHashValue。

(4)hash表结构取值：hget hash field返回对应的value，如hget testHashtestField则根据(3)的设值会返回testHashValue。

假设现在有企业4419960123的用户，保存了一份提运单号为520020200813的一车数据，其中只含有一份清单的订单号为202008131357(一个订单号指向一份清单数据)。保存到数据库后，对应的整车数据标识uecId为520020200813，清单标识id则为202008131357。

在缓存中存放订单号和清单标识id对应关系使用的数据结构为key-value，key格式为：企业编码_订单号，即4419960123_202008131357；value格式为：整车数据标识id_清单标识id，即520020200813_202008131357。

在缓存中存放申报数据的状态信息使用的数据结构是hash表，hash的格式是uecId_status，以订单状态为例，即520020200813_status；field的值为清单标识id，即202008131357；value的值为单据状态。

用户的申报数据的处理流程：

用户申报三单，其实是指申报订单，运单和支付单。由于这三单是可以并行申报的，数据的处理方式也类似，所以用订单为例进行原理说明。

步骤1，申报订单时，用户提交的是一个含有uecId的请求。假设此时uecId＝520020200813，后台根据uecId的值到数据库中查出对应的数据，数据中就包含id，企业编码和订单编号。

步骤2，因为申报三单是申报的第一阶段，此时只需将订单的状态设置为已申报(status＝1)，并存入缓存中(运单和支付单与订单类似)。此处涉及两条请求Redis的命令：

set 4419960123_202008131357 520020200813_202008131357

hset 520020200813_status 202008131357 1

步骤3，后台服务器更新数据库中该数据的三单状态。

完成以上步骤后，此时，缓存和数据库中，该单的三单状态都是已申报。

海关返三单回执/三单状态同步的处理流程：

海关反馈的回执数据或者状态同步数据本质上是一样的，只是数据来源不同。回执数据是海关根据申报数据返回的处理结果，处理结果同时也会在对应的海关页面显示，而状态同步数据的就是海关页面的数据，又因为三单的流程类似，所以以订单回执为例说明原理。

订单的回执数据是以企业编码和订单号对应订单的申报数据，同时回执数据包含了对申报数据的处理状态。所以回执数据的处理实际上就是根据回执数据中的处理状态，查询原申报数据，将原申报数据中的状态信息更新为回执数据中的状态信息。

后台服务器读取回执数据中的企业编码(4419960123)，单号(202008131357)和状态(假设状态是3，表示审核通过)，用于更新缓存。

然后，先从缓存中的根据企业编码和单号查询对应的uecId和id对应的订单的状态信息更新为回执数据中的状态信息。此处和Redis服务的交互如下：

get 4419960123_202008131357，Redis返回520020200813_202008131357

hget 520020200813_status 202008131357，Redis返回1

后台服务器判断1是已申报状态，待更新的状态是3审核通过状态，可以覆盖原有的1，则hset 520020200813_status 202008131357 3。

此时完成了缓存中的申报数据的状态信息更新，即缓存中的订单状态是审核通过，而数据库中的订单状态依旧是已申报。

用户申报清单的数据处理流程：

步骤1，申报清单时，用户通过页面提交uecId到后台，假设uecId＝520020200813，则后台服务器根据uecId查询该清单的企业编码，订单号和id等信息。

和缓存Redis服务的交互包括：

set 4419960123_202008131357 520020200813_202008131357，设置企业编码和订单号与uecId和id的关系(实际上申报清单时不用这一步，因为在申报订单时已经操作过，不必重复设置，但是为了说明步骤，此处还是写上)；

hget 520020200813_status 202008131357

查询缓存中的上一阶段单据的状态。

hset 520020200813_status 202008131357 1

设置清单状态为已申报；

步骤2，更新数据库中的清单状态。

步骤3，海关返清单回执/清单状态同步，更新缓存中的清单状态是海关回执中的状态，数据库的清单状态依旧是已申报。

剩下阶段的申报数据处理流程：

(1)和前面几个阶段是处理流程类似，都是先将上一阶段的数据状态取出，现阶段数据状态设置为已申报。同时将状态保存到数据库。回执回来时，将本阶段数据的缓存状态更新。

(2)因为申报离境单是最后的一个阶段，所以会在更新缓存的同时更新数据中的离境状态。最终处理完离境的回执后，数据库和缓存中这一单的所有状态都是一致的。

然而，实际线上环境的情境会相对复杂，与原理中出现的流程可能有些许不同：

(1)比如会有申报了下一阶段，发现上一阶段有些单的数据不符合申报下一阶段的条件，只能重新修改上一阶段的单，重新申报，这时上一阶段的状态会从成功改为已申报再重复原来的流程。

(2)整车数据中包含电商企业信息，申报企业信息，物流企业信息等。通常这些企业信息是同一个企业。但实际线上有部分企业只能申请到电商资质所以只能申报订单支付单清单等。申报运单需要另外的企业信息，所以这两个企业信息有所不同。但是在说明原理时为了方便理解，就不做区分。

(3)整车数据中一般不止包含一份清单数据，但是为了说明原理，就只按一份处理。

还有，本发明中使用的缓存服务是Redis，可以用其他主流的缓存服务代替，如Memcached等。

本发明所使用的Redis中数据结构对应的内容不是唯一的。如所使用的key-value，本发明在三单阶段和清单阶段中定的key格式是企业编码_单号，key在这里的作用只是区分于Redis中的其他key，可以在key的格式加上其他常量，如aa_企业编码_单号等；还可以对企业编码和单号进行顺序的调整，如aa_单号_企业编码等；还可以对分割符“_”替换为“__”等。而value存放的格式是uecId_id，无论是顺序还是分隔符，都是可以做适当的修改和替换。这些值的设置是为了逻辑上区分数据的唯一性，因此格式不是唯一的。

参见图2，本发明的一种跨境电商通关数据的处理系统，其包括：

用户页面端1，后台服务器2，缓存3和数据库4；

所述用户页面端1，用于发送的当前申报阶段的申报数据；

所述后台服务器2，用于接收所述申报数据；将所述申报数据作逻辑处理后，存储至数据库4中；在缓存3中设置所述当前申报阶段的状态信息，以及，在所述数据库4中设置所述当前申报阶段的状态信息；若所述当前申报阶段为非首次申报阶段，则所述后台服务器在缓存3中提取上一申报阶段的状态信息，并将所述数据库4中上一申请阶段的状态信息更新为所述提取出的状态信息。

本发明将频繁需要进行修改的数据状态放到缓存中，等状态固定后，再保存到数据库，从而达到提高响应效率的目的。因为缓存的数据处理时在硬件的内存中进行，所以效率比在数据库中做数据处理要高很多。本发明降低对数据库数据的操作次数，减少不必要的并发请求；提高系统性能，减少数据库的压力；还避免数据库死锁，降低数据库卡死的风险。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种跨境电商通关数据的处理方法，其特征在于，包括：

后台服务器接收用户页面端发送的当前申报阶段的申报数据；

所述后台服务器将所述申报数据作逻辑处理后，存储至数据库中；

所述后台服务器在缓存中设置所述当前申报阶段的状态信息，以及，在所述数据库中设置所述当前申报阶段的状态信息；

若所述当前申报阶段为非首次申报阶段，则所述后台服务器在缓存中提取上一申报阶段的状态信息，并将所述数据库中上一申请阶段的状态信息更新为所述提取出的状态信息。

2.根据权利要求1所述的处理方法，其特征在于，还包括：

所述后台服务器获取所述当前申报阶段的审核信息，并在所述缓存中，将所述当前申报阶段的状态信息更新为所述审核信息。

3.根据权利要求2所述的处理方法，其特征在于，还包括：

若所述当前申报阶段为最后一次申报阶段，则所述后台服务器，在所述数据库中，将所述当前申报阶段的状态信息更新为所述审核信息。

4.根据权利要求2所述的处理方法，其特征在于，所述后台服务器获取所述当前申报阶段的审核信息，包括：

所述后台服务器接收海关的反馈数据，所述反馈数据中包含所述当前申报阶段的审核信息；

所述后台服务器从所述反馈数据中获取所述当前申报阶段的审核信息。

5.根据权利要求4所述的处理方法，其特征在于，所述反馈数据包括：回执数据；或者，状态同步数据。

6.根据权利要求4所述的处理方法，其特征在于，所述反馈数据的数据标识为第一数据标识，所述缓存和所述数据库中的数据的数据标识为第二数据标识，所述方法还包括：

所述后台服务器建立所述第一数据标识与所述第二数据标识之间的对应关系，并将所述对应关系存储到所述缓存中，以根据所述对应关系对所述反馈数据对应的数据进行处理。

7.根据权利要求6所述的处理方法，其特征在于，

所述第一数据标识包括：企业编码和订单号；和/或，

所述第二数据标识包括：整车数据标识和清单标识；和/或，

所述对应关系在缓存中采用键值结构存储，其中，关键词为所述第一数据标识，值为所述第二数据标识。

8.根据权利要求1所述的处理方法，其特征在于，所述缓存中的数据结构为键值结构或者哈希表结构。

9.根据权利要求1-8任一项所述的处理方法，其特征在于，所述申报阶段包括：三单申报阶段、清单申报阶段、总分单申报阶段、离境单申报阶段。

10.一种跨境电商通关数据的处理系统，其特征在于，包括：

用户页面端，后台服务器，缓存和数据库；

所述用户页面端，用于发送的当前申报阶段的申报数据；

所述后台服务器，用于接收所述申报数据；将所述申报数据作逻辑处理后，存储至数据库中；在缓存中设置所述当前申报阶段的状态信息，以及，在所述数据库中设置所述当前申报阶段的状态信息；若所述当前申报阶段为非首次申报阶段，则所述后台服务器在缓存中提取上一申报阶段的状态信息，并将所述数据库中上一申请阶段的状态信息更新为所述提取出的状态信息。

Images