CN109271417B - 一种基于数据库的轻量级消息队列实现方法及存储设备 - Google Patents

Abstract

本发明涉及消息处理技术领域，特别涉及一种基于数据库的轻量级消息队列实现方法及存储设备。所述一种基于数据库的轻量级消息队列实现方法，包括步骤：创建数据库表；接收请求操作，并根据请求操作更新消息表；启动本地消息监听程序，若监听到存在未处理的消息，则对对应的未处理的消息在数据库中写入消费占用标注；推送标注成功的消息至本地消费队列；启动本地消费线程，监听本地消费队列，若存在待消费的消息，则获取消息并进行消费；消费结束后，更新消息状态。本发明的技术方案采用基于数据库表的消息处理方式，整个消息的生产、消费过程无需使用MQ中间件作为媒介，降低了硬件环境、***环境的各项配置要求，实现轻量级消息队列的功能。

Description

一种基于数据库的轻量级消息队列实现方法及存储设备

技术领域

本发明涉及消息处理技术领域，特别涉及一种基于数据库的轻量级消息队列实现方法及存储设备。

背景技术

传统的消息消费模型依赖于MQ消息中间件进行实现：由生产者程序生产消息放入指定的队列中，再由消费者程序从指定队列中拉取消息进行消费，同时通过日志对消费的过程进行记录，后续基于日志进行相关的消息跟踪。这样的消费模型存在以下缺点：

1、生产环境必须安装并配置对应的MQ中间件产品，对于软硬件环境、采购成本、兼容性等有更高的要求；

2、MQ产品中的消息通常被暂存在内存中，如果队列应用出现宕机，消息将存在丢失风险；并且多数只能使用自带的管理页面浏览队列中的消息，只能满足普适性监控需求，无法直观展示消息的具体内容、关键数据项、处理状态等，不便于对消息的个性化监控；

3、MQ产品中的消息在消费后即被销毁，对于消息的问题复现、异常追溯、消息重新消费等实现难度高；

4、MQ产品中同一消息，难以被多种业务共同消费，并且对于复杂业务场景、业务功能的适配有较大难度。

发明内容

为此，需要提供一种基于数据库的轻量级消息队列实现方法，用以解决上述提到的现有消费模型中存在的问题。具体技术方案如下：

一种基于数据库的轻量级消息队列实现方法，包括步骤：

创建数据库表，所述数据库表至少包括：消息表；

接收请求操作，并根据所述请求操作对应更新所述消息表；

启动本地消息监听程序，判断是否监听到未处理的消息，若监听到存在未处理的消息，则对对应的未处理的消息在数据库中写入消费占用标注；

推送标注成功的消息至本地消费队列；

启动本地消费线程，监听本地消费队列，判断是否监听到存在待消费的消息，若存在待消费的消息，则获取所述消息并进行消费；

消费结束后，更新消息状态。

进一步的，所述“并根据所述请求操作对应更新所述消息表”，还包括步骤：

根据所述请求操作生产消息，并将所述消息写入所述消息表。

进一步的，还包括步骤：

启动消息归档线程，并扫描过期消息，对过期消息进行归档。

进一步的，还包括步骤：

启动死信修复线程，扫描符合预设死信条件的消息，根据预定义策略对符合预设死信条件的消息进行修复。

进一步的，所述消息表用于：存储外部程序产生的消息、并记录消息的核心控制字段；

所述数据库表还包括：复杂消息体表，所述复杂消息体表用于：存储复杂、数据量大的业务消息。

为解决上述技术问题，还提供了一种存储设备，具体技术方案如下：

一种存储设备，其中存储有指令集，所述指令集用于执行：

创建数据库表，所述数据库表至少包括：消息表；

接收请求操作，并根据所述请求操作对应更新所述消息表；

启动本地消息监听程序，判断是否监听到未处理的消息，若监听到存在未处理的消息，则对对应的未处理的消息在数据库中写入消费占用标注；

推送标注成功的消息至本地消费队列；

启动本地消费线程，监听本地消费队列，判断是否监听到存在待消费的消息，若存在待消费的消息，则获取所述消息并进行消费；

消费结束后，更新消息状态。

进一步的，所述指令集还用于执行：

所述“并根据所述请求操作对应更新所述消息表”，还包括步骤：

根据所述请求操作生产消息，并将所述消息写入所述消息表。

