春天如何扩展一个以上实例并处理预定任务？

如何解决春天如何扩展一个以上实例并处理预定任务？

我每天早上8点在欧洲/巴黎都会通过春季启动将推送通知发送到android和ios应用程序。

如果我运行多个实例，则通知将发送多次。我正在考虑每天发送通知发送到数据库，并检查它们，但我担心它仍会运行多次，这就是我正在做的事情：

@Component
public class ScheduledTasks {

    private static final Logger log = LoggerFactory.getLogger(ScheduledTasks.class);

    private static final SimpleDateFormat dateFormat = new SimpleDateFormat("HH:mm:ss");

    @Autowired
    private ExpoPushTokenRepository expoPushTokenRepository;

    @Autowired
    private ExpoPushNotificationService expoPushNotificationService;

    @Autowired
    private MessageSource messageSource;

    // TODO: if instances > 1,this will run multiple times,save to database the notifications send and prevent multiple sending.
    @Scheduled(cron = "${cron.promotions.notification}",zone = "Europe/Paris")
    public void sendNewPromotionsNotification() {
        List<ExpoPushToken> expoPushTokenList = expoPushTokenRepository.findAll();
        ArrayList<NotifyRequest> notifyRequestList = new ArrayList<>();
        for (ExpoPushToken expoPushToken : expoPushTokenList) {
            NotifyRequest notifyRequest = new NotifyRequest(
                    expoPushToken.getToken(),"This is a test title","This is a test subtitle","This is a test body"
            );
            notifyRequestList.add(notifyRequest);
        }

        expoPushNotificationService.sendPushNotificationToList(notifyRequestList);
        log.info("{} Send push notification to " + expoPushTokenList.size() + " userse",dateFormat.format(new Date()));
    }
}

有人对我如何安全地防止这种情况有想法吗？

解决方法

Quartz是我眼前与任务无关的大多数数据库解决方案，但已被排除在外，因此我们不再讨论。

我们将探索的解决方案基于以下假设：

• 使用了Postgres >= 9.5（因为我们将使用SKIP LOCKED,which was introduced in Postgresl 9.5）。
• 可以运行本机查询。

在这种情况下，我们可以通过以下查询从运行该应用程序的多个实例中检索一批通知：

SELECT * FROM expo_push_token FOR UPDATE SKIP LOCKED LIMIT 100;

这将从表100中检索并锁定多达expose_push_token个条目。如果应用程序的两个实例同时执行此查询，则接收到的结果将不相交。 100只是一些样本值。您可能需要针对用例微调此值。锁将保持活动状态，直到当前交易结束。

实例获取了一批通知后，它还必须从表中删除它锁定的条目，否则标记该条目已被处理（如果我们沿这条路线前进，则必须将上面的查询修改为过滤掉已处理的整体）并关闭当前交易以释放锁定。然后，该应用程序的每个实例将重复此查询，直到该查询返回零个条目。

有另一种方法：实例首先获取要发送的通知的批处理大小，将事务保持打开状态（从而继续保持对数据库的锁定），发出其通知，然后删除/更新条目并关闭交易。

这两种解决方案具有不同的优势/劣势：

• 第一个解决方案使交易短。但是，如果应用程序在发出通知的过程中崩溃，则此批处理中未发送的部分将丢失。
• 第二种解决方案可以使事务保持打开状态很长时间。如果它在发出通知的过程中崩溃，则所有条目将被解锁，并且其批处理将被重新处理，可能导致某些通知被发送两次。

---

为使该解决方案有效，我们还需要某种工作，用所需的数据填充表expo_push_token。该作业应该不会与通知发送过程重叠。