> I think the unique random token of Redlock is enough for Check & Set when the lock holder work materializes into a database write But that's optimistic conc

> I think the unique random token of Redlock is enough for Check & Set when the lock holder work materializes into a database write But that's optimistic concurrency control! In that case the locking service is a pure optimization and doesn't affect correctness. So why use this complex multi-node locking thing then, instead of a single redis node?