一种流计算应用中实现持久化的方法及装置制造方法及图纸

本申请公开了一种流计算应用中实现持久化的方法及装置，包括当前批次消息消费成功，根据第一起始偏移量和预先设置的持久化间隔，判断是否需要进行持久化操作；在需要进行持久化操作时，按照第二起始偏移量指示的消息位置进行持久化处理，并在持久化成功后，将第一起始偏移量和第二起始偏移量均更新为下一批次消息的起始偏移量。本申请中的持久化操作是在持久化间隔后进行的，增大了磁盘持久化的时间间隔，从而大大提高实时计算效率。在故障恢复时，最多只需要重新消费持久化间隔内的批次的消息，避免了现有同步持久化中频繁写磁盘带来的性能瓶颈，实时计算的消息吞吐性能提升了一个数量级；同时，将故障恢复带来的延迟缩短到了秒级，不会影响实时性。

【技术实现步骤摘要】

本申请涉及流计算技术，尤指一种流计算应用中是实现持久化的方法及装置。
技术介绍
通常，在流计算中将数据流称为消息，而对数据流的一系列计算、处理称为消费。流计算产品主要用于实时计算。实时计算通常在内存中进行，而计算结果要通过某种途径保存并展现出来。目前，主要采用缓存或者持久化到磁盘如数据库（非内存数据库）中两种方式对计算结果进行保存。其中，由于缓存方式没有物理磁盘输入/输出（I/O），因此，缓存方式有着非常卓越的消息吞吐能力；但是，由于计算结果没有持久化，缓存方式几乎没有容错能力，也就是说，一旦出现应用程序中断、服务器宕机、缓存被清空等情况，保存在缓存中的计算结果将无法恢复。而采用持久化到磁盘中的方式，可以实现最高级别的容错功能，但是，持久化到磁盘涉及到大量的磁盘写，这又降低了流计算的计算速度，执行效率大约比采用缓存的方式低一个数量级。图1为现有基本的容错型流计算应用中数据流向示意图，如图1所示，消息中间件集群发送的消息流是一条一条的。为了便于容错，通常流计算产品如图1中的流计算集群对消息流进行消费是以批次为单位的，即将若干条消息捆绑在一个批次中，每一个批次有一个唯一的标识（ID）。对于一个批次的消息，只有批次内的每一条消息都被成功消费后，这个批次的消息才被标记为被成功消费；只要一个批次内有一条消息没有被消费成功，整个批次的消息就会被消息中间件重新发送，被流计算集群重新消费。最终处理过的消息流存储到磁盘称之为持久化，这一步对于故障恢复是至关重要的。一旦出现应用程序中断、服务器宕机等情况，只有持久化操作才能保证实时计算的结果不丢失。故障恢复、实时计算应用重启时，需要重新从磁盘中加载实时计算的过程数据与结果数据，将所有状态恢复到故障发生之前的一个正确的时间点。在图1所示的ZooKeeper集群中存储有消息中间件集群发送的消息所在的消息队列的偏移量。当消息中间件集群发送给流计算集群一批消息时，ZooKeeper中会记录这批次的消息在消息队列中的起始偏移量。如果这批次的消息被流计算集群成功消费，那么，消息中间件集群会发送下一批次消息，ZooKeeper中记录的偏移量随之更新为下一批次消息在消息队列中的起始偏移量；如果这批次消息被消费失败，那么，流计算集群会从ZooKeeper集群中重新读取这批次消息的偏移量，然后到消息中间件集群中重新请求该批次消息，以实现消息的失败重发。
技术实现思路
为了解决上述技术问题，本申请提供了一种流计算应用中实现持久化的方法及装置，能够保证故障后数据的安全恢复，提高实时计算效率。为了达到本申请目的，本申请提供一种流计算应用中实现持久化的方法，包括：当前批次消息消费成功，根据用于保存当前正在消费的批次消息在消息队列中的起始位置的第一起始偏移量和预先设置的持久化间隔，判断是否需要进行持久化操作；在需要进行持久化操作时，按照用于保存最近一次持久化操作的下一批次消息在消息队列中的起始位置的第二起始偏移量指示的消息位置进行持久化处理；持久化操作成功后，分别更新第一起始偏移量和第二起始偏移量为下一批次消息的起始偏移量。所述流计算应用正常启动，或者故障恢复后启动时，该方法还包括：根据所述第二起始偏移量请求消息，同时将所述第一起始偏移量的值更改为第二起始偏移量的值。所述第二起始偏移量的值为空或者未保存有第二起始偏移量时，所述当前批次消息位于消息中间件的消息队列的起始位置；同时还包括：设置所述第一起始偏移量的值为空。所述持久化操作失败，该方法还包括：按照所述第一起始偏移量指示，重新对所述当前批次消息中的消息进行消费。所述判断是否需要进行持久化操作包括：将所述当前批次的ID除以持久化间隔，当其余数为零时，判断出需要进行持久化操作；其中，批次ID为从1开始以递增步长为1的整数。所述流计算应用正常启动，或者故障恢复后启动时，所述批次ID接着流计算应用停止前的最后一个成功持久化过的批次ID继续递增步长为1递增。本申请还公开一种流计算应用中实现持久化的装置，至少存储模块、判断模块，以及处理模块，其中，存储模块，其中保存有持久化间隔、用于保存当前正在消费的批次消息在消息队列中的起始位置的第一起始偏移量，以及用于保存最近一次持久化操作的下一批次消息在消息队列中的起始位置的第二起始偏移量；判断模块，当前批次消息消费成功，根据存储模块中保存的第一起始偏移量和预先设置的持久化间隔，判断出需要进行持久化操作时向处理模块发送持久化通知；处理模块，接收到来自判断模块的持久化通知，按照存储模块中保存的第二起始偏移量指示的消息位置进行持久化操作；并在持久化操作成功后，将第一起始偏移量和第二起始偏移量均更新为下一批次消息的起始偏移量。所述处理模块进一步用于：在流计算应用正常启动，或者故障恢复后启动时，根据所述存储模块中保存的第二起始偏移量从消息中间件中请求消息，同时将所述存储模块中保存的第一起始偏移量的值更改为第二起始偏移量的值。所述处理模块还进一步用于，在所述持久化操作失败时，按照所述存储模块中保存的第一起始偏移量指示，重新对从消息中间件中当前批次消息中的消息进行消费。所述判断模块具体用于：将所述第一起始偏移量所指示的当前批次的ID除以所述持久化间隔，当其余数为零时，判断出需要进行持久化操作，向所述处理模块发送持久化通知；其中，批次ID为从1开始以递增步长为1的整数。本申请提供的方案包括当前批次消息消费成功，根据用于保存当前正在消费的批次消息在消息队列中的起始位置的第一起始偏移量和预先设置的持久化间隔，判断是否需要进行持久化操作；在需要进行持久化操作时，按照用于保存最近一次持久化操作的下一批次消息在消息队列中的起始位置的第二起始偏移量指示的消息位置进行持久化处理，并在持久化成功后，将第一起始偏移量和第二起始偏移量均更新为下一批次消息的起始偏移量。本申请中的持久化操作不是针对每个批次成功消费后都要进行的，而是在一个预先设置的时间间隔即持久化间隔后进行的，增大了磁盘持久化的时间间隔，从而大大提高实时计算效率。这样，在故障恢复时，最多只需要重新消费持久化间隔内的批次的消息，与现有同步持久化相比，避免了同步持久化方案中频繁写磁盘带来的性能瓶颈，实时计算的消息吞吐性能提升了一个数量级，而且达到了与缓存方式的方案在同一个数量级；同时，将故障恢复带来的延迟缩短到了秒级本文档来自技高网...

