这是一个创建于 486 天前的主题，其中的信息可能已经有所发展或是发生改变。
参加：2 个不同个人局域网的 PC ，运行一套 python 程序，基于 a 股的量化交易。
现在要求 a ，b 两个机子根据对方的成交与否，觉得另一方的下一步。
比如 a 成交了，b 就融券卖出，如果 a 没有成交，b 就卖出，诸如此类。
目前方法是 走 redis ，把 a ，b 的状态放到 redis ，同步双方的状态，
，
目前遇到的问题是 同步一次的需要 2-3 秒的时间，主要的耗时：
1. 获取 a 是否成交，这个通过循环获取订单状态，感觉这一步没法优化，因为读取状态需要时间，也是走网络，渠道券商柜台。
2. a 把状态放入 redis ，b 读取，这个一个流程里面大概会有 6 次 redis key 的读取，感觉这里的速度有点慢了。
试过判读 key 是否存在，还有 blpop 设置 0.5 秒超时，设置时间短了，如果 a 来不及获取到成交状态并推送到 redis ，
会误判没有成交，实际 a 端已经成交了。
感觉用 rabbitmq zeromq 这种消息队列会不会好一些？
或者有没有成熟的技术方案?
先谢过各位老师大佬
现在要求 a ，b 两个机子根据对方的成交与否，觉得另一方的下一步。
比如 a 成交了，b 就融券卖出，如果 a 没有成交，b 就卖出，诸如此类。
目前方法是 走 redis ，把 a ，b 的状态放到 redis ，同步双方的状态，
，
目前遇到的问题是 同步一次的需要 2-3 秒的时间，主要的耗时：
1. 获取 a 是否成交，这个通过循环获取订单状态，感觉这一步没法优化，因为读取状态需要时间，也是走网络，渠道券商柜台。
2. a 把状态放入 redis ，b 读取，这个一个流程里面大概会有 6 次 redis key 的读取，感觉这里的速度有点慢了。
试过判读 key 是否存在，还有 blpop 设置 0.5 秒超时，设置时间短了，如果 a 来不及获取到成交状态并推送到 redis ，
会误判没有成交，实际 a 端已经成交了。
感觉用 rabbitmq zeromq 这种消息队列会不会好一些？
或者有没有成熟的技术方案?
先谢过各位老师大佬
 |
1
jones2000 2024-07-06 19:12:15 +08:00  1
就 2 个机器， 直接 TCP 做一个长链接(c/s 模式的就可以)， 一方数据变动了， 发一个数据包给对方机器，同步下对方机器的数据。
|
 |
2
cybort 2024-07-06 19:33:05 +08:00 via Android
一楼说的对，应该主动通知，不应该去查，相当于有两个写竞争，写出的那个有义务广播去更新 cache
|
 |
3
flmn 2024-07-06 20:17:02 +08:00
首先柜台接口除了提供查询接口，应该也提供通知接口的，这个你可以调研一下。
ab 互相通知的话，zmq 我觉得是可以的，比自己手写 socket 要简单一些。 |
 |
4
kiracyan 2024-07-07 00:56:36 +08:00
grpc
|
 |
5
gongquanlin 2024-07-07 11:19:44 +08:00
rpc 、长连接、队列，哪个不都能满足你的需求
|
 |
6
R4rvZ6agNVWr56V0 2024-07-08 10:26:17 +08:00
redis 有 pubusb 模式啊
|
|
7
R4rvZ6agNVWr56V0 2024-07-08 10:26:57 +08:00
|
 |
8
yagamil OP @gongquanlin #5 需要选一个性能 或者方案最优的。 现在用 redis ，用阻塞 pop 的方式，发现返回结果要 0.3s 之多
|
|
9
gongquanlin 2024-07-08 11:07:40 +08:00
@yagamil 哦哦那还是长连接吧，效率最高~
|
 |
10
cppc 2024-07-08 11:33:16 +08:00
设计模式采用发布-订阅，底层技术可选的很多，redis pubusb ，postgres channels ，或者直接上专业 MQ
|
 |
11
skuuhui 2024-07-09 16:29:55 +08:00
你要找的是不是“分布式事件总线”？
|
Select Language