1.本发明涉及it与软件开发领域,特别涉及一种热点营销活动的成本控制方法。
背景技术:
::2.在互联网分布式微服务架构部署大背景下,基于电信用户体系基础上,在进行活动参与数累加时,如果是热点营销活动在高并发状态下,会存在数据单热点情况,数据库会响应慢,严重影响用户体验。3.本专利不同于常规负载均衡方案,原始负载均衡是针对一个请求或一个活动的请求会路由到一个确定的分片,那么当特定的一个或者几个热门活动的流量异常高时,那么在具体的这个分片的角度看流量是有偏向的,且分片固定后无法横向扩容来应对流量增加,本专利则是解决此类问题。技术实现要素:4.本发明要解决的技术问题是克服现有技术的缺陷,提供一种热点营销活动的成本控制方法,解决多个热点活动在使用常规负载均衡时偏向在一个数据节点上的成本控制的问题。5.本发明提供了如下的技术方案:6.本发明提供一种热点营销活动的成本控制方法,整体思路是在常规负载均衡基础上增加活动效果预估、动态调整、和水平的再分散步骤,因此核心方案概况为:7.i.水平再分散技术:针对一个主体,先计算出其分片起始位置,在基于流量情况计算出水平容量范围;8.ii.动态调整:由于引入了路由模块、总控模块,总控模块负责最终成本控制,路由到的数据分片负责实际的累加,因此水平再分散技术所分散的范围是可依据活动流量动态计算的;综上,本方案逻辑部分主要分为三个模块:路由模块、总控模块、计数模块,三个模块依赖间关系如图1;如下是各模块功能具体表述:9.a)路由模块:本模块是软负载均衡实现的重点,负责将请求分散到具体名额累加控制的子节点中。10.活动参与累加数据的存储是基于数据库的:例如共有x个数据存储节点,每个活动分散在具体节点的计算方式为:indexstart=hash(activityid)%x,在计算得到indexstart后,从活动效果预估系统得到活动每日预估参与人数t,再依据历史经验得出1个节点每日可承载参与人数t,进而可得出该活动分散节点数partition=roundup(t/t),可最终得出该活动限额数据最终所在节点区间为的闭区间分表里;11.计数节点所在数据库的算法为:indexdatabase=mod(hash(activityid),4);12.计数节点所在表的算法为:indextable=indexstart mod(hash(activityid),offset);13.b)计数模块:依据路由模块算出的分节点信息后,计数模块负责在当前存储节点做名额累加操作:14.i.开始数据库事物;15.ii.insertinto插入交易明细数据,这个数据作为请求流水记录;16.iii.updateactivity_add17.setadded=added 1whereactivity_id=%{activity_id}andadded 1《limit;18.判断iii中结果,如果更新成功则上报累加成功信息给总控模块并提交事物、否则上报失败信息给总控模块并回滚事物,并将是否累加成功的信息反馈给总控模块;19.路由模块自身也会记录iv中的结果,当某分片无限额后新请求就不在分发到此分片;20.c)总控模块:在接收到计数模块的上报的信息后,会在存储中记录是否已经无限额的标记,此存储存使用redis,key设计为:activity_{id}_over,value设计为:true/false;当总控模块收到活动限额配置信变更消息后会重置此值;21.各模块间依赖关系图、流程图分别如下图1和图2,下面是分流程对各模块做详述分解:22.在线活动参与请求流程:23.a)总控模块判断活动参与数是否达到上限;如果达到则返回“不可参与”信息,否则进入路由模块;24.b)路由模块:依据参与活动id计算本次请求路由到的分片,并通过计数模块在分片上执行计数累加;25.c)计数模块:如果累加成功,则通知总控模块汇总,如果由于超过限额导致累加失败,则通知路由模块记录当前超限额的分片id,用于后续请求不在路由到此分片;26.配置流程:27.活动限额修改:由于活动限额调整故需要重分配各分片分配的限额数,因此需通知总控模块重置活动已无名额状态、通知路由模块重置当前分片无名额状态。28.与现有技术相比,本发明的有益效果如下:29.本专利不同于常规负载均衡方案,原始负载均衡是针对一个请求或一个活动的请求会路由到一个确定的分片,那么当特定的一个或者几个热门活动的流量异常高时,那么在具体的这个分片的角度看流量是有偏向的,且分片固定后无法横向扩容来应对流量增加,本专利则是解决多个热点活动在使用常规负载均衡时偏向在一个数据节点上的成本控制的问题。附图说明30.附图用来提供对本发明的进一步理解,并且构成说明书的一部分,与本发明的实施例一起用于解释本发明,并不构成对本发明的限制。在附图中:31.图1是本发明的是路由模块、计数模块、总控模块间依赖关系图;32.图2是路由模块、计数模块、总控模块在用户参与活动时的名额累加流程、活动限额变更时的配置变更流程图;33.图3是数据存储节点的拓扑关系图。具体实施方式34.以下结合附图对本发明的优选实施例进行说明,应当理解,此处所描述的优选实施例仅用于说明和解释本发明,并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件。35.实施例136.如图1-3,本发明提供参照图2的流程图,现举以下实施例做详细说明。37.a)路由模块负责按照路由策略将请求路由到具体数据存储节点做限额累加操作,具体路由策略是:38.i.本实施例中的计数模块的数据节点是基于数据库存储的,在此基础上实现如果路由策略:39.ii.数据库中表设计如表一所示,其库、表拓扑结构如图3:采用分4库分128表设计,由此一次请求会随机分散在4个库若干张表上,其中计数节点所在数据库的选择采用随机策略,计数节点所在表的选择根据如下算法:表起始位置indexstart计算方式为:indexstart=hash(activityid)%128,在计算得到indexstart后,从活动效果预估模块得到该活动的计数节点总数为:offset,最终得出该活动计数节点最终所在分片区间为的闭区间分表里,具体到本次活动参与请求:40.计数节点所在数据库的算法为:41.indexdatabase=mod(hash(activityid),4)42.计数节点所在表的算法为:43.indextable=indexstart mod(hash(activityid),offset)44.b)计数模块:在路由模块明确了限额数据存储的节点后,计数模块则负责在节点上进行活动参与累加操作:45.i.开始数据库事物;46.ii.insertinto插入交易明细数据,这个数据作为请求流水记录;47.iii.updateactivity_add48.setadded=added 1whereactivity_id=%{activity_id}andadded 1《limit;49.iv.判断iii中结果,如果更新成功则上报累加成功信息给总控模块并提交事物、否则上报失败信息给总控模块并回滚事物;50.路由模块自身也会记录iv中的结果,当某分片无限额后新请求就不在分发到此分片;51.c)总控模块:在接收到计数模块的上报的信息后,会在缓存中记录是否已经无限额的标记,此处缓存使用redis做存储,key设计为:activity_{activity_id}_over,value设计为:true/false;当总控模块收到活动限额配置信变更消息后会重置此值。52.表一[0053][0054][0055]表一表示的是数据存储节点的数据库表设计,具体描述见上面的技术方案。[0056]最后应说明的是:以上所述仅为本发明的优选实施例而已,并不用于限制本发明,尽管参照前述实施例对本发明进行了详细的说明,对于本领域的技术人员来说,其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。当前第1页12当前第1页12
转载请注明原文地址:https://tc.8miu.com/read-2199.html