【技术保护点】
一种流计算应用中实现持久化的方法，其特征在于，包括：当前批次消息消费成功，根据用于保存当前正在消费的批次消息在消息队列中的起始位置的第一起始偏移量和预先设置的持久化间隔，判断是否需要进行持久化操作；在需要进行持久化操作时，按照用于保存最近一次持久化操作的下一批次消息在消息队列中的起始位置的第二起始偏移量指示的消息位置进行持久化处理；持久化操作成功后，分别更新第一起始偏移量和第二起始偏移量为下一批次消息的起始偏移量。

【技术特征摘要】
1.一种流计算应用中实现持久化的方法，其特征在于，包括：
当前批次消息消费成功，根据用于保存当前正在消费的批次消息在消息
队列中的起始位置的第一起始偏移量和预先设置的持久化间隔，判断是否需
要进行持久化操作；
在需要进行持久化操作时，按照用于保存最近一次持久化操作的下一批
次消息在消息队列中的起始位置的第二起始偏移量指示的消息位置进行持久
化处理；
持久化操作成功后，分别更新第一起始偏移量和第二起始偏移量为下一
批次消息的起始偏移量。
2.根据权利要求1所述的方法，其特征在于，所述流计算应用正常启动，
或者故障恢复后启动时，该方法还包括：
根据所述第二起始偏移量请求消息，同时将所述第一起始偏移量的值更
改为第二起始偏移量的值。
3.根据权利要求2所述的方法，其特征在于，所述第二起始偏移量的值
为空或者未保存有第二起始偏移量时，所述当前批次消息位于消息中间件的
消息队列的起始位置；
同时还包括：设置所述第一起始偏移量的值为空。
4.根据权利要求1所述的方法，其特征在于，所述持久化操作失败，该
方法还包括：按照所述第一起始偏移量指示，重新对所述当前批次消息中的
消息进行消费。
5.根据权利要求2或4所述的方法，其特征在于，所述判断是否需要进
行持久化操作包括：将所述当前批次的ID除以持久化间隔，当其余数为零
时，判断出需要进行持久化操作；
其中，批次ID为从1开始以递增步长为1的整数。
6.根据权利要求5所述的方法，其特征在于，所述流计算应用正常启动，
或者故障恢复后启动时，所述批次ID接着流计算应用停止前的最后一个成

\t功持久化过...

【专利技术属性】
技术研发人员：刘健男，
申请(专利权)人：阿里巴巴集团控股有限公司，
类型：发明
国别省市：开曼群岛;KY