Как реализуешь периодический повторяющийся запрос к БД?

Как реализуешь периодический повторяющийся запрос к БД?

В Java есть несколько проверенных способов реализации периодических задач. Выбор зависит от требований: сложность, надёжность, масштабируемость.

Вариант 1: Spring @Scheduled (самый простой)

Для простых задач в одном приложении использую встроенный механизм Spring:

@Component
public class DatabaseSyncTask {
    
    @Autowired
    private UserRepository userRepository;
    
    @Scheduled(fixedDelay = 60000) // Повторять каждые 60 секунд
    public void syncUserStatistics() {
        List<User> activeUsers = userRepository.findByStatusActive();
        activeUsers.forEach(user -> {
            updateUserMetrics(user);
        });
        log.info("User sync completed. Processed: {}", activeUsers.size());
    }
    
    @Scheduled(cron = "0 0 2 * * *") // Каждый день в 2 AM
    public void dailyCleanup() {
        userRepository.deleteExpiredSessions();
    }
}

Включи в конфиге:

@Configuration
@EnableScheduling
public class SchedulingConfig {
}

Плюсы: простота, не нужна отдельная инфраструктура Минусы: работает только в одном инстансе приложения, нет гарантии на отказоустойчивость

Вариант 2: Quartz Scheduler (надёжный, распределённый)

Для критичных фоновых задач в production использую Quartz — он может работать в кластере:

@Component
public class DatabaseUpdateJob implements Job {
    
    @Autowired
    private DataService dataService;
    
    @Override
    public void execute(JobExecutionContext context) throws JobExecutionException {
        try {
            List<Order> pendingOrders = dataService.findPendingOrders();
            for (Order order : pendingOrders) {
                order.setStatus("processing");
                dataService.updateOrder(order);
            }
            log.info("Job executed successfully. Orders: {}", pendingOrders.size());
        } catch (Exception e) {
            log.error("Job execution failed", e);
            throw new JobExecutionException(e);
        }
    }
}

Конфиг Quartz:

@Configuration
public class QuartzConfig {
    
    @Bean
    public JobDetail orderProcessingJobDetail() {
        return JobBuilder.newJob(DatabaseUpdateJob.class)
                .withIdentity("orderProcessingJob")
                .storeDurably()
                .build();
    }
    
    @Bean
    public Trigger orderProcessingTrigger(JobDetail jobDetail) {
        return TriggerBuilder.newTrigger()
                .forJob(jobDetail)
                .withIdentity("orderProcessingTrigger")
                .withSchedule(CronScheduleBuilder.cronSchedule("0 0/5 * * * ?"))
                .build();
    }
    
    @Bean
    public SchedulerFactoryBean schedulerFactoryBean(JobDetail jobDetail, Trigger trigger) {
        SchedulerFactoryBean factory = new SchedulerFactoryBean();
        factory.setQuartzProperties(quartzProperties());
        factory.setJobDetails(jobDetail);
        factory.setTriggers(trigger);
        return factory;
    }
    
    private Properties quartzProperties() {
        Properties props = new Properties();
        props.put("org.quartz.jobStore.class", "org.quartz.impl.jdbcjobstore.JobStoreTX");
        props.put("org.quartz.jobStore.driverDelegateClass", "org.quartz.impl.jdbcjobstore.PostgreSQLDelegate");
        props.put("org.quartz.jobStore.dataSource", "quartzDataSource");
        return props;
    }
}

Плюсы: работает в кластере, гарантия выполнения, хранит историю в БД Минусы: сложнее конфигурировать, нужна отдельная БД для Quartz

Вариант 3: Redis Pub/Sub + Redisson (распределённые системы)

Для микросервисной архитектуры с несколькими инстансами использую Redisson для координации:

@Component
public class DistributedScheduler {
    
    @Autowired
    private RedissonClient redissonClient;
    
    @Autowired
    private UserRepository userRepository;
    
