CN110955857A - 一种用于高并发环境的业务处理方法及装置 - Google Patents

一种用于高并发环境的业务处理方法及装置 Download PDF

Info

Publication number
CN110955857A
CN110955857A CN201910994936.3A CN201910994936A CN110955857A CN 110955857 A CN110955857 A CN 110955857A CN 201910994936 A CN201910994936 A CN 201910994936A CN 110955857 A CN110955857 A CN 110955857A
Authority
CN
China
Prior art keywords
kafka
data
information
channels
member information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201910994936.3A
Other languages
English (en)
Inventor
胡安康
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Suning Cloud Computing Co Ltd
Original Assignee
Suning Cloud Computing Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Suning Cloud Computing Co Ltd filed Critical Suning Cloud Computing Co Ltd
Priority to CN201910994936.3A priority Critical patent/CN110955857A/zh
Publication of CN110955857A publication Critical patent/CN110955857A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/958Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明实施例公开了一种用于高并发环境的业务处理方法及装置,涉及互联网技术领域,能够提高系统的稳定性。本发明包括:业务系统发起业务活动后,读取客群数据文件并提取会员信息;通过kafka接收所述会员信息,并利用所述会员信息确定对应各个会员的渠道;根据所述对应各个会员的渠道,向对应各个会员的渠道发送通知消息,并调用各个会员的渠道的服务接口;将与所述业务活动对应的虚拟物品信息,通过所调用的服务接口发送至下游平台;通过kafka发布订阅消息通知上游平台。本发明适用于高并发环境的分布式系统。

Description

