流处理系统的数据读写方法和流处理系统

文档序号:1860765 发布日期:2021-11-19 浏览:3次 >En<

阅读说明:本技术 流处理系统的数据读写方法和流处理系统 (Data reading and writing method of stream processing system and stream processing system ) 是由 阮良 于 2021-07-19 设计创作,主要内容包括:本申请涉及一种本实施例中提供的一种流处理系统的数据读写方法和流处理系统。其中,该方法包括:流处理系统的Broker接收读写数据请求;响应于读写数据请求,Broker通过读写缓存进行数据的读写操作,其中,读写缓存是由Broker从堆外内存中申请的预设内存空间。通过本申请,解决了流处理速度慢的问题,提高了流处理速度。(The present application relates to a data read-write method for a stream processing system and a stream processing system provided in this embodiment. Wherein, the method comprises the following steps: a Broker of the stream processing system receives a read-write data request; and responding to the read-write data request, and the Broker performs the read-write operation of the data through the read-write cache, wherein the read-write cache is a preset memory space applied by the Broker from the off-heap memory. By the method and the device, the problem of low stream processing speed is solved, and the stream processing speed is improved.)

流处理系统的数据读写方法和流处理系统

技术领域

本申请涉及流处理系统技术领域,特别是涉及一种流处理系统的数据读写方法和流处理系统。

背景技术

流处理系统是现代大数据系统中重要的一个环节,负责数据的存储和计算,例如Kafka,Pulsar等。

流处理系统由存储和计算两部分组成,生产者将数据源源不断的推送到流处理系统,流处理系统内部会有对应的计算任务持续地对数据进行处理,将结果输出到指定的外部系统,用于汇总展示。

在当前的流处理系统方案中,Broker接收到写入数据的请求会直接把数据写入到操作系统页缓存(Page Cache),等待OS的定时刷盘动作来写磁盘,当收到读取数据的请求时先从操作系统页缓存中找如果没有被淘汰会直接返回,避免了读取磁盘的动作;如果操作系统页缓存中没有需要读取磁盘,集群Broker之间副本同步也走的相同的逻辑,在实际生产环节中会遇到消费滞后的情况,当消费者请求到来,消费的是很早之前的数据(不在操作系统页缓存中)此时会触发磁盘的读取动作,并主动淘汰掉操作系统页缓存中的一些数据。此外,由于操作系统页缓存由OS的管理,而OS的行为却不受Broker的控制;并且当操作系统页缓存的缓存压力较大时,OS中除Broker之外的其他进程会导致内存竞争加剧,或操作系统页缓存中的流数据被其他进程的数据污染,增加了磁盘读取的次数,严重影响流处理速度。

为了解决上面的问题,当前的云原生环境基于Kubernetes的部署方案,为了确保流处理系统性能会让Broker独占一台物理机,即Broker基本上独占操作系统页缓存,避免与其他进程竞争内存,但这样会提高基础建设的硬件成本。

针对相关技术中流处理速度慢的问题,目前还没有提出有效的解决方案。

发明内容

在本实施例中提供了一种流处理系统的数据读写方法、流处理系统,在基于Kubernetes的部署方案中,以解决相关技术中存在的流处理速度慢的问题。

第一个方面,在本实施例中提供了一种流处理系统的数据读写方法,包括:

流处理系统的Broker接收读写数据请求;

响应于所述读写数据请求,所述Broker通过读写缓存进行数据的读写操作,其中,所述读写缓存是由所述Broker从堆外内存中申请的预设内存空间。

在其中的一些实施例中,在所述Broker接收到读数据请求时,所述Broker查询所述读写缓存是否存在第一数据,其中,所述第一数据为所述读数据请求所请求读取的数据;

若有,所述Broker从所述读写缓存读取所述第一数据;

否则,所述Broker从磁盘读取所述第一数据。

在其中的一些实施例中,所述Broker从磁盘读取所述第一数据包括:

在所述第一数据为所述冷数据时,所述Broker通过操作系统页缓存将所述第一数据从HDD写入所述读写缓存,在所述第一数据为所述热点数据时,所述Broker将所述第一数据从所述SSD写入所述读写缓存;

