Используя тикет-сервер для генерации первичных идентификаторов?

Question

Я строю распределенное приложение поверх Java и Cassandra. Для генерации уникальных последовательных 32-битных и 64-битных идентификаторов подходит ли такой подход, как использование серверов билетов Flickr для генерации первичных идентификаторов? Я особенно взволнован этим, поскольку это может помочь мне уменьшить размер идентификаторов до 32 или 64 бит, если требуется, что в противном случае может увеличиться до 128 бит с UUID. Я не хочу, чтобы эти идентификаторы были идеально последовательными, но увеличивались как минимум!

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

Похоже ли это на хорошую стратегию? Короче говоря, мы смешиваем MYSQL и Cassandra в одном приложении. Я знаю, что если по какой-то причине mySQL не работает, мы не сможем продолжить работу только с Кассандрой.

Мы смотрели на другие решения, такие как снежинка, но они не полностью соответствовали нашим требованиям.

РЕДАКТИРОВАТЬ: я ищу совета о том, является ли использование MySQL для создания уникальных первичных идентификаторов для ключа данных / сущностей, хранящихся в базе данных Cassandra, является хорошим подходом. Каковы недостатки, если таковые имеются, подхода, подобного билетным серверам Flickr?

Answer 1

Я не большой поклонник попыток придать смысл суррогатным ключам (что вы пытаетесь сделать, если хотите, чтобы они со временем увеличивались). Как видите, это усложняет задачу создания ключей. Предполагая, что вы хотите, чтобы ключи со временем увеличивались просто для сортировки данных, почему бы не включить временную метку, когда объект был создан, и сохранить ее в своем хранилище данных? Это значительно упрощает генерацию ключей и позволяет вам делать практически все, что вы могли бы делать с ключами, которые со временем увеличиваются, с дополнительным бонусом того факта, что для любого, кто будет поддерживать ваш код, будет совершенно ясно, как следует сортировать объекты. 1001 *

Answer 2

В общем, вы не можете иметь как «постоянно растущий», так и «без SPOF и без сложной синхронизации».

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

Действительно простой пример упоминается в статье, на которую вы ссылаетесь: один сервер создает нечетные, а другой - четные. (Вы можете расширить это на несколько серверов тривиально). Конечно, тогда вы не можете быть уверены, что один сервер не работает впереди другого, что может привести к не увеличивающейся последовательности, такой как 111, 120, 113, 122, 115, 124 ...

Если вы хотите только «приблизительно увеличить», вы можете реализовать схему, в которой каждый сервер через определенные промежутки времени (например, каждую минуту или каждые 10000 идентификаторов) сообщает другому (им) свой текущий идентификатор, а другой затем переходит его собственное удостоверение личности (только вперед), если он висит слишком далеко. Это должно быть сделано способом, который не прерывает генерацию идентификатора, для надежности, если другой сервер не работает.

---

Ах, для "свободных битов в конце" просто умножьте свой идентификатор на несколько number (один и тот же каждый раз, и степень два, если вам действительно нужны "свободные биты", а не только "место для data "), затем добавьте свои данные (которые должны быть меньше number). Но, конечно, тогда у вас не хватит места для идентификатора немного раньше (по фактору number).