Комментарии 4
А смотрели для БД на что-нибудь ещё? По описанию не плохо подходит сюда FoundationDB, есть и сортировка, и внутренние "часы", она же версия, и полностью асинхронный.
Foundation DB я посмотрел, спасибо. Вроде как на первый взгляд у них нет CAS (https://github.com/apple/foundationdb/wiki/Proposal:-compare_and_set-mutation), а есть распределенные транзакции. Это в общем случае дороговато, тогда как compareAndSet в HBase по производительности не отличается от put.
Тут вопрос, а нужны ли они, если исходить из описанных пунктов, то:
Проблема в самих timestamp-ах. Дело в том, что нормального времени у нас нет.
Есть атомарные операции https://apple.github.io/foundationdb/developer-guide.html#atomic-operations
И если нам нужно писать сообщения, то получаем следующую структуру:
префикс/<channel>/<version>/<ts>/<user> = <payload>
version - может проставляться самой БД в момент коммита, что гарантирует всегда растущую последовательность
тогда чтение лога будет выглядеть как getRange(префикс/<channel>/<last_version>, префикс/<channel>/\xff)
В целом, не обязательно использовать CAS, если можно использовать особенности и возможности самой БД.
я согласен с тем, что CAS использовать необязательно, если есть транзакции, я об этом писал. Если нет - нужен CAS, ну это просто исходя из теории.
В случае с FoundationDB вместо CAS-loop-а нужно будет использовать транзакцию - атомарно читать и обновлять список получателей.
По поводу нужности timestamp-ов. Вместо них можно использовать атомарный счетчик, например, FoundationDB их поддерживает. Не совсем понял, какую версию вы хотите использовать в качестве timestamp-а, версию какой записи.
Просто алгоритм строится вокруг возможностей DB. Я рассматривал монгу и hbase, и взял hbase, ну и так совпало, что я ее лучше знаю. В hbase нет транзакций, как нет и глобально-консистентных timestamp-ов, у каждого regionserver-а он свой. Зато есть CAS. Атомарный инкремент тоже есть, но нам вполне подойдет локальный timestamp - он нужен только чтобы сортировать сообщения внутри эпохи, и, если часы не расходятся слишком сильно, проблем не будет. И все равно необходимость в CAS-е никуда не денется.
P.S.: я могу комментировать только раз в день из-за кармы, поэтому такая большая портянка
Публикации
Как я писал свой распределенный мессенджер на Scala/fs2 и немного lock-free. Часть 1: Архитектура и бизнес-логика