进一步的，所述指令集还用于执行：

启动消息归档线程，并扫描过期消息，对过期消息进行归档。

进一步的，所述指令集还用于执行：

启动死信修复线程，扫描符合预设死信条件的消息，根据预定义策略对符合预设死信条件的消息进行修复。

进一步的，所述指令集还用于执行：

所述消息表用于：存储外部程序产生的消息、并记录消息的核心控制字段；

所述数据库表还包括：复杂消息体表，所述复杂消息体表用于：存储复杂、数据量大的业务消息。

本发明的有益效果是：

1、本发明的技术方案采用基于数据库表的消息处理方式，整个消息的生产、消费过程无需使用MQ中间件作为媒介，降低了硬件环境、***环境的各项配置要求，实现轻量级消息队列的功能；

2、其次消息利用数据库进行存储，解决了消息存放在内存中，因宕机造成的丢失风险，并且基于数据库，可开发各类的管理页面，对消息进行查询、管理、统计，大大降低了监控难度；

3、由于消息持久化在数据库，消费后不立即销毁，并记录异常堆栈等日志消息。消息的追溯、统计监控依赖于数据库的查询功能。查询指定过滤条件的消息即可追溯消息消费过程中存在的各类异常，同时通过消息编号，更改指定消息的状态，变更状态即可进行消息的重新消费和问题复现。相比于MQ需要进行发送方重新请求，该方法极大的降低了消息追溯难度。

附图说明

图1为具体实施方式所述一种基于数据库的轻量级消息队列实现方法的流程图；

图2为具体实施方式所述消息表、复杂消息体表示意图；

图3为具体实施方式所述一种存储设备的示意图。

附图标记说明：

300、存储设备。

具体实施方式

为详细说明技术方案的技术内容、构造特征、所实现目的及效果，以下结合具体实施例并配合附图详予说明。

请参阅图1至图2，在本实施方式中，一种基于数据库的轻量级消息队列实现方法可应用在一种存储设备上，所述存储设备，包括但不限于：个人计算机、服务器、通用计算机、专用计算机、网络设备、嵌入式设备、可编程设备、智能移动终端等。具体实现如下：

步骤S101：创建数据库表，所述数据库表至少包括：消息表。

步骤S102：接收请求操作，并根据所述请求操作对应更新所述消息表。

步骤S103：启动本地消息监听程序，判断是否监听到未处理的消息，若监听到存在未处理的消息，则对对应的未处理的消息在数据库中写入消费占用标注。

步骤S104：推送标注成功的消息至本地消费队列。

步骤S105：启动本地消费线程，监听本地消费队列，判断是否监听到存在待消费的消息，若存在待消费的消息，则获取所述消息并进行消费。

步骤S106：消费结束后，更新消息状态。

以上步骤具体可采用如下方式：

步骤S101：

创建数据库表，其核心表为消息表，在本实施方式中，亦创建有另外一个表复杂消息体表，其中所述消息表用于：存储外部程序产生的消息、并记录消息的核心控制字段；所述复杂消息体表用于：存储复杂、数据量大的业务消息。消息表是必须的，复杂消息体表可根据实际业务的复杂程度可选择性地决定是否创建。如图2所示，表的内容可如下所示：

创建好数据库表后，执行步骤S102，在本实施方式中，所述“并根据所述请求操作对应更新所述消息表”，还包括步骤：根据所述请求操作生产消息，并将所述消息写入所述消息表。具体可采用如下方式：

接收外部调用请求，请求形式不限；支持http请求、WebService请求、RMI调用、类方法调用等；

将外部的请求转换为对应的消息对象，并将消息对象写入数据库；初次写入时，此时消息的状态为：0：待消费；

通过该步骤可扩展出主题订阅、广播通知等更多功能，在生产消息的时候，根据消息头信息上的控制字段，在指定表上生成对应的消息即可。如某应用APP1内，用户B/用户C订阅了用户A的消息；在生产A的消息时，获取订阅关系(关系可存储置数据库表、或者缓存***中)，创建订阅消息，并将消息的目标编号，指向订阅者B/订阅者C，就可生产订阅者的消息。

在本实施方式中，在执行步骤S103前，先创建应用本地的消费队列，用于存放本地待消费的消息，同时启动本地的消息监听线程，定时轮询扫描消息表。