一种用于高并发环境的业务处理方法及装置
技术领域
本发明涉及互联网技术领域,尤其涉及一种用于高并发环境的业务处理方法及装置。
背景技术
电商平台是目前互联网技术发展的一个重要产物,主要为消费者提供购物服务,与之相关联的还包括了物流平台、供应商平台等系统。而随着互联网经济的技术发展,电商平台每日需要处理的业务数据量也呈几何式增加。电商平台在数据处理方面面临的压力和挑战也逐步增加。
尤其是对于大型促销活动的处理,这类促销活动如果想正常上线运行,需要处理多种商品信息、多类用户信息、物流信息以及供应商的信息,处理过程复杂且信息数据往往是动态的,实际应用中受限于硬件环境,比如:目前常用的数据库存储数据(Mysql,DB2)数据容量有限,读写能力较弱;并发处理数据量有限,受限于数据的存储,销毁,读取能力,需要大量的机器用于无用的重启,无法动态扩展存储容量;且由于机器设备需求量大,需要更多的存储资源,数据刷新速度快,难以动态扩展。
因此目前的主要几大电商平台也只能同时支撑几种活动的同时进行,数量一旦增多将严重影响整个系统的稳定性。最终造成的问题在于目前的方式中对于业务活动并发处理效率较低,每天活动并发率不高,必须排队等待,并且很容易造成机器使用率过高,存在宕机风险。
发明内容
本发明的实施例提供一种用于高并发环境的业务处理方法及装置,能够提高系统的稳定性。
为达到上述目的,本发明的实施例采用如下技术方案:
一方面,提供一种用于高并发环境的业务处理方法,包括:
业务系统发起业务活动后,读取客群数据文件并提取会员信息;
通过kafka接收所述会员信息,并利用所述会员信息确定对应各个会员的渠道;
根据所述对应各个会员的渠道,向对应各个会员的渠道发送通知消息,并调用各个会员的渠道的服务接口;
将与所述业务活动对应的虚拟物品信息,通过所调用的服务接口发送至下游平台;
通过kafka发布订阅消息通知上游平台。
另一方面,一种用于高并发环境的业务处理装置,包括:
提取模块,用于业务系统发起业务活动后,读取客群数据文件并提取会员信息;
渠道模块,用于通过kafka接收所述会员信息,并利用所述会员信息确定对应各个会员的渠道;
接口模块,用于根据所述对应各个会员的渠道,向对应各个会员的渠道发送通知消息,并调用各个会员的渠道的服务接口;
下发模块,用于将与所述业务活动对应的虚拟物品信息,通过所调用的服务接口发送至下游平台;
上报模块,用于通过kafka发布订阅消息通知上游平台。
本发明实施例提供的用于高并发环境的业务处理方法及装置,通过使用多组件分布方式数据处理及存储;布隆过滤器处理重复数据效率更高,可达到千万分支一误差率;高通过hbase读写数据,减少使用mysql、db2数据库的读写,降低数据丢失率。从而提高整个系统的稳定性。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1为本发明实施例提供的系统架构示意图;
图2为本发明实施例提供的方法流程示意图;
图3、图4、图5、图6、图7、图8为本发明实施例提供的具体实例的示意图。
具体实施方式
为使本领域技术人员更好地理解本发明的技术方案,下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式,所述实施方式的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的,仅用于解释本发明,而不能解释为对本发明的限制。本技术领域技术人员可以理解,除非特意声明,这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是,本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件,但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解,当称元件被“连接”或“耦接”到另一元件时,它可以直接连接或耦接到其他元件,或者也可以存在中间元件。此外,这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解,除非另外定义,这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是,诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义,并且除非像这里一样定义,不会用理想化或过于正式的含义来解释。
本实施例中的方法流程,具体可以在服务器集群上执行,并通过目前常见的大数据系统架构技术,在服务器集群中的划分各个节点或者子系统,并不同的子系统承担相应的功能,其中包括了:
Mysql:一种关系型数据库管理系统,用于存储数据基础信息备份使用,不作为常用方案;
Kafka:一种是由Apache软件基金会开发的一个开源流处理平台,基于Scala和Java编写,属于高吞吐量的分布式环境下发布订阅消息的系统,并用于本实施例中消息发布订阅后进行数据消费后业务处理;
Hbase:一种高可靠性、高性能、面向列、可伸缩的分布式存储系统,用于数据灾备,在系统其它方面出现问题后,可快速切换Hbase进行数据存储和备份,有着高读写能力的优势;
RSF(Remote Service Framework,分布式服务框架设计):用于数据分发,RSF服务具有高并发和重试机制,用于解决数据消费的及时和准确性;rsf/kafka则是一种基于Kafka开发的分布式的系统组件服务。
ZooKeeper:ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Hadoop和Hbase的重要组件,用于解决机器调度不均问题;
Redis:一种key-value存储系统,用于基本数据数据存储,方便管理和读取速度更快;
Elasticsearch:是一种基于Lucene的搜索服务器,提供了一个分布式多用户能力的全文搜索引擎,作为底层数据框架,提供大数据量(亿级)的实时统计查询的方案,用于实时数据查询和统计,运行Elasticsearch的节点接入Hbase,形成es/Hbase的读写架构,从而实现数据再被的快速读写;在本实施例中,rsf/kafka用于数据通信,es/hbase用于数据存储。
Flink:由Apache软件基金会开发的开源流处理框架,其核心是用Java和Scala编写的分布式流数据流引擎。Flink以数据并行和流水线方式执行任意流数据程序,Flink的流水线运行时系统可以执行批处理和流处理程序。此外,Flink的运行时本身也支持迭代算法的执行,用于数据排重过滤。
在本实施例中,并在服务器集群上采用动态的灾备扩容方案,其中过包括:
kafka将所有消息组织成多个topic的形式存储,而每个topic又可以拆分成多个partition,每个partition又由一个一个消息组成。每个消息都被标识了一个递增序列号代表其进来的先后顺序,并按顺序存储在partition中。每个Topics划分为一个或者多个Partition,并且Partition中的每条消息都被标记了一个sequentialid,也就是offset,并且存储的数据是可配置存储时间的,只要动态增加partition数量,增加消费partition的机器数量,就可以快速消费partition中数据,并且kafka topic存储数据容量可达到10M,有更大的空间去存储报文数据,不用担心报文大小的问题。如图1所示的,Zookeeper用以实现诸如分布式应用配置管理、统一命名服务、状态同步服务、集群管理等功能,这里拿比较简单的分布式应用配置管理为例来说明。假设的程序是分布式部署在多台机器上,如果要改变程序的配置文件,需要逐台机器去修改,非常麻烦,现在把这些配置全部放到zookeeper上去,保存在zookeeper的某个目录节点中,然后所有相关应用程序对这个目录节点进行监听,一旦配置信息发生变化,每个应用程序就会收到zookeeper的通知,然后从zookeeper获取新的配置信息应用到系统中。通过该特性当提升处理数据性能,只需要动态增加机器,会立马注册节点提供服务。本实施例中zookeeper的处理逻辑如图5所示的。
本发明实施例提供一种用于高并发环境的业务处理方法,如图2所示,包括:
S101,业务系统发起业务活动后,读取客群数据文件并提取会员信息。
其中,业务系统指的是用于处理各类在线业务活动的系统,例如用户承担大型促销活动中优惠券发放的系统、优惠商品的抢购系统、抢购过程中的订单处理系统等。客群数据文件,广义上指的是用户数据,用户被按照一定的分类规则划分为不同的群体,从而形成不同的客群,一个客群中的用户数据的集合可以理解为客群数据文件。而一个用户若在相应的业务系统中注册过,或者在会员系统中注册过,则被认定为会员,并在客群数据文件中维护对应于该用户的会员信息。
S102,通过kafka接收所述会员信息,并利用所述会员信息确定对应各个会员的渠道。
S103,根据所述对应各个会员的渠道,向对应各个会员的渠道发送通知消息,并调用各个会员的渠道的服务接口。
S104,将与所述业务活动对应的虚拟物品信息,通过所调用的服务接口发送至下游平台。
S105,通过kafka发布订阅消息通知上游平台。
在实际应用中,为了应对海量的用户请求和流量波动,通常会通过一些前端服务器来接收并处理用户的终端设备发送的信息和数据。并且在这些前端服务器上也会部署一些中间件服务(其中,中间件服务可以理解为一种在前端服务器上处理数据,并向用户提供业务功能的服务),并将需要向用户发送的消息,通过这些下游平台推送至用户。因此,下游平台可以理解为与用户终端进行直接数据交互的服务器设备。而上游平台,则可以理解为用于存储长期数据的数据库系统,用于为业务系统的正常运行提供数据支持。在本实施例中,S101中所述业务系统发起业务活动,具体包括:
所述业务系统发起业务活动后,通过rsf/kafka告知各个客群节点。各个客群节点校验客群规则和活动规则,校验完成后所述业务系统接收各个客群节点返回的活动状态。例如图3所示的活动下发时取数据的流程图,业务系统发起活动,通过rsf/kafka告知,活动客群规则校验,活动规则校验,校验完成后通过返回活动状态。使用rsf方式可以通过rsf架构的动态扩容方式,可提供更多的机器去接收活动数据,并进行校验。使用kafka方式可使用kafka发布订阅消息的特性,在数据未被消费的情况下,可继续消费数据,直到数据被消费掉,解决的问题:机器宕机情况下,进行机器重启后可继续消费kafka中的订阅消息,解决数据丢失问题。
取数据流程的处理逻辑:
1、通过拼装Redis key(ACT:系统编码:活动ID)判断活动是否重复;
2、校验ActivityReqDto中参数是否合法(指令、渠道、客群);
3、校验通过,将活动信息存Redis;校验不通过直接返回错误信息;
4、如果活动需要排重,从Redis中获取该场景的排重规则,排重规则举例:X天内向同一个会员发送过Y次虚拟券数据;
5、启动异步任务(调用ActivityCustomGrpProcessor类fetchCustomGrp方法,实现客群取数、发送执行节点对应的Kafka Topic,Spring配置异步线程池<task:executorpool-size="5-20"queue-capacity="200"keep-alive="120"rejection-policy="ABORT"/>)
6、返回成功响应。
其中,类ActivityCustomGrpProcessor方法fetchCustomGrp()@Async,输入:ActivityReqDto,输出:无
1、循环处理ActivityReqDto中客群信息列表,调用客群系统RSF接口获取客群文件OSS下载地址;
2、下载客群失败,将活动信息记录到MySQL数据库,并标记失败,然后退出;
3、下载客群文件到本地成功,逐行读取文件,清洗格式异常的记录;
4、按会员尾数分组建立bloomfilter,通过bloomfilter过滤重复的会员号,BloomFilter构建参数expectedInsertions 300万,falsePositiveProbability误判率0.0001;
5、通过会员编号查询客群系统Hbase获取会员联系信息;
6、根据会员联系信息,去除黄牛(发券情况),去除注销会员;
7、保存会员信息到ES;
8、根据活动信息和会员联系信息拼装Kafka消息,发送到ActivityReqDto指令指定的下一个执行节点Topic(imp_act_exe_指令)中;
9、循环处理完所有客群文件,删除活动所有bloomfilter。
进一步的,所述读取客群数据文件并提取会员信息,包括:
从所述客群数据文件中读取存在会员信息的数据集合,并对所述数据集合中的元素使用k个哈希函数计算k个哈希值,k为正整数。
检测每一个哈希值作为下标的元素,所对应位数组的位置是否都为1,
如果k个哈希值作为下标的元素所对应位数组的位置都为1,则判定元素在所述数据集合中,否则元素不在所述数据集合中,并根据判定的结果过滤重复的元素,其中,一个元素被判定在所述数据集合中则表示这一个元素是重复的。
例如:客群数据文件取数,使用BloomFilter解决活动多个文件情况下会有重复的信息。比如,在响应时间要求比较严格的情况下,如果存在内里,那么随着集合中元素的增加,需要的存储空间越来越大,以及检索的时间越来越长,导致内存开销太大、时间效率变低。此时需要考虑解决的问题就是,在数据量比较大的情况下,既满足时间要求,又满足空间的要求。即需要一个时间和空间消耗都比较小的数据结构和算法。
其中,BloomFilter(布隆过滤器)是一种由Howard Bloom提出的二进制向量数据结构,在响应时间要求比较严格的情况下,随着集合中元素的增加,需要的存储空间越来越大,以及检索的时间越来越长,导致内存开销太大、时间效率变低。此时需要考虑解决的问题就是,在数据量比较大的情况下,既满足时间要求,又满足空间的要求。即需要一个时间和空间消耗都比较小的数据结构和算法。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法,缺点是有一定的误识别率和删除困难。布隆过滤器可以用于检索一个元素是否在一个集合中。对元素使用k个哈希函数计算k个哈希值,检查这些哈希值作为下标对应位数组的位置是否都为1,如果都为1则认为元素在集合中,否则元素不在集合中。解决了多个数据文件中重复信息发送概率。重复过滤可达到千万分之一。
本实施例中,BloomFilter主要用于检索一个元素是否在集合中。优点是空间效率和查询效率比较高。缺点是存在误判率。具体实现逻辑,包括:
1.定义一个位数组;
2.添加元素,使用k个哈希函数映射到位数组中,把位数组指定下标设置为1;
3.判断元素是否在集合中对元素使用k个哈希函数计算k个哈希值,检查这些哈希值作为下标对应位数组的位置是否都为1,如果都为1则认为元素在集合中,否则元素不在集合中。这里可能会存在误判。
具体在会员信息排重中,如图4所示的,Flink以数据并行和流水线方式执行任意流数据程序,Flink的流水线运行时系统可以执行批处理和流处理程序。此外,Flink的运行时本身也支持迭代算法的执行,用于数据排重过滤。
排重的处理逻辑,包括:
类KafkaMessageMapper方法flatMap()
输入:FlinkKafkaConsumer读取的字符串
输出:Tuple2<String,ExclusionData>,元组f0是“会员ID_渠道_场景”,f1是kafka消息JSON转对象
将入参String转ExclusionData对象;
校验数据,非法的数据丢弃;
将ExclusionData对象中会员ID、渠道、场景字段用下划线连接的字符串
作为输出元组的第一字段,ExclusionData作为第二个字段输出;
类HbaseDedupProccessor方法processElement()
输入:Tuple2<String,ExclusionData>,元组f0是“会员ID_渠道_场景”;
输出:ExclusionData;
根据ExclusionData中的排重规则计算版本区间,处理逻辑是查询区间为最大时间maxStamp=当前时间,最小时间minStamp为(当天-(排重规则天数-1)日期的0点);
setTimeRange(long minStamp,long maxStamp);
根据入参元组中的“会员ID_渠道_场景”作为rowkey查询Hbase;
如果查询出结果个数大于等于排重规则中次数,则ExclusionData对象isDuplicate字段设置为true;
如果查询结果个数小于排重规则次数,则isDuplicate设置为false;
输出ExclusionData对象。
在本实施例中,S102中所述通过kafka接收会员信息,并利用所述会员信息确定对应各个会员的渠道,具体包括:
通过kafka接收所述会员信息后,从hbase中查询各个会员与每个渠道是否为可到达。具体的,“渠道可到达”指的是业务系统中记录了用户的联络方式,比如:发送短信,检测会员是否有登记记录手机号,有手机号则为可到达;发送邮件,检测会员是否有登记记录邮箱,有邮箱则为可到达。
对于可到达的渠道,通过kafka发送通知。
对于不可到达的渠道,发布订阅消息并记录异常信息,通过kafka消费所述异常信息后,将所述异常信息写入es/hbase。例如:
图6所示的,通过kafka接收消息后,查询hbase会员信息,判断会员每个渠道是否可达,是否黑名单,可达后数据丢到下游的kafka进行发送通知,不可达数据,发布订阅消息至记录异常信息kafka,异常信息kafka数据消费后,通过定时定量的方式,把数据写入es/hbase当中,待查询异常信息。
渠道判断的处理逻辑,包括:
类ChannelSplitMessage的onMessage()方法输入:Kafka Json字符串输出:无
1、调用checkMessage(String msg)方法,校验json字符串是否合法,若不合法,流程结束
2、调用deserialize(String msg)方法,反序列化json串为MsgDTO
3、调用ChannelSplitBiz的splitChannel(MsgDTO dto)方法,处理渠道拆分逻辑,无返回值
4、将渠道拆分好的会员信息合法会员记录拼装Kafka消息,调用KafkaUtil的sendMessage(String msg)方法,将报文传输给下游。
类ChannelSplitBiz的splitChannel()方法
输入:渠道未拆分的MsgDTO消息对象
输出:渠道拆分好的MsgDTO消息对象
1、调用checkAllSendChannel(MsgDTO dto)方法,遍历需全部发送的渠道列表(dto.getAllChannel()),校验各渠道的联系方式是否合法,如果包含短信渠道,需调用checkMobile(Stringmobile)方法,从短信黑名单缓存中查询该用户是否在黑名单,返回所有可触达的渠道(List),通过kafka,将不可触达的渠道及原因异步写到ES。
2、调用checkOrderSendChannel(MsgDTO dto)方法,校验第一个渠道的联系方式(dto.getOrderChannel().get(0))是否合法,如果是短信渠道,需调用checkMobile(String mobile)方法,从短信黑名单缓存中查询该用户是否在黑名单,如果第一个渠道可触达,直接返回该渠道,如果不合法,校验第二个渠道,以此类推,至多返回一个可触达的渠道(List),通过kafka,将不可触达的渠道及原因异步写到ES。
3、拼接1、2步骤返回的渠道list,封装为MsgDTO,返回给ChannelSplitMessageListener
在本实施例中,S103中,根据所述对应各个会员的渠道,向对应各个会员的渠道发送通知消息,并调用各个会员的渠道的服务接口,具体包括:
通过通知kafka消费数据,判断用户发送各个渠道通知消息,调用提供服务接口的系统,包含mq、kafka、http、windq等方式,发送通知给下游,成功数据发布订阅消息到记录成功信息的kafka当中,等待定时定量消费数据,写入es/hbase,失败数据发布订阅消息至记录异常信息kafka,异常信息kafka数据消费后,通过定时定量的方式,把数据写入es/hbase当中,待查询异常信息。
在本实施例中,S104中,将与所述业务活动对应的虚拟物品信息,通过所调用的服务接口发送至下游平台。
以虚拟物品为优惠券的发券场景为例,通过发券kafka消费数据后,通过消息队列控制(BlockQueue),定时定量发送券信息到下游平台,成功数据发布订阅消息到记录成功信息的kafka当中,等待定时定量消费数据,写入es/hbase,失败数据发布订阅消息至记录异常信息kafka,异常信息kafka数据消费后,通过定时定量的方式,把数据写入es/hbase当中,待查询异常信息。
在本实施例中,S105中,所述通过kafka发布订阅消息通知上游平台,包括:通过kafka发布订阅消息通知所述上游平台,当所述上游平台消费所述订阅消息的数据后,完成活动上报。如图7所示的,活动通知上游,通过kafka发布订阅消息通知上游,由上游系统消费,只要上游数据未消费,都可以再次消费数据,完成活动上报。
本实施例在实际应用中的整体流程如图8所示。本实施例中,通过使用多组件分布方式数据处理及存储;布隆过滤器处理重复数据效率更高,可达到千万分支一误差率;高tps hbase读写数据,减少使用mysql db2数据库的读写;elasticsearch+hbase动态切换数据读写,降低数据丢失率;基于kafka、rsf组件特性,可动态扩容机器,提高处理能力。在实际应用中,提高活动并发处理能力:以前可同时并发10个活动,量级300w左右,使用本专利后,以现在机器数量可同时50个活动,量级在3000w以上,并且是可以通过动态扩容机器,增加并发处理能力;且极大的降低数据丢失率:以前每处理活动数据,出现异常情况,只能通过日志系统一点点找,由于不对其他系统造成压力,很多日志是无法完整打印,使用本专利后,每个活动,每个人,在每一步都可以看到完成的流程,正常的,异常的一目了然。提高数据处理速度:以前每秒处理的数量在1000条左右,在资源争抢下,还会降低,采用本实施例后,每秒处理条数在万条以上,大大提高了处理速度,提高了转换率。
本发明实施例还提供一种用于高并发环境的业务处理装置,包括:
提取模块,用于业务系统发起业务活动后,读取客群数据文件并提取会员信息;
渠道模块,用于通过kafka接收所述会员信息,并利用所述会员信息确定对应各个会员的渠道;
接口模块,用于根据所述对应各个会员的渠道,向对应各个会员的渠道发送通知消息,并调用各个会员的渠道的服务接口;
下发模块,用于将与所述业务活动对应的虚拟物品信息,通过所调用的服务接口发送至下游平台;
上报模块,用于通过kafka发布订阅消息通知上游平台。
其中,所述提取模块,具体用于所述业务系统发起业务活动后,通过rsf/kafka告知各个客群节点;各个客群节点校验客群规则和活动规则,校验完成后所述业务系统接收各个客群节点返回的活动状态。
所述提取模块,具体用于从所述客群数据文件中读取存在会员信息的数据集合,并对所述数据集合中的元素使用k个哈希函数计算k个哈希值,k为正整数;检测每一个哈希值作为下标的元素,所对应位数组的位置是否都为1;如果k个哈希值作为下标的元素所对应位数组的位置都为1,则判定元素在所述数据集合中,否则元素不在所述数据集合中,并根据判定的结果过滤重复的元素,其中,一个元素被判定在所述数据集合中则表示这一个元素是重复的。
所述渠道模块,具体用于通过kafka接收所述会员信息后,从hbase中查询各个会员与每个渠道是否为可到达;
对于可到达的渠道,通过kafka发送通知;
对于不可到达的渠道,发布订阅消息并记录异常信息,通过kafka消费所述异常信息后,将所述异常信息写入es/hbase。
所述上报模块,具体用于通过kafka发布订阅消息通知所述上游平台,当所述上游平台消费所述订阅消息的数据后,完成活动上报。
本实施例中,通过使用多组件分布方式数据处理及存储;布隆过滤器处理重复数据效率更高,可达到千万分支一误差率;高tps hbase读写数据,减少使用mysql db2数据库的读写;elasticsearch+hbase动态切换数据读写,降低数据丢失率;基于kafka、rsf组件特性,可动态扩容机器,提高处理能力,在实际应用中,提高活动并发处理能力。并且是可以通过动态扩容机器,增加并发处理能力;且极大的降低数据丢失率:以前每处理活动数据,出现异常情况,只能通过日志系统一点点找,由于不对其他系统造成压力,很多日志是无法完整打印,使用本专利后,每个活动,每个人,在每一步都可以看到完成的流程,正常的,异常的一目了然。提高数据处理速度:以前每秒处理的数量在1000条左右,在资源争抢下,还会降低,采用本实施例后,每秒处理条数在万条以上,大大提高了处理速度,提高了转换率。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于设备实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。