    @PostConstruct
    public void startScheduler() {
        // Получаем distributed lock
        RLock lock = redissonClient.getLock("user-sync-lock");
        
        ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);
        executor.scheduleAtFixedRate(() -> {
            try {
                if (lock.tryLock(10, TimeUnit.SECONDS)) {
                    try {
                        List<User> users = userRepository.findAll();
                        syncUsers(users);
                        log.info("Sync completed in instance: {}", getInstanceId());
                    } finally {
                        lock.unlock();
                    }
                }
            } catch (InterruptedException e) {
                log.error("Lock acquisition failed", e);
            }
        }, 0, 5, TimeUnit.MINUTES);
    }
    
    private void syncUsers(List<User> users) {
        users.forEach(user -> {
            user.setLastSyncTime(LocalDateTime.now(ZoneOffset.UTC));
            userRepository.save(user);
        });
    }
}

Плюсы: автоматическое распределение между инстансами, высокая доступность Минусы: зависимость от Redis, сложнее в отладке

Вариант 4: Spring Data + Pagination (для больших объёмов)

Когда БД содержит миллионы записей, нужна пакетная обработка с пагинацией:

@Component
public class LargeDatasetProcessor {
    
    @Autowired
    private TransactionService transactionRepository;
    
    private static final int PAGE_SIZE = 1000;
    
    @Scheduled(fixedDelay = 300000) // Каждые 5 минут
    public void processTransactions() {
        int pageNumber = 0;
        boolean hasMore = true;
        
        while (hasMore) {
            Page<Transaction> page = transactionRepository.findUnprocessed(
                    PageRequest.of(pageNumber, PAGE_SIZE)
            );
            
            processPage(page.getContent());
            
            pageNumber++;
            hasMore = page.hasNext();
            
            // Даём БД отдохнуть между страницами
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                break;
            }
        }
        
        log.info("Batch processing completed. Total pages: {}", pageNumber);
    }
    
    private void processPage(List<Transaction> transactions) {
        transactions.forEach(tx -> {
            tx.setStatus("completed");
            tx.setProcessedAt(LocalDateTime.now(ZoneOffset.UTC));
        });
        transactionRepository.saveAll(transactions);
    }
}

Плюсы: не перегружает память, не блокирует БД Минусы: требует тщательной настройки PAGE_SIZE

Вариант 5: Отдельный Worker Service

Для очень сложных сценариев запускаю отдельное приложение-воркер:

@SpringBootApplication
public class DatabaseWorkerApp {
    
    @Autowired
    private WorkerService workerService;
    
    @Bean
    public CommandLineRunner run() {
        return args -> {
            ScheduledExecutorService executor = Executors.newScheduledThreadPool(5);
            
            // 5 потоков для параллельной обработки
            executor.scheduleAtFixedRate(
                    workerService::processPendingOrders,
                    0, 30, TimeUnit.SECONDS
            );
            
            executor.scheduleAtFixedRate(
                    workerService::cleanupExpiredData,
                    0, 1, TimeUnit.HOURS
            );
        };
    }
}

Мониторинг и логирование

Всегда добавляю логирование и метрики:

@Component
public class MonitoredScheduledTask {
    
    @Autowired
    private MeterRegistry meterRegistry;
    
    @Scheduled(fixedDelay = 60000)
    public void executeTask() {
        Timer timer = Timer.start(meterRegistry);
        
        try {
            log.info("Task started");
            performDatabaseOperation();
            meterRegistry.counter("task.success").increment();
        } catch (Exception e) {
            log.error("Task failed", e);
            meterRegistry.counter("task.failures").increment();
        } finally {
            timer.stop(Timer.builder("task.duration").register(meterRegistry));
        }
    }
}

Сравнительная таблица

Я выбираю подход в зависимости от требований: для MVP стартую с @Scheduled, затем при необходимости масштабирования перехожу на Quartz или Redis.