Design and Implementation of a Generic Asynchronous Processing SDK for Java Backend

The author introduces a generic asynchronous processing SDK for Java backend systems, aiming to keep core code stable under frequent business iterations by offloading extensible features to an asynchronous thread pool without compromising performance or data consistency.

Purpose : Ensure method execution without blocking the main flow and guarantee data persistence through fallback mechanisms to achieve eventual consistency.

Advantages : Non‑intrusive design, independent database, scheduled tasks, message queue, and unified login‑protected UI; uses Spring transaction event mechanism so that asynchronous failures never affect the primary business transaction; supports execution after transaction commit/rollback and provides fallback handling unless the underlying resources fail.

Principle : After container bean initialization, all methods annotated with @AsyncExec are cached; at runtime an AOP aspect publishes an event, and a transactional event listener processes the asynchronous execution strategy.

Key annotation example:

@TransactionalEventListener(fallbackExecution = true, phase = TransactionPhase.AFTER_COMPLETION)

– the listener runs even when no transaction is active and processes events after both commit and rollback.

Components :

Kafka message queue

XXL‑Job scheduler

MySQL database

Spring AOP

Vue front‑end

Design Patterns : Strategy, Template Method, Dynamic Proxy, Flowchart.

Database Schema (simplified):

CREATE TABLE `async_scene` ( ... );
CREATE TABLE `async_req` ( ... );
CREATE TABLE `async_log` ( ... );

Asynchronous Strategies , Security Levels , Execution Statuses and related flowcharts are illustrated with images in the original document.

Apollo Configuration (example):

# Switch (default off)
async.enabled=true

# Application name
spring.application.name=xxx

# DataSource (Druid)
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/fc_async?... 

# Thread pool defaults
async.executor.thread.corePoolSize=10
async.executor.thread.maxPoolSize=50
async.executor.thread.queueCapacity=10000
async.executor.thread.keepAliveSeconds=600

# Record deletion after success
async.exec.deleted=true

# Queue name prefix (default application name)
async.topic=${spring.application.name}

# Retry settings
async.exec.count=5
async.retry.limit=100
async.comp.limit=100
async.login=false

Usage :

Enable the async switch: scm.async.enabled=true Annotate methods that need asynchronous execution (must be Spring‑proxied):

@AsyncExec(type = AsyncExecEnum.SAVE_ASYNC, remark = "Data Dictionary")

Access the manual handling UI at http://localhost:8004/async/index.html Notes :

Application name must be set correctly.

Queue name follows the pattern ${async.topic:${spring.application.name}}_async_queue.

Business logic should be idempotent.

One queue is shared per application.

Two scheduled jobs: retry every 2 minutes (configurable attempts) and compensation every hour for records older than one hour.

Demo Screenshots and Code Repository are provided (GitHub: https://github.com/xiongyanokok/fc-async).

Finally, the author invites readers to join a backend‑focused technical community for knowledge sharing and recruitment.