Claims (10)

1.一种用于高并发环境的业务处理方法,其特征在于,包括:
业务系统发起业务活动后,读取客群数据文件并提取会员信息;
通过kafka接收所述会员信息,并利用所述会员信息确定对应各个会员的渠道;
根据所述对应各个会员的渠道,向对应各个会员的渠道发送通知消息,并调用各个会员的渠道的服务接口;
将与所述业务活动对应的虚拟物品信息,通过所调用的服务接口发送至下游平台;
通过kafka发布订阅消息通知上游平台。
2.根据权利要求1所述的方法,其特征在于,所述业务系统发起业务活动,包括:
所述业务系统发起业务活动后,告知各个客群节点;
各个客群节点校验客群规则和活动规则,校验完成后所述业务系统接收各个客群节点返回的活动状态。
3.根据权利要求1所述的方法,其特征在于,所述读取客群数据文件并提取会员信息,包括:
从所述客群数据文件中读取存在会员信息的数据集合,并对所述数据集合中的元素使用k个哈希函数计算k个哈希值,k为正整数;
检测每一个哈希值作为下标的元素,所对应位数组的位置是否都为1;
如果k个哈希值作为下标的元素所对应位数组的位置都为1,则判定元素在所述数据集合中,否则元素不在所述数据集合中,并根据判定的结果过滤重复的元素,其中,一个元素被判定在所述数据集合中则表示这一个元素是重复的。
4.根据权利要求1所述的方法,其特征在于,所述通过kafka接收会员信息,并利用所述会员信息确定对应各个会员的渠道,包括:
通过kafka接收所述会员信息后,从hbase中查询各个会员与每个渠道是否为可到达;
对于可到达的渠道,通过kafka发送通知;
对于不可到达的渠道,发布订阅消息并记录异常信息,通过kafka消费所述异常信息后,将所述异常信息写入es/hbase。
5.根据权利要求1所述的方法,其特征在于,所述通过kafka发布订阅消息通知上游平台,包括:
通过kafka发布订阅消息通知所述上游平台,当所述上游平台消费所述订阅消息的数据后,完成活动上报。
6.一种用于高并发环境的业务处理装置,其特征在于,包括:
提取模块,用于业务系统发起业务活动后,读取客群数据文件并提取会员信息;
渠道模块,用于通过kafka接收所述会员信息,并利用所述会员信息确定对应各个会员的渠道;
接口模块,用于根据所述对应各个会员的渠道,向对应各个会员的渠道发送通知消息,并调用各个会员的渠道的服务接口;
下发模块,用于将与所述业务活动对应的虚拟物品信息,通过所调用的服务接口发送至下游平台;
上报模块,用于通过kafka发布订阅消息通知上游平台。
7.根据权利要求6所述的装置,其特征在于,所述提取模块,具体用于所述业务系统发起业务活动后,通过rsf/kafka告知各个客群节点;各个客群节点校验客群规则和活动规则,校验完成后所述业务系统接收各个客群节点返回的活动状态。
8.根据权利要求6所述的装置,其特征在于,所述所述提取模块,具体用于从所述客群数据文件中读取存在会员信息的数据集合,并对所述数据集合中的元素使用k个哈希函数计算k个哈希值,k为正整数;检测每一个哈希值作为下标的元素,所对应位数组的位置是否都为1;如果k个哈希值作为下标的元素所对应位数组的位置都为1,则判定元素在所述数据集合中,否则元素不在所述数据集合中,并根据判定的结果过滤重复的元素,其中,一个元素被判定在所述数据集合中则表示这一个元素是重复的。
9.根据权利要求6所述的装置,其特征在于,所述渠道模块,具体用于通过kafka接收所述会员信息后,从hbase中查询各个会员与每个渠道是否为可到达;
对于可到达的渠道,通过kafka发送通知;
对于不可到达的渠道,发布订阅消息并记录异常信息,通过kafka消费所述异常信息后,将所述异常信息写入es/hbase。
10.根据权利要求6所述的装置,其特征在于,所述上报模块,具体用于通过kafka发布订阅消息通知所述上游平台,当所述上游平台消费所述订阅消息的数据后,完成活动上报。
CN201910994936.3A 2019-10-18 2019-10-18 一种用于高并发环境的业务处理方法及装置 Pending CN110955857A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910994936.3A CN110955857A (zh) 2019-10-18 2019-10-18 一种用于高并发环境的业务处理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910994936.3A CN110955857A (zh) 2019-10-18 2019-10-18 一种用于高并发环境的业务处理方法及装置

