融合消息队列的数据库与融合事务的实现方法与流程

本技术涉及数据库，具体涉及一种融合消息队列的数据库与融合事务的实现方法。

背景技术：

1、消息队列是一种用于在应用程序之间传递消息的技术。它是一种在消息生产者和消息消费者之间解耦合的通信方式，允许发送者将消息发送到队列中，而不需要立即将消息传递给接收者。消息队列通常用于实现异步通信，其中消息生产者和消息消费者可以在不同的时间和速度处理消息。

2、常见的消息队列系统包括rabbitmq、apache kafka、amazon sqs等。它们提供了不同的特性和适用场景，可以根据具体需求选择合适的消息队列系统。

3、数据库是一种用于存储和组织数据的软件系统。它们被设计用来有效地管理大量的数据，允许用户进行快速的检索、更新和管理数据。

4、数据库提供了数据的持久性存储，确保数据在系统关闭或重启后仍然可用。它们还支持事务处理，允许用户执行一系列操作，并在必要时将它们作为一个原子操作进行提交或回滚。

5、常见的数据库类型包括关系型数据库(如mysql、postgresql、oracle)和非关系型数据库(如mongodb、redis、elasticsearch)，它们针对不同的数据存储和访问需求提供了不同的解决方案。

6、目前在需要异步处理和事件驱动的应用程序中需要集成数据库和消息队列。请参见图1，图1为相关技术中一种数据库和消息队列集成的结构示意图。如图1所示，100为应用程序，101为数据库，102为消息队列。通常的做法是应用100将要发送的信息持久化在数据库101中的库表(可以是缓存表)，然后通过触发器或定时任务从该库表中提取要发送的消息至消息队列完成消息消费。

7、这种集成利用了数据库的存储特性方便持久化要发送的消息，防止整个系统异常导致消息丢失。但是如图1所示应用程序需要对接数据库101和消息队列102，第一方面，对于开发应用程序的研发工程师来讲，需要开发复杂的程序来保证数据库101和消息队列102之间的数据通信开发工作量大，很不友好；第二方面，在融合事务中(融合事务包括在需要跨数据库系统配合完成操作的场景中，本端数据库的库表操作和通知对端数据库执行相关操作的通知操作)，如果只利用数据库自身的事务机制，只能保证数据库操作和将要发送的消息持久化在库表中的原子性，没法将消息队列102发送消息是否成功也列入事务中，即如果最终消息发送失败没法做到事务回滚。在一些方案中使用如图2所示利用分布式中间件203(复杂的事务机制)来实现完整融合事务，如此开发难度大，太依赖单点分布式中间件，容易发生数据阻塞，带来单点风险，导致参与者出现收到的提交/回滚消息不一致，出现数据不一致的问题，事务处理失效。

技术实现思路

1、有鉴于此，本技术公开一种融合消息队列的数据库。所述数据库包括消息处理中心；所述消息处理中心与消息生产者和消息消费者通过所述数据库的通信机制进行通信连接；所述数据库还包括为所述消息生产者和消息消费者分配的消息队列。所述消息生产者，用于产生消息，并发送至所述消息处理中心；所述消息处理中心，用于响应于接收到所述消息，基于所述数据库内核支持的重做日志机制将所述消息写入redo log，以及将所述消息写入所述消息队列；所述消息消费者，用于通过所述通信连接从所述消息队列获取所述消息，完成消费。

2、在一些实施例中，所述消息处理中心，响应于异常重启，从所述redo log读取未完成处理的目标消息，并将所述目标消息写入所述消息队列，以使消息消费者完成针对所述目标消息的消费。

3、在一些实施例中，所述消息生产者对应于发送端缓存，所述消息消费者对应于接收端缓存；所述消息生产者在产生消息之后，将产生的消息发送至所述发送端缓存；所述发送端缓存为所述消息设置消息序号和所述消息队列的队列id，以将所述消息与所述消息队列关联起来，以及将所述消息发送至所述消息处理中心，并在发送端缓存记录所述消息序号为发送消息序号；所述消息处理中心，将所述消息写入redo log，向所述消息生产者回复发送确认成功，并在消息处理中心记录所述消息序号为发送确认消息序号；以及将所述消息写入与所述队列id对应的消息队列，并通过所述通信连接将所述消息推送至所述接收端缓存，并在消息处理中心记录所述消息序号为消息接收序号；所述接收端缓存，将所述消息推送至所述消息消费者，响应于推送成功，向所述消息处理中心回复接收确认成功，并在接收端缓存记录所述消息序号为消息接收序号；所述消息消费者，接收所述消息并完成消费；所述消息处理中心在接收到所述接收端缓存反馈的接收确认成功，释放本地消息，并在消息处理中心记录接收确认消息序号。

