하루에 한 번 사용자 조치 : 24 시간 재설정 대 자정 재설정 [닫기]

사용자가 하루에 한 번만 경기를 할 수있는 경우 (예 : 경쟁에 대한 무료 티켓 받기) 내 경험에 두 가지 가능성이 있습니다.

1) 24 시간 리셋

오후 11시 45 분에 1 일에 작업을 수행하는 경우 11시 45 분 이후에 2 일에 다시 작업을 수행 할 수 있습니다. 그는 2 일째되는 날 11:44에 할 수 없습니다.

2) 자정 재설정 (또는 고정 시간)

사용자가 1 일에 작업을 수행 한 시간에 관계없이 자정이 바뀌고 2 일이 시작되는 즉시 다시 작업을 수행 할 수 있습니다.

둘 다 사용자가 하루에 하나의 작업 만 수행하도록 제한하지만 가장 자주 두 가지 이유로 불편한 방법 1을 발견합니다.

• 먼저 시간을 기다려야합니다
• 오랜 시간에 걸쳐 두 번째로, 작업을 수행하는 타임 스탬프는 나중에 몇 초 또는 몇 분 후에 매일 해당 타임 스탬프에서 정확하게 작업을 수행 할 수 없기 때문에 시간이 지날 것입니다.

어떤 거기에 기술적 인 이유는 사용자에 대한 내 의견 중요한 단점에서 미리 언급이기는 하나, 방법 1을 선호하는 것?

편집, 지정 : 나는 특히 예를 들어 이야기하고 있습니다. 예를 들어 현재의 무료 스핀 이벤트 Theory11 과 같이 24 시간마다 1 개의 무료 스핀을 얻습니다. 수상 경력에 있습니다.

나는 자정 재설정을 기대할 때 일반적으로 놀랐습니다.

그러나 24 시간마다 자정이 둘 이상이라는 점에서 큰 단점이 있습니다. 시간대를 선택해야합니다.

어쩌면 이것이 24 시간에 한 번 범용이 선택되는 이유 일 수 있습니다. 회사에서 다른 국가의 절반 사용자가 자정이 아닌 현지 시간을 가질 수도 있고 "하루에"라는 말이 자정을 암시한다고 생각하기보다는 따라서 마케팅은 "24 시간마다"로 변경되고 소프트웨어 사양은

요즘 "오후 2시 (GMT)에 종료"또는 이와 유사한 것을 보는 것이 상당히 일반적이라고 생각합니다.

모든 사용자의 마지막 작업 날짜를 저장하는 것이 사용자 또는 작업 유형에 시간대를 지정하는 것보다 어렵다는 생각이 들었습니다.

편집 두 방법의 차이점에 주목할 가치가 있다고 생각합니다.

24 시간 규칙

• 24 시간당 1 개 미만의 속도로 일정이 일정하게 유지됩니다.
• 내가 그 일을 끝내면 일부 사용자는 적은 이벤트를 받게됩니다.
• 모든 사용자에게 마지막 이벤트를 저장해야합니다
• 일광 절약 시간이 길거나 짧은 날인 경우 하루에 1 개의 이벤트가 없습니다.
• 인간은 점에 정확히 24 시간을 맞출 수 없으므로 평균적으로 하루에 평균 1 미만을 얻을 것입니다

달력 당 1 규칙

• 달력 날짜에 할당 된 50 시간 (? UTC + 14 ~ -12?) 동안 버킷 이벤트가 발생합니다.
• 현실적으로 나는 모든 사용자에게 마지막 이벤트를 무릎 위의 '일'로 저장해야합니다
• 난 후에 나는 모든 이벤트를 말할 수있는 하루의 명확한 끝이 어떻게 지금 하루에없는합니다.
• 이벤트가 적용되는 요일을 알기 위해 사용자의 위치를 ​​알아야합니다.
• 어떤 사람들은 다른 사람들보다 '일'에 훨씬 일찍 깨어 있습니다

UTC 규칙에서 달력 일당 1

• 나는 24 시간 긴 유니폼을 입는다
• 이벤트를 버켓 수 있습니다
• 나는 하루의 시작과 끝이 언제인지 알고있다
• 일광 절약은 사람들을 혼란스럽게 할 것입니다.
• 인간은 하루에 1 개의 이벤트를 가질 수 있습니다
• 그리니치 근처에 살지 않는 사람들은 재미있는 시작과 끝 시간을 가질 것입니다
• 어쩌면 영리한 최적화를 수행하고 입력 한 사용자 목록을 저장할 수 있습니까? (아마도 모든 사용자 이벤트와 시간을 저장하게 될 것입니다)