Publications (1)

Publication Number Publication Date
CN110955857A true CN110955857A (zh) 2020-04-03

Family

ID=69975605

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910994936.3A Pending CN110955857A (zh) 2019-10-18 2019-10-18 一种用于高并发环境的业务处理方法及装置

Country Status (1)

Country Link
CN (1) CN110955857A (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111934986A (zh) * 2020-07-31 2020-11-13 银盛支付服务股份有限公司 一种异步消息终端推送解决方法及系统
CN112069162A (zh) * 2020-11-10 2020-12-11 太平金融科技服务(上海)有限公司 流计算的数据处理方法、装置、计算机设备和存储介质
CN112699130A (zh) * 2021-01-15 2021-04-23 广东电网有限责任公司广州供电局 电力数据处理方法、装置、计算机设备
CN112769948A (zh) * 2021-01-20 2021-05-07 中信银行股份有限公司 消息处理方法及装置
CN112822260A (zh) * 2020-12-31 2021-05-18 北京天融信网络安全技术有限公司 文件传输方法及装置、电子设备、存储介质
CN113112255A (zh) * 2021-04-19 2021-07-13 中国工商银行股份有限公司 分布式消息处理方法、装置、设备、介质和程序产品
CN114048201A (zh) * 2021-11-16 2022-02-15 北京锐安科技有限公司 一种基于分布式流计算引擎Flink的关键字段实时去重方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107026917A (zh) * 2017-06-16 2017-08-08 智者四海(北京)技术有限公司 用于消息推送的方法及系统
CN107437132A (zh) * 2016-05-26 2017-12-05 上海泓进信息技术有限公司 一种全渠道云erp综合管理系统
CN108390881A (zh) * 2018-02-27 2018-08-10 北京焦点新干线信息技术有限公司 一种分布式高并发实时消息推送方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107437132A (zh) * 2016-05-26 2017-12-05 上海泓进信息技术有限公司 一种全渠道云erp综合管理系统
CN107026917A (zh) * 2017-06-16 2017-08-08 智者四海(北京)技术有限公司 用于消息推送的方法及系统
CN108390881A (zh) * 2018-02-27 2018-08-10 北京焦点新干线信息技术有限公司 一种分布式高并发实时消息推送方法及系统

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111934986A (zh) * 2020-07-31 2020-11-13 银盛支付服务股份有限公司 一种异步消息终端推送解决方法及系统
CN112069162A (zh) * 2020-11-10 2020-12-11 太平金融科技服务(上海)有限公司 流计算的数据处理方法、装置、计算机设备和存储介质
CN112069162B (zh) * 2020-11-10 2021-02-26 太平金融科技服务(上海)有限公司 流计算的数据处理方法、装置、计算机设备和存储介质
CN112822260A (zh) * 2020-12-31 2021-05-18 北京天融信网络安全技术有限公司 文件传输方法及装置、电子设备、存储介质
CN112699130A (zh) * 2021-01-15 2021-04-23 广东电网有限责任公司广州供电局 电力数据处理方法、装置、计算机设备
CN112769948A (zh) * 2021-01-20 2021-05-07 中信银行股份有限公司 消息处理方法及装置
CN113112255A (zh) * 2021-04-19 2021-07-13 中国工商银行股份有限公司 分布式消息处理方法、装置、设备、介质和程序产品
CN114048201A (zh) * 2021-11-16 2022-02-15 北京锐安科技有限公司 一种基于分布式流计算引擎Flink的关键字段实时去重方法

Similar Documents

Publication Publication Date Title
CN110955857A (zh) 一种用于高并发环境的业务处理方法及装置
US20180365254A1 (en) Method and apparatus for processing information flow data
US8903925B2 (en) Scheduled messages in a scalable messaging system
CN110134648A (zh) 日志处理方法、装置、设备、系统及计算机可读存储介质
CN108228322B (zh) 一种分布式链路跟踪、分析方法及服务器、全局调度器
CN112182043B (zh) 日志数据查询方法、装置、设备及存储介质
CN112434243B (zh) 一种同步数据的方法、装置和计算机可读存储介质
CN111210340A (zh) 一种自动任务处理方法、装置、服务器及存储介质
CN110764705B (zh) 一种数据的读写方法、装置、设备和存储介质
CN107562803B (zh) 数据供应系统及方法、终端
CN113742392A (zh) 一种数据同步方法、装置、电子设备及存储介质
CN114116827B (zh) 一种用户画像数据的查询系统及方法
CN111131512B (zh) 设备信息的处理方法、装置、存储介质及处理器
CN112541816A (zh) 互联网金融消费信贷批量业务分布式流计算处理引擎
CN112860412A (zh) 业务数据处理方法、装置、电子设备及存储介质
CN112052259A (zh) 数据处理方法、装置、设备及计算机存储介质
CN112099864A (zh) 一种异步数据的处理方法及装置
CN114218303B (zh) 一种交易数据的处理系统、处理方法、介质和设备
CN114416717A (zh) 一种数据处理方法及架构
CN115237935A (zh) 数据查询方法、装置、计算机设备和计算机可读存储介质
CN112256208A (zh) 一种离线数据包存储分析方法及装置
CN118365452B (zh) 基于Redis的热点账户的交易方法、装置、介质和设备
CN115269060B (zh) 一种基于aPaaS平台的服务执行前后置处理方法
Zhi et al. Data management solutions based on the data distribution service communication model
CN116541137A (zh) 事务处理方法、装置、计算机设备、存储介质和程序产品

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20200403