4、在一些实施例中，所述消息处理中心，响应于异常重启，从所述redo log读取未完成处理的目标消息，将所述目标消息写入所述消息队列，通过所述通信连接将所述目标消息推送至所述接收端缓存，并在消息处理中心记录所述目标消息的消息序号为消息接收序号；所述接收端缓存，响应于接收到所述目标消息，在所述目标消息的消息序号大于本地记录的消息接收序号的情形下，将所述目标消息推送至所述消息消费者，响应于推送成功向所述消息处理中心回复接收确认成功，并在接收端缓存记录所述目标消息的消息序号为消息接收序号。

5、在一些实施例中，在所述未完成处理是指没有向所述消息生产者回复发送确认成功的情形下，在将所述目标消息写入消息队列之前，向所述消息生产者回复针对所述目标消息的发送确认成功，并在消息处理中心记录所述目标消息的消息序号为发送确认消息序号。

6、在本技术前面任意实施例示出的数据库中，在该数据库内核中开发了消息处理中心以及该中心与数据库内核已有机制的兼容机制，使得数据库在原有机制基础上增加了消息队列机制，一方面，对于应用程序开发人员来讲只需将应用(消息产生者)对接数据库，降低了开发难度，较为友好；另一方面，可以利用数据库原有的事务机制，将利用消息队列发送消息封装在本地数据库事务中，从而不需开发也不依赖分布式事务中间件，即可监控到消息发送是否成功实现事务原子性，开发难度低，系统也简单，也会避免由于太依赖单点分布式事务中间件带来的容易发生阻塞，发生单点风险导致事务同步失效等缺陷。

7、本技术还包括一种融合事务的实现方法。所述方法基于如前面任意实施例示出的数据库实现，所述融合事务包括针对第一数据库的第一操作，与通知第二数据库执行第二操作的通知操作；所述第一数据库指如前面任一实施例示出的数据库；所述方法包括：接收向所述第一数据库发送的所述融合事务的处理请求；所述第一数据库响应于所述融合事务，将执行第一操作与所述通知操作封装为同一事务，执行该事务以基于自身内核的事务机制，确保执行第一操作，和利用所述第一数据库融合的消息队列机制完成所述通知操作的原子性。

8、在一些实施例中，所述执行该事务以基于自身内核的事务机制，确保执行第一操作，和利用所述第一数据库融合的消息队列机制完成所述通知操作的原子性，包括：预执行所述第一操作，以及利用所述第一数据库融合的消息队列机制预执行所述通知操作；响应于预执行所述第一操作成功以及预执行所述通知操作成功，发布提交指令，完成执行所述第一操作与所述通知操作；响应于预执行所述第一操作失败或者预执行所述通知操作失败，发布回滚指令，撤回所述第一操作与所述通知操作。

9、在一些实施例中，所述利用所述第一数据库融合的消息队列机制预执行所述通知操作，包括：响应于接收到通知第二数据库执行第二操作的通知消息，利用所述消息处理中心，将所述通知消息写入redo log，以及写入与所述通知消息关联的消息队列，以将所述通知消息传输至所述第二数据库对应的消费端应用程序；响应于接收到所述消费端应用程序返回的消息接收确认，确定预执行所述通知操作成功；响应于未接收到消息接收确认，确定预执行所述通知操作失败。

10、在一些实施例中，所述消费端应用程序对应于接收端缓存；所述将所述通知消息传输至所述第二数据库对应的消费端应用程序，包括：将所述通知消息传输至所述消费端应用程序对应的接收端缓存，以由所述消费端应用程序对应的接收端缓存在成功接收到所述通知消息的情形下，向所述消息处理中心返回消息接收确认；在发布提交指令之后，所述方法还包括：响应于接收到关于所述通知消息的提交指令，利用所述消息处理中心，将所述提交指令写入与所述提交指令关联的消息队列，以将所述提交指令传输至所述消费端应用程序对应的接收端缓存，以由所述消费端应用程序对应的接收端缓存将所述通知消息推送至所述消费端应用程序完成第二操作；在发布回滚指令之后，所述方法还包括：响应于接收到关于所述通知消息的回滚指令，利用所述消息处理中心，将所述回滚指令写入与所述回滚指令关联的消息队列，以将所述回滚指令传输至所述消费端应用程序对应的接收端缓存，以由所述消费端应用程序对应的接收端缓存释放所述通知消息。

11、在一些实施例中，所述方法还包括：响应于将所述通知消息推送至所述消费端应用程序，向所述消息处理中心返回提交成功；响应于所述消费端应用程序对应的接收端缓存释放所述通知消息，向所述消息处理中心返回完成回滚；利用所述消息处理中心，将接收到的提交成功或完成回滚，返回至所述通知消息的产生者，以确认完成融合事务。

12、前述任意实施例记载的方案中，可以利用数据库原有的事务机制，将对数据库的操作和通知其它数据库的通知操作封装在同一事务中，从而不需开发也不依赖分布式事务中间件，即可监控到数据库操作和通知操作是否成功实现事务原子性，开发难度低，对应用程序开发人员友好，系统也简单，也会避免由于太依赖单点分布式事务中间件带来的容易发生阻塞，发生单点风险导致事务同步失效等缺陷。

13、应当理解的是，以上所述的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本技术。