将扫描到的消息，进行逐一遍历，判断是否监听到未处理的消息，若监听到存在未处理的消息，则利用sql语句方式标注消费占用，以防止其他线程应用重复消费：

核心语句：Update T_MSG t Set t.status＝‘1’Where t.status＝’0’And t.id＝‘xxx’；

执行该语句后，从程序端获取执行影响的条数，如果非0，说明已成功标注该消息；为0时，说明该消息已被其他线程或节点标注，直接略过。

步骤S104：

将标注成功的消息推送本地的消费队列，此时消息状态为1：消费中，等待消费者线程消费。

步骤S105：

启动本地的消费线程，监听本地的消费队列；监听到本地队列中存在待消费的消息时，获取并进行消费。

步骤S106：

消费结束后，无论成功、失败，都更新消息的状态；记录相关信息。其中，如果消费成功，状态变更为2：成功，记录日志；如果为失败，变更为3：失败。同时记录异常类型、日志。

同样通过以上步骤如果业务需求允许进行自动重试功能，此时可根据异常分类划分，将指定的消息状态变更为0：待消费。并在可执行时间上进行设置下次重试的开始时间，程序后续即可自动重试。

进一步的，上述所有的线程均支持多线程调用，可开启多线程模式，以提高***的处理性能。

进一步的，在其它实施方式中，还可运行其它辅助流程用以管理消息在消费之外的环节。如：

启动消息归档线程，并扫描过期消息，对过期消息进行归档。具体可采用如下方式：

扫描过期消息，扫描可依赖定时任务组件的功能，进行定期/定时扫描，过期策略通常可根据实际存储、业务需求进行调整，例如15天、1个月等。

将过期的消息进行归档。归档的消息主体，除了消息外，还包括复杂的Blob形式的消息，由于在每个表中都定义了记录的创建时间，在归档时无需逐一进行主子记录的查询，直接按照创建时间进行归档即可，大幅提高了归档的效率。

归档的策略可根据实际业务需求自定义，例如移除、转移、或者直接利用数据库的分区表保存均可。

还可启动死信修复线程，扫描符合预设死信条件的消息，根据预定义策略对符合预设死信条件的消息进行修复。具体可采用如下方式：

首先对死消息的定义做以下说明：死信消息定义：对于那些消费过程中因各类突出情况产生异常过程、导致无法被正确消费的消息，例如某一消息刚被标注为占用状态，而此时应用关闭，导致其未被进行消费；又或者某一消息因为网络、IO等原因导致消费失败。具体步骤如下：

扫描符合死信消息定义的消息，死信消息的定义可根据业务需求进行扩展和调整，包括因为网络等原因消费失败的消息均可被列为死信消息。

针对死信消息，可根据自定义策略进行修复，例如上述提到：

被占用却未被消费的消息，可修复状态为0，让消费程序重新消费；

因网络等问题，消费异常的消息，可制定重试策略，重置消息的状态，进行重新消费尝试。

在其它实施方式中，一实施例如下：

使用上述实现方式，实现业务报文的转发功能

消息表设计如上，该实施例由于存在具体的业务报文，业务报文大小>4000字符长度，<1MB；故使用复杂消息体表；

接收外部请求，根据消息中的头信息，持久为数据库中消息，主要字段摘要：

创建本地消费队列，启动线程，轮询监听待消费的消息，

以下为待处理消息轮询线程的代码片段：

将扫描到的消息，进行逐一遍历，并利用sql语句方式标注消费占用，以防止其他线程应用重复消费，代码片段：

其中，service.checkUndoTaskIndex4Cluster的核心语句：

Update T_MSG t Set t.status＝‘1’Where t.status＝’0’And t.id＝‘xxx’；执行该语句，并返回受影响的记录条数，如果返回的为0，则表明当前消息已经被其他应用所标注，放弃处理；如果返回值＝1，则表明，当前应用已成功标注了该消息的处理。此时消息的状态为1：正在处理中，同时将标注要处理的消息推送至本地的消费队列中，等待处理。

启动消费线程，监听本地消费队列，存在待消息的消息时，进行处理。

以下为消费者线程的代码片段：

在其它实施方式中，当需要手动重消费时(开发调试、异常复现、批量重试)，只需执行update语句，变更消息的状态即可。