所述Broker从所述读写缓存读取所述第一数据。

在其中的一些实施例中,

在所述Broker接收到写数据请求时,所述Broker将第二数据写入所述读写缓存,其中,所述第二数据为所述写数据请求所请求写入的数据。

在其中的一些实施例中,在所述Broker将所述第二数据写入所述读写缓存之后,所述方法还包括:

在所述第二数据是所述冷数据时,所述Broker通过操作系统页缓存将所述第二数据从所述读写缓存写入HDD;

在所述第二数据是所述热点数据时,所述Broker将所述第二数据从所述读写缓存写入SSD。

在其中的一些实施例中,所述方法还包括:

在所述读写缓存剩余容量小于第一预设阈值的情况下,所述Broker将第三数据转存到磁盘,其中,所述第三数据为所述读写缓存当前存储的数据中最早被写入的数据。

在其中的一些实施例中,将所述第三数据转写到磁盘包括:

在所述第三数据是热点数据时,所述Broker将所述第三数据从所述读写缓存转存到SSD;

在所述第三数据是冷数据时,所述Broker通过操作系统页缓存将所述第三数据从所述读写缓存转存到HDD。

在其中的一些实施例中,所述方法还包括:

在所述Broker将所述第三数据从所述读写缓存转存到SSD时,当所述SSD内存不足时,所述Broker将第四数据从所述SSD删除,其中,所述第四数据为所述SSD当前存储的数据中最早被写入的数据。

在其中的一些实施例中,所述方法还包括:

所述Broker获取配置信息;

所述Broker根据所述配置信息,判断当前读写的数据是热点数据还是冷数据。

在其中的一些实施例中,所述方法还包括:

所述Broker根据在预设时间段内对读写数据的读写频率的统计信息,判断当前读写的数据是冷数据还是热点数据;

其中,在当前读写的数据在所述预设时间段内的读写频率超过第二预设阈值时,确定当前读写的数据为热点数据;否则,确定当前读写的数据为冷数据。

在其中的一些实施例中,响应于所述读写数据请求,所述Broker通过读写缓存进行数据的读写操作包括:

所述Broker判断所述读写数据请求是否为外部业务的读写数据请求;

在判断到所述读写数据请求不为外部业务的读写数据请求的情况下,所述Broker通过操作系统页缓存和磁盘进行读写数据的读写操作;

在判断到所述读写数据请求为外部业务的读写数据请求的情况下,所述Broker通过所述读写缓存进行读写数据的读写操作。

第二个方面,在本实施例中提供了一种流处理系统,包括生产者、消费者和Broker;其中,所述生产者用于生产数据并将生产的数据写入所述Broker,所述消费者用于消费所述Broker存储的数据,所述Broker包括存储器和处理器,其特征在于,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序实现上述第一个方面所述的流处理系统的数据读写方法。

与相关技术相比,在本实施例中提供的一种流处理系统的数据读写方法和流处理系统,通过流处理系统的Broker接收读写数据请求;响应于读写数据请求,Broker通过读写缓存进行数据的读写操作,其中,读写缓存是由Broker从堆外内存中申请的预设内存空间的方式,解决了流处理速度慢的问题,提高了流处理速度。

本申请的一个或多个实施例的细节在以下附图和描述中提出,以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:

图1是本实施例的流处理系统的数据读写方法的流程图。

图2是其中一个实施例的流处理系统的数据读写方法的示意图。

图3是其中一个优选实施例的流处理系统的数据读写方法的流程图。

具体实施方式

为更清楚地理解本申请的目的、技术方案和优点,下面结合附图和实施例,对本申请进行了描述和说明。

