MariaDB与Galera Cluster下连续序列号生成方案可行性咨询

这个基于乐观锁+版本序列的方案，在Galera Cluster的高并发场景下是可行的，但要注意几个关键细节：

核心逻辑的合理性 #

• 本质是用**乐观锁（CAS操作）**避免并发冲突：通过WHERE version = original_version的条件，同一时间只有一个事务能成功更新seq_no，确保序列号连续。
• _version序列生成的唯一非连续值作为版本标识，每次更新都会替换version字段，能精准检测到并发冲突，避免脏写。

Galera场景下的关键注意事项 #

• 必须完善冲突重试机制：高并发下冲突概率会明显上升，应用层一定要实现自动重试逻辑——重试时要重新读取最新的version，不能复用之前的旧值，否则会一直失败。
• 事务尽量短小：原逻辑里在事务启动后做业务数据处理，会拉长事务持有时间，既增加冲突概率，也影响Galera的复制效率。建议把序列号生成单独放在一个短小的事务里，和业务逻辑分开执行。
• 节点一致性有保障：Galera是强一致性集群，只要集群状态正常，所有节点的_sequence表数据最终会保持一致，不会出现节点间序列号不一致的情况。极端脑裂情况虽可能出现双写，但Galera的仲裁机制会尽量规避。
• 注意性能瓶颈：所有请求都要竞争更新同一行数据，高并发下会形成热点。如果序列号生成压力极大，可以考虑按业务模块拆分不同的seq行（比如每个模块对应一行），但这会牺牲全局连续性。

优化后的SQL逻辑（中文注释） #

-- 所有节点执行逻辑一致
START TRANSACTION;

-- 【建议：业务数据处理移到该事务之外，缩短事务时长】

-- 获取当前版本号
SELECT version INTO original_version FROM _sequence;

-- 从_version序列获取新的版本标识
SELECT nextval('_version') INTO v_new_version;

-- 乐观锁更新序列号和版本号
UPDATE _sequence 
SET seq_no = seq_no + 1, version = v_new_version 
WHERE version = original_version;

-- 检查更新是否成功
IF ROW_COUNT() = 0 THEN  
    -- 更新失败，处理冲突（重试或返回错误）
    ROLLBACK;
ELSE
    -- 更新成功，提交事务
    COMMIT;
END IF;

内容的提问来源于stack exchange，提问作者Sam