개인적으로 모든 소프트웨어 타이밍은 폴링을 통해 이루어지며 이러한 작업을 수행하기 위해 스레드를 여는 데 더 많은 리소스가 소비된다고 생각합니다. 다음 솔루션의 성능이 더 나을 수도 있다고 생각합니다.
0. 먼저 5분마다 방송을 보내는 '예약방송'이 필요합니다. 1. 사용자가 등록하면 '예약방송'을 들을 청취자를 등록합니다. 2. user 메일함 내 활성화 주소를 클릭하면 기존에 등록된 리스너가 종료됩니다 3. 리스너가 두 번째로 방송을 수신하면 작업이 실행되고 청취가 취소됩니다
두 번째 방송을 수신할 때 작업을 실행해야 하는 이유는 5~10분 후에 작업이 실행될 수 있도록 하기 위함입니다. 물론 이것이 정확한 타이밍을 보장할 수는 없습니다. 타이밍 정확도를 향상시켜야 하는 경우에는 1분에 한 번, 심지어는 1초에 한 번 브로드캐스트할 수도 있지만 이 시나리오는 필요하지 않습니다.
예약 방송을 구현하려면 Quartz와 같은 도구를 사용하거나 메시지 대기열을 사용하여 이 비즈니스를 분리할 수도 있습니다.
개인적으로 모든 소프트웨어 타이밍은 폴링을 통해 이루어지며 이러한 작업을 수행하기 위해 스레드를 여는 데 더 많은 리소스가 소비된다고 생각합니다. 다음 솔루션의 성능이 더 나을 수도 있다고 생각합니다.
0. 먼저 5분마다 방송을 보내는 '예약방송'이 필요합니다.
1. 사용자가 등록하면 '예약방송'을 들을 청취자를 등록합니다.
2. user 메일함 내 활성화 주소를 클릭하면 기존에 등록된 리스너가 종료됩니다
3. 리스너가 두 번째로 방송을 수신하면 작업이 실행되고 청취가 취소됩니다
두 번째 방송을 수신할 때 작업을 실행해야 하는 이유는 5~10분 후에 작업이 실행될 수 있도록 하기 위함입니다. 물론 이것이 정확한 타이밍을 보장할 수는 없습니다. 타이밍 정확도를 향상시켜야 하는 경우에는 1분에 한 번, 심지어는 1초에 한 번 브로드캐스트할 수도 있지만 이 시나리오는 필요하지 않습니다.
예약 방송을 구현하려면 Quartz와 같은 도구를 사용하거나 메시지 대기열을 사용하여 이 비즈니스를 분리할 수도 있습니다.
도움이 되었길 바라며, 부적절하거나 잘못된 부분이 있으면 댓글 부탁드립니다
데이터베이스를 사용하여 폴링하고, 클릭하면 해당 기록을 삭제합니다
스프링의 타이머를 사용하여 서비스 레이어에서 등록 시 0인 필드가 있습니다. 등록 후 5분 후에 데이터베이스의 이 필드가 몇 초마다 스캔됩니다. 인증코드 사용자가 메일함의 주소를 클릭하여 타이머를 중지시켰는데, 스프링 타이머의 문서와 코드를 알려드릴 수 있습니다
jdk의 기본 타이머 및 트리거 부분을 붙여넣는 것이 핵심입니다. 타이머가 일정을 호출할 때 리스너를 등록하거나 다른 방법으로 호출하면 JDK 개발을 참조하세요. 문서에 자세한 지침이 있습니다. 이 작은 데모는 작업을 취소하지 않았습니다.
으아아아이러한 종류의 일회성 타이머는 메시지 대기열을 사용하여 구현하는 데 더 적합합니다. 구현이 비교적 간단하고 Java에서 가장 필수적인 것은 휠입니다. RabbitMQ, ActiveMQ, RocketMQ
와 같은 메시지 대기열디자인에 문제가 있습니다.
설계에 따르면 각 사용자의 등록은 예약된 작업을 시작해야 하는데 많은 사용자가 등록하면 어떻게 되나요? 예약된 작업은 실제로 스레드입니다. 많은 수의 스레드를 시작하면 너무 많은 CPU 리소스가 소모됩니다.
사용자는 이메일 주소를 클릭하여 주소를 활성화한 후 파기합니다. 예약된 작업을 JVM에 저장하면 등록 및 활성화 중에 사용자가 동일한 JVM 인스턴스에 액세스하는지 보장할 수 없으므로 클러스터 배포 중에 실패할 가능성이 있습니다.
예약된 작업은 사용자가 활성화되지 않은 것을 확인한 후 인증 코드를 다시 생성합니다. 사용자가 다음에 이메일을 보내기 위해 클릭하기 전에 생성되어야 하는 이유는 무엇입니까?
더 나은 디자인은 다음과 같아야 한다고 생각합니다.
사용자 등록, 사용자 활성화 상태 = 아니요
사용자가 [활성화 이메일 보내기]를 클릭하면 활성화 URL이 백그라운드에서 생성됩니다. URL은 uuid와 함께 저장됩니다(uuid, 사용자 이름, 만료). 시간), 이메일이 전송됩니다
사용자가 이메일에 있는 활성화 URL을 클릭하고 애플리케이션에 액세스합니다.
애플리케이션은 URL에서 uuid를 가져와 uuid가 데이터베이스에 존재하고 만료되지 않았는지 확인합니다. 그렇다면 연결된 사용자 이름을 가져오고 사용자 활성화 상태를 true로 업데이트하고, 그렇지 않은 경우 uuid를 삭제합니다.
UUID 저장소:
은 데이터베이스에 저장할 수 있지만 만료된 데이터를 정리하려면 별도의(단 하나의) 스레드를 열고 1분마다 실행하여 데이터베이스에서 만료된 uuid를 삭제하면 됩니다.
은 Redis에도 저장할 수 있습니다. Redis에는 데이터의 TTL을 지정할 수 있는 기능이 있으므로 만료되면 자동으로 삭제되므로 정리하기 위해 별도의 스레드를 열 필요가 없습니다. 만료된 uuid.