语句片段：Update T_MSG t Set t.stauts＝‘0’Where t.status＝‘3’[And其他过滤条件…]；

当需要开启自动重消费时，可选择：

1、在消费后，将消息的状态更改为0，并设置下次重试时间，累加重试次数，即可自动实现定期的消费重试。建议设定重试的上限次数和合理的重试间隔，以便于及时中断某些消息的处理，节省***开支。

2、利用死信消息修复线程，对于指定状态、指定异常类型的消息，自动进行状态重置，即可完成重新消费。

1、本发明的技术方案采用基于数据库表的消息处理方式，整个消息的生产、消费过程无需使用MQ中间件作为媒介，降低了硬件环境、***环境的各项配置要求，实现轻量级消息队列的功能；

2、其次消息利用数据库进行存储，解决了消息存放在内存中，因宕机造成的丢失风险，并且基于数据库，可开发各类的管理页面，对消息进行查询、管理、统计，大大降低了监控难度；

3、由于消息持久化在数据库，消费后不立即销毁，并记录异常堆栈等日志消息。消息的追溯、统计监控依赖于数据库的查询功能。查询指定过滤条件的消息即可追溯消息消费过程中存在的各类异常，同时通过消息编号，更改指定消息的状态，变更状态即可进行消息的重新消费和问题复现。相比于MQ需要进行发送方重新请求，该方法极大的降低了消息追溯难度。

请参阅图3，在本实施方式中，一种存储设备300的具体实施方式如下：

一种存储设备300，其中存储有指令集，所述指令集用于执行：

创建数据库表，所述数据库表至少包括：消息表；

接收请求操作，并根据所述请求操作对应更新所述消息表；

启动本地消息监听程序，判断是否监听到未处理的消息，若监听到存在未处理的消息，则对对应的未处理的消息在数据库中写入消费占用标注；

推送标注成功的消息至本地消费队列；

启动本地消费线程，监听本地消费队列，判断是否监听到存在待消费的消息，若存在待消费的消息，则获取所述消息并进行消费；

消费结束后，更新消息状态。具体可采用如下方式：

创建数据库表，其核心表为消息表，在本实施方式中，亦创建有另外一个表复杂消息体表，其中所述消息表用于：存储外部程序产生的消息、并记录消息的核心控制字段；所述复杂消息体表用于：存储复杂、数据量大的业务消息。消息表是必须的，复杂消息体表可根据实际业务的复杂程度可选择性地决定是否创建。如图2所示，表的内容可如下所示：

创建好数据库表后，进一步的，所述指令集还用于执行：

所述“并根据所述请求操作对应更新所述消息表”，还包括步骤：

根据所述请求操作生产消息，并将所述消息写入所述消息表。具体可采用如下方式：

接收外部调用请求，请求形式不限；支持http请求、WebService请求、RMI调用、类方法调用等；

将外部的请求转换为对应的消息对象，并将消息对象写入数据库；初次写入时，此时消息的状态为：0：待消费；

通过该步骤可扩展出主题订阅、广播通知等更多功能，在生产消息的时候，根据消息头信息上的控制字段，在指定表上生成对应的消息即可。如某应用APP1内，用户B/用户C订阅了用户A的消息；在生产A的消息时，获取订阅关系(关系可存储置数据库表、或者缓存***中)，创建订阅消息，并将消息的目标编号，指向订阅者B/订阅者C，就可生产订阅者的消息。

在本实施方式中，在启动本地消息监听程序前，先创建应用本地的消费队列，用于存放本地待消费的消息，同时启动本地的消息监听线程，定时轮询扫描消息表。

将扫描到的消息，进行逐一遍历，判断是否监听到未处理的消息，若监听到存在未处理的消息，则利用sql语句方式标注消费占用，以防止其他线程应用重复消费：

核心语句：Update T_MSG t Set t.status＝‘1’Where t.status＝’0’And t.id＝‘xxx’；

执行该语句后，从程序端获取执行影响的条数，如果非0，说明已成功标注该消息；为0时，说明该消息已被其他线程或节点标注，直接略过。

将标注成功的消息推送本地的消费队列，此时消息状态为1：消费中，等待消费者线程消费。

启动本地的消费线程，监听本地的消费队列；监听到本地队列中存在待消费的消息时，获取并进行消费。