除另作定义外,本申请所涉及的技术术语或者科学术语应具有本申请所属技术领域具备一般技能的人所理解的一般含义。在本申请中的“一”、“一个”、“一种”、“该”、“这些”等类似的词并不表示数量上的限制,它们可以是单数或者复数。在本申请中所涉及的术语“包括”、“包含”、“具有”及其任何变体,其目的是涵盖不排他的包含;例如,包含一系列步骤或模块(单元)的过程、方法和系统、产品或设备并未限定于列出的步骤或模块(单元),而可包括未列出的步骤或模块(单元),或者可包括这些过程、方法、产品或设备固有的其他步骤或模块(单元)。在本申请中所涉及的“连接”、“相连”、“耦接”等类似的词语并不限定于物理的或机械连接,而可以包括电气连接,无论是直接连接还是间接连接。在本申请中所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系,表示可以存在三种关系,例如,“A和/或B”可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。通常情况下,字符“/”表示前后关联的对象是一种“或”的关系。在本申请中所涉及的术语“第一”、“第二”、“第三”等,只是对相似对象进行区分,并不代表针对对象的特定排序。

在本实施例中提供了一种流处理系统的数据读写方法,比如Kafka流处理平台和Pulsar流处理平台,Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者在网站中的所有动作流数据。这种动作(网页浏览,搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群来提供实时的消息。

相关技术中大部分流系统都是直接利用的操作系统的页缓存操作系统页缓存来作为数据缓存,相关技术中流系统处理进程是:当Broker接收到写入数据的请求时,会直接把数据写入到操作系统的页缓存操作系统页缓存,等待操作系统OS的定时刷盘动作来写入到磁盘;当Broker接收到读取数据的请求时,流系统处理进程先从操作系统的页缓存操作系统页缓存中查找,如果操作系统的页缓存操作系统页缓存中的被查出数据没有被淘汰,会直接返回给流系统处理,避免了读取磁盘的动作;但是如果操作系统的页缓存操作系统页缓存中没有查找到需要被读取的数据,此时会触发磁盘的读取动作,主动淘汰掉一些数据;由于OS级别的缓存应用程序不可控,当压力上来之后会导致内存竞争加剧,从而影响流系统处理的速度,进而导致操作系统页缓存中的数据被污染,增加磁盘读取的次数,所以,相关技术中流系统生产和消费的速度比较缓慢。而集群Broker之间副本同步也采用了与Broker接收到读取数据的请求相同的逻辑。

在本实施例中提供了一种流处理系统的数据读写方法,图1是本实施例的流处理系统的数据读写方法的流程图,如图1所示,该流处理系统的数据读写方法包括如下步骤:

步骤S101:流处理系统的Broker接收读写数据请求。

读数据请求是指在实际生产消费环节中消费者向流处理系统发出读取数据的指令。写数据请求是指在实际生产消费环节中生产者向流处理系统发出写入数据的指令。读数据的过程是指消费者向读写缓存或者磁盘读取数据,并将从读写缓存或者磁盘读取数据返回给消费者的过程;写数据的过程是指生产者向读写缓存或者磁盘写入数据的过程。

步骤S102:响应于读写数据请求,Broker通过读写缓存进行数据的读写操作,其中,读写缓存是由Broker从堆外内存中申请的预设内存空间。

Kafka集群包含一个或多个服务器,此服务器被称为Broker,Broker接收到读写数据请求时,Broker对读写数据请求作出响应,Broker通过读写缓存进行数据的读写操作。读写缓存读写缓存是由Broker从堆外内存中申请的预设内存空间,其中,堆外内存就是把内存对象分配在Java虚拟机的堆以外的内存。

通过上述步骤,本申请的流处理系统的数据读写方法Broker在堆外内存中申请了预设内存空间用于数据的读写缓存,该读写缓存由Broker管理,从而在Broker不需独占一台物理机的情况下,提高了流处理速度。与现有技术比Broker自己维护了缓存读写缓存,不再使用操作系统自带的页缓存,本发明更加可控。

在其中的一些实施例中,在Broker接收到读数据请求时,Broker查询读写缓存是否存在第一数据,其中,第一数据为读数据请求所请求读取的数据;若有,Broker从读写缓存读取第一数据;否则,Broker从磁盘读取第一数据。

例如,在Broker接收到读数据请求时,Broker先从读写缓存中查询读数据请求所请求读取的数据是否存在,在此,本实施例将读数据请求所请求读取的数据称为第一数据,若第一数据存在于读写缓存中,Broker从读写缓存中读取第一数据,若第一数据不存在于读写缓存中,Broker从磁盘读取第一数据。

在其中的一些实施例中,Broker从磁盘读取第一数据包括:在第一数据为冷数据时,Broker通过操作系统页缓存将第一数据从HDD写入读写缓存,在第一数据为热点数据时,Broker将第一数据从SSD写入读写缓存;Broker从读写缓存读取第一数据。

例如,Broker从磁盘读取第一数据时,Broker先判断第一数据是冷数据还是热点数据,若第一数据为冷数据时,Broker通过操作系统页缓存将第一数据从HDD写入读写缓存,然后Broker再从读写缓存中读取第一数据;若第一数据是热点数据时,Broker将第一数据从SSD写入读写缓存,然后Broker再从读写缓存中读取第一数据;

在其中的一些实施例中,在Broker接收到写数据请求时,Broker将第二数据写入读写缓存,其中,第二数据为写数据请求所请求写入的数据。

例如,在Broker接收到写数据请求时,Broker将写数据请求所请求写入的数据写入读写缓存,本实施例将写数据请求所请求写入的数据称为第二数据。

在其中的一些实施例中,在Broker将第二数据写入读写缓存之后,流处理系统的数据读写方法还包括如下步骤:在第二数据是冷数据时,Broker通过操作系统页缓存将第二数据从读写缓存写入HDD;在第二数据是热点数据时,Broker将第二数据从读写缓存写入SSD。

例如,在Broker将第二数据写入读写缓存之后,Broker还需判断第二数据是热点数据还是冷数据,若第二数据是冷数据时,Broker通过操作系统页缓存将第二数据从读写缓存写入HDD,若第二数据是热点数据时,Broker将第二数据从读写缓存写入SSD。

在其中的一些实施例中,流处理系统的数据读写方法还包括:在读写缓存剩余容量小于第一预设阈值的情况下,Broker将第三数据转存到磁盘,其中,第三数据为读写缓存当前存储的数据中最早被写入的数据。

例如,给读写缓存剩余容量设定预设阈值,在本实施例中该预设阈值称为第一预设阈值,在读写缓存剩余容量小于第一预设阈值的情况下,Broker将读写缓存当前存储的数据中最早被写入的数据转存到磁盘,本实施例将读写缓存当前存储的数据中最早被写入的数据称为第三数据。

另外,当读写缓存剩余容量小于第一预设阈值的情况下,读写缓存确定将第三数据转存到磁盘,也就是说出现异常情况时,当读写缓存容量不足时,Broker将第三数据转存到磁盘。

在其中的一些实施例中,将第三数据转写到磁盘包括:

在第三数据是热点数据时,Broker将第三数据从读写缓存转存到SSD;在第三数据是冷数据时,Broker通过操作系统页缓存将第三数据从读写缓存转存到HDD。

例如,将第三数据转写到磁盘包括:Broker还需先判断第三数据是热点数据还是冷数据,若第三数据是热点数据,Broker将第三数据从读写缓存转存到SSD;若第三数据是冷数据,Broker通过操作系统页缓存将第三数据从读写缓存转存到HDD。

在其中的一些实施例中,流处理系统的数据读写方法还包括:在Broker将第三数据从读写缓存转存到SSD时,当SSD内存不足时,Broker将第四数据从SSD删除,其中,第四数据为SSD当前存储的数据中最早被写入的数据。

例如,在Broker将第三数据从读写缓存转存到SSD时,当SSD的剩余容量不足时,Broker将SSD当前存储的数据中最早被写入的数据从SSD删除,其中,本实施例将SSD当前存储的数据中最早被写入的数据称为第四数据。

在其中的一些实施例中,流处理系统的数据读写方法还包括:Broker获取配置信息;Broker根据配置信息,判断当前读写的数据是热点数据还是冷数据。

例如,Broker获取配置信息;其中,配置信息是服务启动之前部分被指定数据是热点数据,未被指定部分的数据即为冷数据,Broker根据配置信息,判断当前读写的数据是热点数据还是冷数据。

在其中的一些实施例中,流处理系统的数据读写方法还包括:Broker根据在预设时间段内对读写数据的读写频率的统计信息,判断当前读写的数据是冷数据还是热点数据;其中,在当前读写的数据在预设时间段内的读写频率超过第二预设阈值时,确定当前读写的数据为热点数据;否则,确定当前读写的数据为冷数据。

例如,在预设时间段内,Broker对读写数据的读写频率进行统计,并根据统计信息判断当前读写的数据是冷数据还是热点数据。本实施例中可以对预设时间段内数据的读写频率设定预设阈值,本实施例将该预设阈值称为第二预设阈值,若当前读写的数据在预设时间段内的读写频率超过第二预设阈值时,确定当前读写的数据为热点数据;否则,确定当前读写的数据为冷数据。

例如,Broker启动后的半小时内,统计当前读写的数据的被读写的频率,根据最近10min被读写的频率来打分,将Top n的数据定为热数据。

在其中的一些实施例中,响应于读写数据请求,Broker通过读写缓存进行数据的读写操作包括:Broker判断读写数据请求是否为外部业务的读写数据请求;在判断到读写数据请求不为外部业务的读写数据请求的情况下,Broker通过操作系统页缓存和磁盘进行读写数据的读写操作;在判断到读写数据请求为外部业务的读写数据请求的情况下,Broker通过读写缓存进行读写数据的读写操作。

例如,流处理系统的Broker接收读写数据请求时,Broker对读写数据请求作出响应,Broker通过读写缓存进行数据的读写操作前,Broker还需判断读写数据请求是否为外部业务的读写数据请求;此处的外部业务是指生产消费业务。

如果读写数据请求是外部业务的读写数据请求时,Broker通过读写缓存进行读写数据的读写操作。如果读写数据请求不是外部业务的读写数据请求时,Broker通过操作系统页缓存和磁盘进行读写数据的读写操作,也就是说Broker将限制不是外部业务的数据进入读写缓存,将读写缓存全部的空间都留给外部业务,用于确保读写缓存完全为外部业务所使用,也就是说将读写缓存全部的空间都用于生产消费业务。

在本实施例中还提供了一种流处理系统,包括生产者、消费者和Broker;其中,生产者用于生产数据并将生产的数据写入Broker,消费者用于消费Broker存储的数据,Broker包括存储器和处理器,存储器中存储有计算机程序,处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

图2是其中一个实施例的流处理系统的数据读写方法流程框图,如图2所示,以Kafka流处理系统为例,Kafka流处理系统可以包括一个Broker或者多个Broker构成的流处理集群。其中,每个Broker部署在虚拟机(JVM)中,每个Broker在虚拟机中申请预设大小的堆内内存作为读写缓存。

在其中的一些实施例中,每个Broker可以分别配置一个SSD。不同虚拟机中的Broker可以共用同一物理机的SSD和HDD。

图3是其中一个优选实施例的流处理系统的数据读写方法流程框图,如图3所示,当Broker接收到生产者的写入数据请求后,Broker将数据写入到读写缓存中,后台会有线程定期执行刷盘动作,将冷数据写到操作系统页缓存,最后由OS将数据写到HDD盘中,对于热点数据直接持久化到SSD,不经过操作系统页缓存;

相关技术中,数据统一被写入到操作系统自带的操作系统页缓存中,由操作系统自己决定刷盘动作,将数据持久化到磁盘。

与相关技术相比,Broker将数据写入到Broker自己维护的读写缓存中,后台程序决定刷盘动作,Broker区分具有判断冷热数据的能力,并将冷数据和热点数据分别持久化到不同介质的盘,有效确保后续热点数据快速访问,提高了流处理系统的速度。

当Broker接收到消费者的读取数据请求后,Broker先从读写缓存中查找,如果读写缓存有消费者请求读取的数据,Broker将消费者请求读取的数据直接返回给消费者;如果读写缓存没有消费者请求读取的数据,Broker触发读盘机制,对于冷数据Broker将消费者请求读取的数据先写入到读写缓存中,再从读写缓存中将消费者请求读取的数据返回给消费者,对于热数据,Broker根据索引信息,直接去SSD中将消费者请求读取的数据写入到读写缓存,再从读写缓存中将消费者请求读取的数据返回给消费者。

在相关技术中,当Broker收到读取数据的请求时,Broker先从操作系统页缓存中找,如果操作系统页缓存中该数据没有被淘汰,Broker将该数据会直接返回消费者,避免了读取磁盘的动作;但是如果操作系统页缓存中没有该数据,需要读取磁盘,操作系统页缓存会主动淘汰掉一些数据,因为OS的行为不可控,会导致操作系统页缓存中的数据被污染,增加磁盘读取的次数,在磁盘找到该数据后,将该数据返回给消费者,严重影响生产和消费的速度。

与相关技术相比,Broker先从自己维护的读写缓存中查找,后台程序决定刷盘动作,Broker区分具有判断冷热数据的能力,有效确保后续热点数据快速访问,提高了流处理系统的速度。

当Broker接收到副本Broker从主Broker同步数据的请求后,Broker将主Broker的数据写入到副本Broker的读写缓存中,后台会有线程定期执行刷盘动作,将冷数据写到操作系统页缓存,最后由OS将数据写到HDD盘中,对于热点数据直接持久化到SSD,不经过操作系统页缓存;

Broker自己维护了缓存读写缓存,不再使用操作系统自带的操作系统页缓存,相比较相关技术中的使用操作系统自带的操作系统页缓存来说,更加可控,

而在相关技术中,Broker在处理Follower的数据同步请求的时候,会将从磁盘读取的数据重新加载到操作系统自带的操作系统页缓存中,这样会导致操作系统自带的操作系统页缓存被污染的情况发生,从而导致真正的消费者需要消费的数据被置换出,进而增加读取磁盘的次数,在读写压力大的场景下对生产消费业务速度影响很大。

与相关技术相比,本发明提高了流处理系统中生产消费的速度。

Broker严格按照时序来维护堆外内存空间读写缓存,当读写缓存达到淘汰条件,Broker会触发异步淘汰策略LRU,将热点数据保存到SSD盘,并将冷数据通过操作系统页缓存持久化到HDD。

又因为本发明中采用堆外内存保存读写缓存,可以有效减少GC的压力;由于给Broker配置一块SSD盘,当读写缓存达到淘汰条件,Broker会触发异步淘汰策略LRU,将热点数据直接保存到SSD盘,不经过操作系统页缓存,并将冷数据通过操作系统页缓存持久化到HDD,可以有效保证热点数据的快速读取和持久化,有效确保生产消费业务的响应速度。因为减少了对操作系统页缓存的依赖,可以满足基于Kubernetes的混合部署,降低服务器硬件成本。

在其中的一些实施例中,淘汰条件是读写缓存达到阈值。

应用程序维护的读写缓存采用LRU的缓存淘汰算法,可以确保将最不常访问的数据替换出去,不会和操作系统上其他的程序产生竞争关系,可以有效确保流处理系统的性能。

所谓LRU是Least Recently Used的缩写,即最近最少使用,是一种常用的数据置换算法,选择最近最久未使用的数据予以淘汰。该算法赋予每个数据一个访问字段,用来记录一个数据自上次被读写以来所经历的时间t,当须淘汰一个数据时,选择现有数据中其t值最大的,即最近最少使用的数据予以淘汰。

而在相关技术中,操作系统的淘汰策略应用程序不可控,直接使用操作系统自带的缓存,物理机上的所有进程共享这一块内存,会存在各种激烈竞争问题,无法有效流处理系统的性能。

在其中的一些实施例中,Broker处理生产请求时,淘汰条件是出现读写缓存不足。当读写缓存不足时,主动触发淘汰策略,也就是说将最老的数据清除掉,并持久化到对应的磁盘。

在其中的一些实施例中,Broker处理生产请求时,淘汰条件是SSD磁盘数据不够用。当SSD磁盘数据不够用时,会主动触发淘汰机制,同样将最老的数据清除掉,确保新的热点数据可以持久化到SSD。

在其中的一些实施例中,在Broker进程启动之前可以指定数据是热点数据。支持区分冷数据和热点数据,并支持冷数据和热点数据分级存储,有效保证热点数据的读取速度。如果服务启动之前不指定的热点数据,也可以在Broker进程启动之后,Broker进程会有自适应的过程,在一段时间内根据业务读写频率确定热点数据。而相关技术不支持区分冷数据和热点数据。

相关技术对物理机的操作系统页缓存有要求,为了保证服务质量,一般都是会独占一台物理机,或者是跟其他不占用操作系统页缓存的服务一起部署。和相关技术比较,本实施例可以得出本发明可以解决消费滞后问题,操作系统页缓存污染的问题,影响生产消费速度的问题,提高系统的稳定性。通过引入SSD盘,可以满足基于Kubernetes的混合部署,节约服务器硬件成本。因为本实施例不再依赖操作系统自带的操作系统页缓存,应用程序自己维护内存,可以在保证服务质量的同时和其他服务混合部署,同时节省硬件成本。

另外,Broker将堆外内存作为读写缓存,可以显著减少内存垃圾回收(GC)压力;控制Follower同步拉取的数据进入读写缓存,可以增加缓存的有效空间,减少读盘次数;严格按照时序来淘汰数据,保证不同滞后程度的消费者可以同时消费,可以最大限度的减少读盘次数,提高消费的速度,同时也不会对生产者速度造成很大影响,引入SSD盘将冷数据和热点数据分开持久化,可以有效保证热点数据的快速读取和持久化,并有效保证生产消费业务的响应速度。又因为本实施例减少了对操作系统页缓存的依赖,可以满足基于Kubernetes的混合部署。

在相关技术中,采用传统JVM系的语言,申请的堆内存由JVM管理,会涉及到GC(内存回收)的问题,会导致服务暂停,影响服务质量。和相关技术比较,本发明采用堆外内存来作为缓存,不再由JVM来负责垃圾回收,有效避免服务停顿的问题。

在本实施例中还提供了一种电子装置,包括存储器和处理器,该存储器中存储有计算机程序,该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地,上述电子装置还可以包括传输设备以及输入输出设备,其中,该传输设备和上述处理器连接,该输入输出设备和上述处理器连接。

可选地,上述处理器可以被设置为通过计算机程序执行以下步骤:

步骤1,接收读写数据请求;

步骤2,响应于读写数据请求,Broker通过读写缓存进行数据的读写操作,其中,读写缓存是由Broker从堆外内存中申请的预设内存空间。

需要说明的是,在本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例,在本实施例中不再赘述。

此外,结合上述实施例中提供的流处理系统的数据读写方法,在本实施例中还可以提供一种存储介质来实现。该存储介质上存储有计算机程序;该计算机程序被处理器执行时实现上述实施例中的任意一种流处理系统的数据读写方法。

应该明白的是,这里描述的具体实施例只是用来解释这个应用,而不是用来对它进行限定。根据本申请提供的实施例,本领域普通技术人员在不进行创造性劳动的情况下得到的所有其它实施例,均属本申请保护范围。

显然,附图只是本申请的一些例子或实施例,对本领域的普通技术人员来说,也可以根据这些附图将本申请适用于其他类似情况,但无需付出创造性劳动。另外,可以理解的是,尽管在此开发过程中所做的工作可能是复杂和漫长的,但是,对于本领域的普通技术人员来说,根据本申请披露的技术内容进行的某些设计、制造或生产等更改仅是常规的技术手段,不应被视为本申请公开的内容不足。

“实施例”一词在本申请中指的是结合实施例描述的具体特征、结构或特性可以包括在本申请的至少一个实施例中。该短语出现在说明书中的各个位置并不一定意味着相同的实施例,也不意味着与其它实施例相互排斥而具有独立性或可供选择。本领域的普通技术人员能够清楚或隐含地理解的是,本申请中描述的实施例在没有冲突的情况下,可以与其它实施例结合。

以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对专利保护范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请的保护范围应以所附权利要求为准。

14页详细技术资料下载
上一篇:一种医用注射器针头装配设备
下一篇:一种冗余数据标记及去除方法

网友询问留言

已有0条留言

还没有人留言评论。精彩留言会获得点赞!

精彩留言,会给你点赞!

技术分类