一种解决高并发下数据错误的系统和方法与流程

1.本发明涉及软件开发领域，特别涉及一种解决高并发下数据错误的系统和方法。


背景技术：

2.随着网购的发展，抢购活动越来越多，互联网时代各种电商活动飞速发展，抢购秒杀等开始广泛地应用到各个领域之中。在这种情况下由于系统的瓶颈易发生数据错误。本发明公开了一种高效解决高并下库存增减库问题的系统和方法，该系统包括累加、校验、累加撤销、爆点活动redis缓存刷新、白名单等服务。从而能灵活管理商品数据,节省本地硬盘开销,满足用户对应用数据的特定需求。


技术实现要素：

3.本发明要解决的技术问题是克服现有技术的缺陷，提供一种解决高并发下数据错误的系统和方法。
4.本发明提供了如下的技术方案：
5.本发明提供一种解决高并发下数据错误的系统和方法，包括以下方案：
6.一、累加功能技术技术方案：
7.在做返利链路时，将活动、权益、商户、门店、手机号、设备号、客户号等维度进行校验并累加操作；
8.二、校验功能技术方案：
9.在做预查询链路时，需先判断活动、权益、商户、门店、手机号、设备号、客户号等维度是否有参与返利资格；
10.三、累加撤销功能技术方案：
11.针对已经做过累加交易或者累加超时的场景，需做累加撤销操作；
12.四、爆点活动redis缓存刷新能力技术方案：
13.做大型促销活动时，在活动开始前将对应的活动、权益、商户、门店组装成rediskey刷新至redis中，累加值为0，保证活动开展时redis有值，走redis累加逻辑；
14.五、marketing-limit-center白名单功能(活动管控)技术方案：
15.活动、工具配置时，会同步活动管控活动基本信息，活动管控根据apollo配置的时间判断白名单链路；
16.累加功能技术方案具体包括以下(如图1所示)：
17.(1)用户购买抢购商品时进入系统通过活动、权益、商户、门店建立redis热点维度；
18.(2)结合热度维度和组装掉规则中心获取静态配置信息(维度金融、笔数、活动结束时间)并查询规则详情；
19.(3)根据规则中心返回的结果先查询redis进行check(判断redis、累加表的金额与配置的金额笔数)其中要进行rediskey是否存在，不存在则查询累加表获取最后更新时
间(加redis锁)；判断当前时间与最后更新时间；若不是同一天则认为是第一笔交易，redis直接插入；若是同一天则认为redis失效，进行补偿操作；
20.注：每天11点定时任务跑t 1日redis刷新(刷新每一天第一笔的日维度、每月第一笔的月维度)；
21.(4)数据正常则落交易明细表(状态为ini)；
22.(5)热点维度redis校验累加，increby做累加操作，并判断累加后的数据是否超成本(redis不存在则数据库校验累加，做redis补偿)；
23.(6)redis补偿(加redis锁)(redis高可用情况，理论上无需补偿):开线程并发查询所有库中状态为init的交易明细表获取金额、笔数 累加表数据 当前累加金额、笔数，补偿至redis中；
24.(7)redis过期时间计算方式:
25.a)日维度固定两天 随机数过期；
26.b)月维度取当前日与当月月底的时间差 随机值；
27.c)周期维度取当日与活动结束时间的时间差 随机值(若活动延期则接受配置中心信息变更kafka做延期操作)；
28.(8)成功：
29.非热点维度数据库校验累加(乐观锁判断)(累加明细表存在则更新，不存在则插入)(开线程将热点维度数据累加至累加明细表(累加失败落异常推进表)，累加成功则更新交易流水表状态为成功)；
30.(9)失败：
31.失败返回(若之前有累加成功操作，则开线程做累加撤销，更新交易明细表状态为失败，撤销失败落异常推进表)(注意:开线程做累加撤销时，热点维度只需撤销redis数据，无需操作数据库)；
32.校验功能技术方案如下(如图2所示)：
33.(1)组装调规则中心查询接口请求参数；
34.(2)热度维度查询redis(redis不存在不做补偿)，非热度维度查询数据库；
35.分片核心技术方案如下(如图3所示)：
36.(1)业务开始进入分片功能；
37.(2)根据前置逻辑计算的值进入对应的service进行数据的变更，将请求参数存入command返回对应的结果给用户；
38.(3)command根据用户的状态：成功-储存到对应的数据库中，失败-监控所有的服务内数量对最多的进行减半处理并加到数据量最少的服务内,直到没用用户数据可以储存或达到阈值将所用服务的剩余数量同步到数据库中；
39.累加撤销功能技术方案(如图4所示)：
40.(1)根据原请求三要素查询交易明细表，判断原单是否存在、原单状态以及原单累加金额(撤销金额不得大于累加金额)；
41.(2)落交易明细表(init状态)；
42.(3)发送自产自销kafka消息；
43.(4)接受自产自销kafka消息；
44.(5)热点维度redis校验累加撤销，加锁做累加撤销操作(redis不存在则数据库累加撤销，不做redis补偿)(开线程将热点维度数据累加撤销至累加明细表(累加撤销失败落异常推进表)，累加成功则更新交易流水表状态为成功)；
45.(6)非热点维度数据库累加撤销。
46.与现有技术相比，本发明的有益效果如下：
47.本发明将逻辑根据业务需求灵活增大减少对应应用的服务数量；多个应用分担整个业务的压力；增加了数据维度提高效率；多应用配合可根据场景灵活调度。
附图说明
48.附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
49.图1是本发明的累加功能技术方案图；
50.图2是本发明的校验功能技术方案图；
51.图3是本发明的分片核心技术方案图；
52.图4是本发明的累加撤销功能技术方案图。
具体实施方式
53.以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件。
54.实施例1
55.如图1-4，本发明提供一种解决高并发下数据错误的系统和方法，包括以下方案：
56.一、累加功能技术技术方案：
57.在做返利链路时，将活动、权益、商户、门店、手机号、设备号、客户号等维度进行校验并累加操作；
58.二、校验功能技术方案：
59.在做预查询链路时，需先判断活动、权益、商户、门店、手机号、设备号、客户号等维度是否有参与返利资格；
60.三、累加撤销功能技术方案：
61.针对已经做过累加交易或者累加超时的场景，需做累加撤销操作；
62.四、爆点活动redis缓存刷新能力技术方案：
63.做大型促销活动时，在活动开始前将对应的活动、权益、商户、门店组装成rediskey刷新至redis中，累加值为0，保证活动开展时redis有值，走redis累加逻辑；
64.五、marketing-limit-center白名单功能(活动管控)技术方案：
65.活动、工具配置时，会同步活动管控活动基本信息，活动管控根据apollo配置的时间判断白名单链路；
66.累加功能技术方案具体包括以下(如图1所示)：
67.(1)用户购买抢购商品时进入系统通过活动、权益、商户、门店建立redis热点维度；
68.(2)结合热度维度和组装掉规则中心获取静态配置信息(维度金融、笔数、活动结束时间)并查询规则详情；
69.(3)根据规则中心返回的结果先查询redis进行check(判断redis、累加表的金额与配置的金额笔数)其中要进行rediskey是否存在，不存在则查询累加表获取最后更新时间(加redis锁)；判断当前时间与最后更新时间；若不是同一天则认为是第一笔交易，redis直接插入；若是同一天则认为redis失效，进行补偿操作；
70.注：每天11点定时任务跑t 1日redis刷新(刷新每一天第一笔的日维度、每月第一笔的月维度)；
71.(4)数据正常则落交易明细表(状态为ini)；
72.(5)热点维度redis校验累加，increby做累加操作，并判断累加后的数据是否超成本(redis不存在则数据库校验累加，做redis补偿)；
73.(6)redis补偿(加redis锁)(redis高可用情况，理论上无需补偿):开线程并发查询所有库中状态为init的交易明细表获取金额、笔数 累加表数据 当前累加金额、笔数，补偿至redis中；
74.(7)redis过期时间计算方式:
75.a)日维度固定两天 随机数过期；
76.b)月维度取当前日与当月月底的时间差 随机值；
77.c)周期维度取当日与活动结束时间的时间差 随机值(若活动延期则接受配置中心信息变更kafka做延期操作)；
78.(8)成功：
79.非热点维度数据库校验累加(乐观锁判断)(累加明细表存在则更新，不存在则插入)(开线程将热点维度数据累加至累加明细表(累加失败落异常推进表)，累加成功则更新交易流水表状态为成功)；
80.(9)失败：
81.失败返回(若之前有累加成功操作，则开线程做累加撤销，更新交易明细表状态为失败，撤销失败落异常推进表)(注意:开线程做累加撤销时，热点维度只需撤销redis数据，无需操作数据库)；
82.校验功能技术方案如下(如图2所示)：
83.(1)组装调规则中心查询接口请求参数；
84.(2)热度维度查询redis(redis不存在不做补偿)，非热度维度查询数据库；
85.分片核心技术方案如下(如图3所示)：
86.(1)业务开始进入分片功能；
87.(2)根据前置逻辑计算的值进入对应的service进行数据的变更，将请求参数存入command返回对应的结果给用户；
88.(3)command根据用户的状态：成功-储存到对应的数据库中，失败-监控所有的服务内数量对最多的进行减半处理并加到数据量最少的服务内,直到没用用户数据可以储存或达到阈值将所用服务的剩余数量同步到数据库中；
89.累加撤销功能技术方案(如图4所示)：
90.(1)根据原请求三要素查询交易明细表，判断原单是否存在、原单状态以及原单累
加金额(撤销金额不得大于累加金额)；
91.(2)落交易明细表(init状态)；
92.(3)发送自产自销kafka消息；
93.(4)接受自产自销kafka消息；
94.(5)热点维度redis校验累加撤销，加锁做累加撤销操作(redis不存在则数据库累加撤销，不做redis补偿)(开线程将热点维度数据累加撤销至累加明细表(累加撤销失败落异常推进表)，累加成功则更新交易流水表状态为成功)；
95.(6)非热点维度数据库累加撤销。
96.最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。