消费结束后，无论成功、失败，都更新消息的状态；记录相关信息。其中，如果消费成功，状态变更为2：成功，记录日志；如果为失败，变更为3：失败。同时记录异常类型、日志。

同样通过以上步骤如果业务需求允许进行自动重试功能，此时可根据异常分类划分，将指定的消息状态变更为0：待消费。并在可执行时间上进行设置下次重试的开始时间，程序后续即可自动重试。

进一步的，上述所有的线程均支持多线程调用，可开启多线程模式，以提高***的处理性能。

进一步的，所述指令集还用于执行：

启动消息归档线程，并扫描过期消息，对过期消息进行归档。具体可采用如下方式：

扫描过期消息，扫描可依赖定时任务组件的功能，进行定期/定时扫描，过期策略通常可根据实际存储、业务需求进行调整，例如15天、1个月等。

将过期的消息进行归档。归档的消息主体，除了消息外，还包括复杂的Blob形式的消息，由于在每个表中都定义了记录的创建时间，在归档时无需逐一进行主子记录的查询，直接按照创建时间进行归档即可，大幅提高了归档的效率。

归档的策略可根据实际业务需求自定义，例如移除、转移、或者直接利用数据库的分区表保存均可。

进一步的，所述指令集还用于执行：

启动死信修复线程，扫描符合预设死信条件的消息，根据预定义策略对符合预设死信条件的消息进行修复。具体可采用如下方式：

首先对死消息的定义做以下说明：死信消息定义：对于那些消费过程中因各类突出情况产生异常过程、导致无法被正确消费的消息，例如某一消息刚被标注为占用状态，而此时应用关闭，导致其未被进行消费；又或者某一消息因为网络、IO等原因导致消费失败。具体步骤如下：

扫描符合死信消息定义的消息，死信消息的定义可根据业务需求进行扩展和调整，包括因为网络等原因消费失败的消息均可被列为死信消息。

针对死信消息，可根据自定义策略进行修复，例如上述提到：

被占用却未被消费的消息，可修复状态为0，让消费程序重新消费；

因网络等问题，消费异常的消息，可制定重试策略，重置消息的状态，进行重新消费尝试。

进一步的，所述指令集还用于执行：

所述消息表用于：存储外部程序产生的消息、并记录消息的核心控制字段；

所述数据库表还包括：复杂消息体表，所述复杂消息体表用于：存储复杂、数据量大的业务消息。

在其它实施方式中，一实施例如下：

使用上述实现方式，实现业务报文的转发功能

消息表设计如上，该实施例由于存在具体的业务报文，业务报文大小>4000字符长度，<1MB；故使用复杂消息体表；

接收外部请求，根据消息中的头信息，持久为数据库中消息，主要字段摘要：

创建本地消费队列，启动线程，轮询监听待消费的消息，

以下为待处理消息轮询线程的代码片段：

将扫描到的消息，进行逐一遍历，并利用sql语句方式标注消费占用，以防止其他线程应用重复消费，代码片段：

其中，service.checkUndoTaskIndex4Cluster的核心语句：

Update T_MSG t Set t.status＝‘1’Where t.status＝’0’And t.id＝‘xxx’；执行该语句，并返回受影响的记录条数，如果返回的为0，则表明当前消息已经被其他应用所标注，放弃处理；如果返回值＝1，则表明，当前应用已成功标注了该消息的处理。此时消息的状态为1：正在处理中，同时将标注要处理的消息推送至本地的消费队列中，等待处理。

启动消费线程，监听本地消费队列，存在待消息的消息时，进行处理。

以下为消费者线程的代码片段：

在其它实施方式中，当需要手动重消费时(开发调试、异常复现、批量重试)，只需执行update语句，变更消息的状态即可。

语句片段：Update T_MSG t Set t.stauts＝‘0’Where t.status＝‘3’[And其他过滤条件…]；

当需要开启自动重消费时，可选择：

1、在消费后，将消息的状态更改为0，并设置下次重试时间，累加重试次数，即可自动实现定期的消费重试。建议设定重试的上限次数和合理的重试间隔，以便于及时中断某些消息的处理，节省***开支。

2、利用死信消息修复线程，对于指定状态、指定异常类型的消息，自动进行状态重置，即可完成重新消费。

