35 lines
1.6 KiB
Go
35 lines
1.6 KiB
Go
package config
|
||
|
||
import (
|
||
"encoding/json"
|
||
"sync"
|
||
)
|
||
|
||
var _ = json.RawMessage{}
|
||
var _ = sync.Mutex{}
|
||
|
||
//
|
||
// Process-wide id counters whose high-water mark survives a restart.
|
||
// 2026-09-24 自捐赠端 DremkaPS handoff §6.10 移植：「编号高水位必须落盘」。
|
||
// 背景：本服此前所有自分配号段都是 private static long x = FLOOR; 加
|
||
// Interlocked.Increment，序号只活在进程里。服务端一重启就回到 FLOOR 重新发号，
|
||
// 而对端（客户端 / 已落盘的存档）可能还记得上一轮的号 —— 同一个 UniqueId / unitId 发出去两遍，
|
||
// 表现就是「发了但看不见」「SyncLogicAgentLeave 变成 no-op」「换个号段才正常」这类
|
||
// 查起来完全不像重号的怪现象。
|
||
// 用法：把 Interlocked.Increment(ref s_x) 换成
|
||
// IdCounterStore.Next("文件.字段名", FLOOR)，语义完全一致（返回 +1 之后的值），
|
||
// 只是多了一步落盘。FLOOR 仍由调用方持有，存档里的值低于 FLOOR 时自动抬回 FLOOR，
|
||
// 所以调整号段不会把旧的高水位带进新号段。
|
||
// 落盘是同步写：调用点全是低频的面板 / GM 控制台操作（生成 NPC、建车、发物品），
|
||
// 一个几百字节的 JSON 不值得为此引入延迟写入的复杂度。写失败只记日志、绝不影响发号。
|
||
//
|
||
type IdCounterStore struct {
|
||
Gate any `json:"gate"`
|
||
Options any `json:"options"`
|
||
// ServerLogger 没有全局实例（只读构造器，Write 是实例方法），所以这里自带一个。
|
||
Log any `json:"log"`
|
||
HighWater map[string]int64 `json:"highWater"`
|
||
FilePath string `json:"filePath"`
|
||
}
|
||
|