160 lines
4.8 KiB
Markdown
160 lines
4.8 KiB
Markdown
# 共享内存时间戳机制说明
|
||
|
||
## 问题背景
|
||
|
||
原始实现中，Python 端每 30 秒更新一次共享内存数据，而 Go 客户端每秒读取一次。由于共享内存中的数据不会自动清除，Go 客户端每次读取的都是同一份旧数据，导致看起来像是每秒都收到了新行情。
|
||
|
||
## 解决方案：时间戳版本检测
|
||
|
||
### 核心思路
|
||
|
||
在共享内存头部添加**时间戳字段**，Go 客户端通过检测时间戳变化来判断数据是否真正更新。
|
||
|
||
### 共享内存头部结构（16字节）
|
||
|
||
```
|
||
偏移量 | 字段名 | 类型 | 说明
|
||
--------|---------------|--------|------------------
|
||
0-3 | version | uint32 | 版本号（当前为1）
|
||
4-7 | write_pos | uint32 | 写入位置指针
|
||
8-11 | last_data_len | uint32 | 最后一条数据的长度
|
||
12-15 | timestamp | uint32 | Unix 时间戳（秒级）
|
||
```
|
||
|
||
### 工作流程
|
||
|
||
#### Python 端（生产者）
|
||
|
||
1. 每次调用 `publish_tick()` 时：
|
||
- 序列化数据并写入共享内存
|
||
- **更新头部时间戳为当前 Unix 时间戳**
|
||
|
||
2. 关键代码位置：`src/qmt/tick_push.py` 第 93-97 行
|
||
|
||
```python
|
||
# 更新写入位置、最后数据长度和时间戳
|
||
new_pos = current_pos + 4 + data_len
|
||
timestamp = int(time.time()) # Unix 时间戳
|
||
struct.pack_into('<I', buf, 4, new_pos)
|
||
struct.pack_into('<I', buf, 8, data_len)
|
||
struct.pack_into('<I', buf, 12, timestamp) # 更新时间戳
|
||
```
|
||
|
||
#### Go 端（消费者）
|
||
|
||
1. `TickReader` 结构体新增字段：
|
||
```go
|
||
type TickReader struct {
|
||
shmName string
|
||
bufferSize int
|
||
mappedFile windows.Handle
|
||
view uintptr
|
||
lastTimestamp uint32 // 上次读取的时间戳
|
||
}
|
||
```
|
||
|
||
2. `ReadLatestTick()` 方法增加时间戳检测：
|
||
- 读取头部时间戳
|
||
- **与上次读取的时间戳比较**
|
||
- 如果相同，返回错误 "数据未更新"
|
||
- 如果不同，继续读取数据并更新 `lastTimestamp`
|
||
|
||
3. 关键代码位置：`client_go/tick_reader.go` 第 105-152 行
|
||
|
||
```go
|
||
// 解析时间戳
|
||
currentTimestamp := binary.LittleEndian.Uint32(header[12:16])
|
||
|
||
// 检查数据是否更新
|
||
if currentTimestamp == r.lastTimestamp {
|
||
return nil, fmt.Errorf("数据未更新")
|
||
}
|
||
|
||
// ... 读取数据 ...
|
||
|
||
// 更新最后时间戳
|
||
r.lastTimestamp = currentTimestamp
|
||
```
|
||
|
||
### 优势
|
||
|
||
1. **高频读取无浪费**：Go 客户端可以每秒甚至更频繁地读取，但只在数据真正更新时才处理
|
||
2. **实时响应**：一旦 Python 端写入新数据，Go 端最多延迟 1 秒就能检测到
|
||
3. **向后兼容**：只需修改头部最后一个字段（reserved → timestamp），不影响其他逻辑
|
||
4. **简单高效**：无需额外的事件通知机制，纯轮询方式实现
|
||
|
||
### 测试验证
|
||
|
||
#### Python 端测试
|
||
|
||
运行测试脚本验证时间戳是否正确更新：
|
||
|
||
```bash
|
||
cd d:\work\quant\qmt
|
||
python test\test_timestamp.py
|
||
```
|
||
|
||
预期输出：
|
||
```
|
||
============================================================
|
||
测试共享内存时间戳机制
|
||
============================================================
|
||
|
||
[1] 第一次发布数据...
|
||
时间戳: 1775996840 (20:27:20)
|
||
|
||
[2] 等待 2 秒...
|
||
|
||
[3] 第二次发布数据（相同内容）...
|
||
时间戳: 1775996842 (20:27:22)
|
||
|
||
✓ 时间戳已更新: 2 秒
|
||
|
||
[4] 再次等待 2 秒...
|
||
|
||
[5] 第三次发布数据（不同内容）...
|
||
时间戳: 1775996844 (20:27:24)
|
||
|
||
✓ 时间戳继续更新: 2 秒
|
||
|
||
============================================================
|
||
✓ 所有测试通过！
|
||
============================================================
|
||
```
|
||
|
||
#### Go 端测试
|
||
|
||
编译并运行 Go 客户端：
|
||
|
||
```bash
|
||
cd d:\work\quant\qmt\client_go
|
||
go build -o tick_reader.exe tick_reader.go
|
||
.\tick_reader.exe
|
||
```
|
||
|
||
预期行为：
|
||
- Go 客户端每秒读取一次共享内存
|
||
- 只有当 Python 端更新数据时（每 30 秒），才会打印 "接收到新行情"
|
||
- 其余时间会跳过处理（因为时间戳未变化）
|
||
|
||
### 性能对比
|
||
|
||
| 方案 | 读取频率 | CPU 占用 | 响应延迟 | 实现复杂度 |
|
||
|------|---------|---------|---------|-----------|
|
||
| 方案1：调整读取间隔 | 30秒/次 | 低 | 最高 30 秒 | 简单 |
|
||
| **方案2：时间戳检测** | **1秒/次** | **低** | **最高 1 秒** | **中等** |
|
||
| 方案3：事件通知 | 实时 | 最低 | 毫秒级 | 复杂 |
|
||
|
||
### 注意事项
|
||
|
||
1. **时间戳精度**：当前使用秒级时间戳，如果需要更高精度可改为毫秒级（需要 8 字节存储）
|
||
2. **时钟回拨**：理论上系统时钟回拨可能导致时间戳倒退，但在实际交易中几乎不可能发生
|
||
3. **溢出问题**：uint32 时间戳可使用到 2106 年，短期内无需担心
|
||
|
||
### 未来优化方向
|
||
|
||
如果需要更低延迟的响应，可以考虑：
|
||
1. 缩短 Python 端的 `DEFAULT_TICK_INTERVAL`（如改为 5 秒）
|
||
2. 使用 Windows Event 对象实现真正的推送机制
|
||
3. 采用环形缓冲区 + 序列号的无锁设计
|