* 이벤트 버킷 팅은 다양한보고 목적에 매우 유용합니다. 예. 24 시간마다 10 개의 상을 받았으며 시간이 지남에 따라 다릅니다. 10 일째에 몇 명의 학생이 입학 했습니까? 기타

내 머리 꼭대기에서 :

• "마지막 조치 이후 24 시간"버전을 구현하는 것이 더 쉬울 수 있습니다.
• 사용자가 마지막 시간 이후 정확히 24 시간 후에 작업을 수행하지 않으면 결국 24 시간 동안 전체 작업을 놓칠 수 있습니다. 이는 잠자기 또는 작업 중일 때 재설정해야하기 때문입니다. 아마도 그들은 출근하기 전에 오전 7시에하고 오후 8시에 출근합니다. 다음날 그들은 7시 15 분, 7시 30 분, 7시 45 분에 그것을하고 마지막 날에는 8 시까 지 머무르기 직전에 조치를 취하십시오. 다음날 오후 8시 15 분까지 기꺼이 머 무르지 않기 때문에 그날 아침을 그리워하고 오후 6시 직장에서 집으로 돌아온 후 34 시간의 간격을 두십시오. 회사의 조치 결과가 비싸면 비용 절감이 불편 함보다 더 중요 할 수 있습니다.

다른 답변에서 언급했듯이 24hr 방법은 여러 시간대에 더 친숙하며 각 사용자에 대해 마지막으로 성공한 타임 스탬프를 저장하는 것처럼 코딩하기 쉽습니다.

또한 실제로 매일 사용자가 앱과 상호 작용하여 모든 일상적인 작업을 수행해야하는 "혜택"이 추가되었습니다. 자정 재설정이있는 경우 사용자는 오후 11시 59 분에 작업을 수행 한 다음 오전 12시에 다시 작업을 수행 할 수 있습니다. 그들은 매일이 작업을 수행하고 여전히 모든 작업을 수행 할 수 있습니다. 일부 앱의 경우 일상적인 작업의 목적은 사용자가 매일 앱과 상호 작용하도록하는 것이 이상적이지 않습니다.

UI 함정을 피하는 세 번째 대안이 있지만 코딩하기가 조금 더 어렵습니다.

3) (n-0.75) * 24 시간 동안 n 개 이상의 동작에 줄무늬가 없음

저장하는 데 두 가지 변수가 필요하지만 시스템을 남용하지 않는 사람은 시간대와 재설정에 대해 걱정할 필요없이 하루 중 언제든지 한 가지 작업을 사용할 수 있습니다.

또한 모든 사람이 둘 이상의 "추가"작업을 사용하지 못하게합니다.

실제로 행진의 시작 시간, 마지막 재생 시간 및 행진의 동작 수를 저장해야하는 알고리즘을 구현하십시오.

마지막 작업 시간을 추적하면 너무 가까운 두 작업을 거부 할 수 있습니다. 이 줄무늬는 24 시간 이내에이 제한을 만들 수 있습니다.

매일 행동을 취하는 한 행진은 계속됩니다. 조치를 취하면 행진에서 며칠보다 더 많은 조치를 취해야한다면 거부됩니다. 이렇게하면 줄무늬의 시작 시간이 변경되지 않기 때문에 "추가"작업을 수행하면서 천천히 앞으로 기어 오르는 것을 방지합니다.

검사를 구현하고 시간을 추적하는 의사 코드 :

//precondition: streakStart and  lastAction are initialized as in the far past
//              streakCount is initialized as 0
graceHours=18;
checkAllowed(currentTime,&streakStart,&streakCount, &lastAction){
    diffhours=hoursDifferent(lastAction,currentTime);
    if(diffhours< 24 - graceHours){
        return false;
    }
    diffhours=hoursDifferent(streakStart,currentTime);
    if(diffhours <= 24*streakCount - graceHours){
        return false;
    }
    if(diffhours > 24*(streakCount+2)-graceHours){
        streakStart=currentTime;
        streakCount=0;
    }
    streakCount++;
    lastActionTime=currentTime;
    return true;
}

추가 보너스로 원하는 경우 줄무늬 카운터를 얻을 수 있습니다.