1、本发明的技术方案采用基于数据库表的消息处理方式，整个消息的生产、消费过程无需使用MQ中间件作为媒介，降低了硬件环境、***环境的各项配置要求，实现轻量级消息队列的功能；

2、其次消息利用数据库进行存储，解决了消息存放在内存中，因宕机造成的丢失风险，并且基于数据库，可开发各类的管理页面，对消息进行查询、管理、统计，大大降低了监控难度；

3、由于消息持久化在数据库，消费后不立即销毁，并记录异常堆栈等日志消息。消息的追溯、统计监控依赖于数据库的查询功能。查询指定过滤条件的消息即可追溯消息消费过程中存在的各类异常，同时通过消息编号，更改指定消息的状态，变更状态即可进行消息的重新消费和问题复现。相比于MQ需要进行发送方重新请求，该方法极大的降低了消息追溯难度。

需要说明的是，尽管在本文中已经对上述各实施例进行了描述，但并非因此限制本发明的专利保护范围。因此，基于本发明的创新理念，对本文所述实施例进行的变更和修改，或利用本发明说明书及附图内容所作的等效结构或等效流程变换，直接或间接地将以上技术方案运用在其他相关的技术领域，均包括在本发明的专利保护范围之内。

Claims (10)

1.一种基于数据库的轻量级消息队列实现方法，其特征在于，包括步骤：

创建数据库表，所述数据库表至少包括：消息表；

接收请求操作，并根据所述请求操作对应更新所述消息表；

启动本地消息监听程序，判断是否监听到未处理的消息，若监听到存在未处理的消息，则对对应的未处理的消息在数据库中写入消费占用标注；

推送标注成功的消息至本地消费队列；

启动本地消费线程，监听本地消费队列，判断是否监听到存在待消费的消息，若存在待消费的消息，则获取所述消息并进行消费；

消费结束后，更新消息状态。

2.根据权利要求1所述的一种基于数据库的轻量级消息队列实现方法，其特征在于，所述“并根据所述请求操作对应更新所述消息表”，还包括步骤：

根据所述请求操作生产消息，并将所述消息写入所述消息表。

3.根据权利要求1所述的一种基于数据库的轻量级消息队列实现方法，其特征在于，还包括步骤：

启动消息归档线程，并扫描过期消息，对过期消息进行归档。

4.根据权利要求1所述的一种基于数据库的轻量级消息队列实现方法，其特征在于，还包括步骤：

启动死信修复线程，扫描符合预设死信条件的消息，根据预定义策略对符合预设死信条件的消息进行修复。

5.根据权利要求1所述的一种基于数据库的轻量级消息队列实现方法，其特征在于，

所述消息表用于：存储外部程序产生的消息、并记录消息的核心控制字段；

所述数据库表还包括：复杂消息体表，所述复杂消息体表用于：存储复杂、数据量大的业务消息。

6.一种存储设备，其中存储有指令集，其特征在于，所述指令集用于执行：

创建数据库表，所述数据库表至少包括：消息表；

接收请求操作，并根据所述请求操作对应更新所述消息表；

启动本地消息监听程序，判断是否监听到未处理的消息，若监听到存在未处理的消息，则对对应的未处理的消息在数据库中写入消费占用标注；

推送标注成功的消息至本地消费队列；

启动本地消费线程，监听本地消费队列，判断是否监听到存在待消费的消息，若存在待消费的消息，则获取所述消息并进行消费；

消费结束后，更新消息状态。

7.根据权利要求6所述的一种存储设备，其特征在于，所述指令集还用于执行：

所述“并根据所述请求操作对应更新所述消息表”，还包括步骤：

根据所述请求操作生产消息，并将所述消息写入所述消息表。

8.根据权利要求6所述的一种存储设备，其特征在于，所述指令集还用于执行：

启动消息归档线程，并扫描过期消息，对过期消息进行归档。

9.根据权利要求6所述的一种存储设备，其特征在于，所述指令集还用于执行：

启动死信修复线程，扫描符合预设死信条件的消息，根据预定义策略对符合预设死信条件的消息进行修复。

10.根据权利要求6所述的一种存储设备，其特征在于，所述指令集还用于执行：

所述消息表用于：存储外部程序产生的消息、并记录消息的核心控制字段；

所述数据库表还包括：复杂消息体表，所述复杂消息体表用于：存储复杂、数据量大的业务消息。

Images