Troubleshooting and solutions for time-of-view repetition and liking

Source: Internet
Author: User
Tags repetition

1. Hoang Hai Long 2 times

2016/7/5 9:12:31
2016/7/5 9:13:17

Time interval 45784ms approx. 45s

2. Mingxia praised 6 times,
2016/7/5 6:33:12
2016/7/5 7:16:9
2016/7/5 7:30:18
2016/7/5 9:3:48
2016/7/5 9:4:3
2016/7/5 13:55:12

1th and 2nd time intervals: 2577425ms approx. 2577s approx. 43min,
2nd and 3rd time intervals: 848283ms approx. 848s approx. 14min
3rd and 4th time intervals: 5609891ms approx. 5609ms approx. 93min
4th and 5th time intervals: 15780ms approx. 15s
5th and 6th time intervals: 17468253ms approx. 291min

3. (1) through the likes of the time interval, can be ruled out because of concurrency problems, and caused the likes to repeat this possibility


After you exclude concurrency issues:
4. (1) Why do you like it again?
A. When verifying from Redis, Redis returns false, so after you finish, you can continue to like (main reason)
B. picture_praise table sns_id picture_id Three fields should be set to a unique key ( This is not the main reason)

(2) Why do you like it, and again from the Redis checksum, Redis will return False (that is, the user did not click the praise)
did not deposit to Redis
data deposited to Redis, lost, or failed. But like this morning, this situation basically excludes

(3) Why hasn't it been deposited to Redis?
A. Redis is full, not deposited, this possibility is, but very small

B. There is a judgment before joining Redis
SimpleDateFormat yyyymmdd_format = new SimpleDateFormat ("YyyyMMdd");
Final String yearandmonthandday = Yyyymmdd_format.format (picturecreatetime);
if (Long.parselong (yearandmonthandday) >= newstartday) {
is not credited to Redis
}

checked a piece of Create_ Time is 1395458758000, this number and the above comparison, the return is false.
Preliminary judgment, here's the problem.

(4) Create_time and Newstartday compare why return False
Create_time is 2014/3/22 after 1395458758000L conversion 11:25:58 is less than the minimum time of Redis 20140723, so return false, after the point of praise, can not be credited to Redis

(5) Why the time is greater than 20140723, in order to deposit Redis????

Because before 0723, whether the praise is present in the MONGO inside, so will add 0723 to determine the

However, when judging whether to praise the time, even if the picture creation date before 2014-07-23, also did not check from MONGO inside whether liked

5. Solution
When you save a Redis,
(1) If the picture creation date is after 2016-06-09, the logic does not change
(2) The creation date was not moved until 2014-07-23
(3) The rest of the situation, according to the creation date after 2016-06-09 logic walk, that is divided into 5 paragraphs
Judging if you've liked it, you need to add

Troubleshooting and solutions for time-of-view repetition and liking

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.