Использование системного времени как UUID

Question

В моем приложении, когда пользователь взаимодействует с кем-то, новое уведомление добавляется в список уведомлений другого парня. Теперь мне приходилось многократно уведомлять идентификатор.

Уловка заключается в том, что идентификатор должен быть уникальным только в пределах диапазона уведомлений только для данного пользователя. Кроме того, я не храню более 150 уведомлений.

Теперь, поскольку я все равно сохраняю время (System.currentTimeMillis()) каждого уведомления, безопасно ли его повторно использовать как идентификатор?

Кажется маловероятным, что два уведомления для одного и того же пользователя могут быть сгенерированы в одно и то же время. Например. несколько человек, таких как его сообщение в то же время и т. д. Даже если это так, я не думаю, что мой сервер будет обслуживать каждый звонок в одно и то же время.

EDIT

Безопасный пример для рассмотрения может быть несколько людей любящих свой пост на Facebook одновременно и сервер добавления уникального уведомления для каждого события. (сохраняя UX в сторону)

Answer 1

время является одним из самых трудных для обработки вещей в компьютерах. Синхронизация между устройствами затруднена, и даже для одного времени устройства не может быть строго монотонным, например. из-за настроек для коррекции тактового дрейфа. Это может работать сейчас, но использование времени в качестве идентификатора приведет к неприятностям при использовании в масштабе, потому что вам придется обрабатывать часовые пояса и т. Д.

Я бы предпочел использовать хэш-функцию для создания идентификатора в вашем дело. Выбрав хеш-функцию, вы можете настроить, насколько вероятны столкновения, и если хотите, вы можете включить время в хэшированные данные. С помощью хэширования всех релевантных данных вы можете убедиться, что только истинные дубликаты и коллизии приводят к тому же значению. Преимущество хэширования состоит в том, что он создает детерминированный результат везде без синхронизации.

Второй вариант - выбрать один случайным образом, но в этом случае вам нужен хороший источник энтропии, и он часто более дорог и менее предсказуем, чем хеширование.

Конечно, если идентификатор может быть выбран одним объектом, счетчик также является опцией. Для нескольких сторон это потребует синхронизации и, следовательно, менее подходит для большой синхронной группы.

Answer 2

Лучшим подходом для uuid будет использование класса UUID и создание уникального кода uuid.

Но если вы не в порядке с ним, попробуйте использовать System.nanoTime() как это оказывает наносекунд точность, а не миллисекунды в System.currentTimeMillis

Answer 3

Существует несколько причин, по которым вам следует использовать uuid. Прежде всего потому, что теория параллелизма заключается в том, что они всегда маловероятны, чтобы когда-либо происходить. Однако практика показывает, что они происходят довольно часто.

Также представьте, что кто-то пытается найти ошибку в вашем программном обеспечении. Этот человек в первую очередь будет действительно смущен тем, что вы просто используете системное время и считаете, что ошибка, которую он ищет, будет связана с параллелизмом. Вероятно, он потратит часы на отладку.

И, наконец, нет смысла сохранять эти несколько бит.Даже если вы сохранили 1 миллион длинных значений, вы использовали бы менее 7 мб пространства, что в настоящее время даже не на телефоне - несмотря на сервер.

Добавив, что значение, следовательно, не только улучшить ваши приложения надежности (и понятности) он также будет гарантировать, что вы не в конечном итоге на thedailywtf.com;)