조치 사이의 24 시간 지속에 대한 문제점에 대해 일부 회사는 대신 22 시간 지속을 사용합니다. 이렇게하면 사용자는 조치가 필요한 정확한 순간에 약간의 여유가 생겨 사용자가 실제로 조치를 수행하도록 권장합니다. 하루에 한 번-아니 23:59-00:00 허점.

답이 아니지만 의견을 말할 충분한 점이 없습니다.

tl/dr: 24 hour resets are the lazy man's way of minimizing load spikes

위의 답변 외에도 자정 재설정은 트래픽 급증을 권장합니다. 특정 시간에 모든 참여자가 조치를 사용할 수있게되면 많은 사람들이 동시에 조치를 시도하도록 유도 할 수 있습니다. 이는 대부분의 주에서 운전 면허증이 생일 (미국)이 아닌 생일에 만료되는 것과 같은 이유입니다. 모든 사람이 1 월 1 일에 운전 면허증이 만료 된 경우 DMV를 유지할 수 없습니다.

소규모 : 컴퓨터 시스템이 많은 사용자를 위해 하루에 한 번 조치를 취해야하는 경우 동일한 질문을 할 수 있으며 일반적으로 두 시스템을 조합하여 설계합니다. 두 가지 cron 작업을 상상할 수 있습니다.

1. 자정에 실행, 모든 레코드 찾기, 조치 수행
2. 1 분마다 (또는 일정한 빈도로) 실행하고 어제 00:00 이후 조치를 취하지 않은 모든 레코드를 찾고 조치를 취한 조치를 기록하십시오.

실제로 나는 전자가 부서지기 쉽다는 것을 발견했다. cron 태스크가 실행 중에 중단되면 일부 숫자에 조치가 적용되지 않을 수 있으며 시스템이 있던 위치를 기억하고 중단 된 위치를 선택하기 위해 추가 작업이 필요할 수 있습니다. cron 태스크가 합리적인 시간 제한으로 모든 레코드를 처리 할 수없는 레코드가 충분하면 문제가 발생할 수 있으며 완료 전에 종료됩니다.

후자는 두 가지 우려를 모두 처리합니다. 그것은 정확히 24시간 분리 처리 모든 것을 얻을 것을 목표로하지 않습니다,하지만 크론 작업이 쉽게 매일 모든 행동을 통해 실행할 수있는 한, 그들은 아주 가까이 될 것입니다 그리고 당신은 그 모두가 각각의 실제 날짜에 실행됩니다 보장 할 수 있습니다 (즉, 24 시간 이상 느리게 표류하는 것은 없습니다.) 가장 중요한 것은 어떤 이유로 든 고장이 발생하면 중단 된 부분을 쉽게 가져올 수 있다는 것입니다.

https://www.youtube.com/watch?v=hoMO1yYC7pQ

TfL (런던 운송)의 일일 버스 / 기차 티켓은 오전 4시 30 분부터 오전 4시 30 분까지 유효합니다. 사람들이 잠들 때 스위치를 사용하십시오. 많은 사람들이 자정을 지나서 8시 30 분부터 1 시간까지의 서비스를 사용하기를 원할 것입니다

자정 재설정에는 해결하려는 문제에 따라 바람직하거나 유해 할 수있는 특정 조건이 있습니다. 즉, 하루 11 : 11 : 59 : 58에 다시 00:00:01에 작업을 수행 할 수 있습니다. 문제 공간이 어떤 종류의 경쟁이라면 자정에 가까운 행동을하도록 선택한 사람들에게 불공정 한 이점을 줄 수 있습니다. 24 시간 재설정 규칙은 다른 사람이 이용할 수있는 시간에 관계없이 사용 가능한 조치를 공정하게 분배 할 수있는 유일한 방법입니다.

24 시간 재설정의 결과가 나중에 점점 더 커지는 결과는 허용 오차를 제공함으로써 완화 될 수 있습니다. 재설정). 이것은 솔루션에 조금 더 복잡해 보이지만 자정 재설정 사례에서와 같이 매일 두 번의 작업을 몇 초 간격으로 수행 할 수있는 완화 전략을 생각할 수 없습니다.

나는 24 시간 규칙이 정기적 인 정기적 방문을 장려한다는 사실을 언급 한 적이 없다. 많은 게임에는 하루에 한 번의 로그인 / 승리 보상이 있으며 24 시간 후에 재설정됩니다. 48 시간마다 두 배가 아닌 24 시간마다 짧은 시간 동안 체크인하기 때문입니다. 티켓 공짜를 호스팅하는 웹 사이트와 비슷하다고 생각합니다.