Комментарии 4
> векторные часы обладают неприятными свойствами: они вводят условную зависимость между событиями там, где ее нет, и теряют ее там, где она на самом деле есть.
Если размер вектора равен числу процессов, то векторные часы точно отражают зависимости в системе.
> Несуществующие зависимости возникают потому, что логические часы вводят полный порядок на событиях
Показания векторных часов только частично упорядочены.
Если размер вектора равен числу процессов, то векторные часы точно отражают зависимости в системе.
> Несуществующие зависимости возникают потому, что логические часы вводят полный порядок на событиях
Показания векторных часов только частично упорядочены.
Эти две проблемы — не столько проблемы логических часов, сколько неявного учета взаимосвязи событий.
Если два события логически несвязаны и идут друг за другом в пределах одного сервиса, то логические часы такие события упорядочат.
Если мы не имеем явной информации о взаимосвязи событий, невозможно учесть ее при их обработке.
Запросы в Kronos решают эту проблему.
Если два события логически несвязаны и идут друг за другом в пределах одного сервиса, то логические часы такие события упорядочат.
Если мы не имеем явной информации о взаимосвязи событий, невозможно учесть ее при их обработке.
Запросы в Kronos решают эту проблему.
Уточните, пожалуйста, архитектуру системы.
Правильно ли я понимаю, что в системе данные (например, в KV-хранилищах под каждый диапазон) хранятся распределённо, но при этом есть «маршрутизатор», в котором события регистрируются и рассылаются узлам, и он един (для всех узлов и клиентов)?
Иначе:
API реализует только «маршрутизатор», но не каждый из узлов? Система не устойчива к резделению?
Правильно ли я понимаю, что в системе данные (например, в KV-хранилищах под каждый диапазон) хранятся распределённо, но при этом есть «маршрутизатор», в котором события регистрируются и рассылаются узлам, и он един (для всех узлов и клиентов)?
Иначе:
Isolation: если две транзакции пересекаются по данным, значит они будут связаны причинно-следственной связью в Kronos, а значит одна будет выполнена раньше другой.почему из пересечения по данным следует, что причинно-следственная связь будет зарегистрирована с использованием API?
API реализует только «маршрутизатор», но не каждый из узлов? Система не устойчива к резделению?
Всё верно, для транзакций, которые затрагивают ключи на нескольких серверах, необходимо обращаться к централизованому API.
По поводу разделения — если сервера, которые отвечают за ключи, оказываются в разных партициях, трудно себе представить, как выполнить такую транзакцию :(
Если же стоит задача выполнять транзакции внутри новых partitions, то можно предложить такое решение: в куске, из которого недоступен старый Kronos выбирается новый Kronos, который будет управлять зависимостями, все подтвержденные транзакции завершаются, неподтвержденные отменяются.
По поводу разделения — если сервера, которые отвечают за ключи, оказываются в разных партициях, трудно себе представить, как выполнить такую транзакцию :(
Если же стоит задача выполнять транзакции внутри новых partitions, то можно предложить такое решение: в куске, из которого недоступен старый Kronos выбирается новый Kronos, который будет управлять зависимостями, все подтвержденные транзакции завершаются, неподтвержденные отменяются.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kronos: никаких путешествий во времени даже в распределенных системах