实时计算用户持股金额的股票系统要怎么设计好?

2020-10-10 18:48:46 +08:00
 SelectLanguage

一共有几千支股票,价格每秒都在变化 每个用户初始持有股票,并且随着下单变化 现在要求每支股票价格变化、或者用户持股数量变化的时候统计出用户持股总额(每支股票数量*价格的和)

我遇到的问题是股票的价格每秒可能会有几千次变化, 每次变化都要去数据库查找这支股票被哪些用户的持有,实在太慢了,做不到实时统计 所以想来问下,大家有什么好看法,或者有什么框架可以套用这种场景?

2841 次点击
所在节点    Java
23 条回复
noahzh
2020-10-10 18:53:27 +08:00
用订阅模式,每个用户去订阅自己的股票就完了.
SelectLanguage
2020-10-10 19:59:02 +08:00
@noahzh 服务端需要计算知道每个用户的总金额,在金额达到一定条件的时候通知用户,所以不能放在客户端去计算
huayumo
2020-10-10 20:59:24 +08:00
为是什么是"每次变化都要去数据库查找这支股票被哪些用户的持有"
我的看法是用户打开自己的持仓界面的时候,开始获取数据,而且是根据股票代码获取股票价格,持仓数据,然后计算持仓总额.
这个数据要求延迟低,感觉起码是 redis 这样的数据库来存储,主要股票价格变动的实时化,只要接口速度快,持仓量可以做个缓存.
没做个这个,不过这个数据一般都会有延迟,股票的买卖是排队形式的,即使你看到了价格,你立即下单,可能排不上你,网络上的价格都是存在延迟的.
自己平台只要时间不要差太多就可以了,如果是证券公司,估计有交易所数据接口,会更快一点吧
纯属个人观点
SelectLanguage
2020-10-10 22:15:32 +08:00
@huayumo 需求是要实时检测 比如某个用户持仓金额超过一万 就要发短信提醒他
所以就算用户没有打开自己的持仓界面,服务端也要计算
Jooooooooo
2020-10-10 22:18:10 +08:00
@huayumo 你没理解需求.

需求是用户 A 对于股票 1 设定了一个通知价格 x, 到了这个价格立马通知用户 (无论是 push 还是短信)

因为用户数量大, 股票价格的阶梯数量也大, 怎么设计数据结构很关键
yc8332
2020-10-10 22:18:44 +08:00
那你这个逻辑不现实。每秒变化,你可能通知用户还没操作就一直在变化,一直通知?
user8341
2020-10-10 23:11:03 +08:00
一台机打算服务多少个用户?
jones2000
2020-10-10 23:21:00 +08:00
单独做一个用户持仓信息计算的服务,
1. 订阅行情,
2. 用户信息放内存,
股票有变化就实时计算用户金额
3. 交易下单操作以后, 通知这个服务更新用户信息
dizun
2020-10-10 23:25:39 +08:00
场外配资??
l00t
2020-10-10 23:31:44 +08:00
首先,股票的价格不会每秒变化几千次……一秒顶多也就一到两次。

然后,嫌慢你就别去数据库找……加载到内存里找啊。用户量多少?量大的话多搞点机器。
SelectLanguage
2020-10-10 23:47:57 +08:00
@jones2000 @l00t 放到内存中可以,但是如果数据很多,需要分割数据存到多台机器中,感觉要考虑很多问题,比如怎样通知多台机器、部分节点故障要如何处理等等。。感觉自己来实现的话会很复杂,而且不一定做得好
想知道有没有现成的框架能处理这个事情,比如大数据 HADOOP 、SPARK 之类的(我对这些不是很清楚,想知道在这种场景下能用得上吗?)
l00t
2020-10-10 23:54:11 +08:00
@SelectLanguage #11 通知你可以用消息队列。节点故障现阶段你可以不考虑。机器挂了就是挂了。你单个机器挂了也是挂了。你如果有单个机器挂了热切备机的方案,那么同理给多个机器做上就行。
wangbenjun5
2020-10-11 00:00:14 +08:00
看各位说的,我感觉这个需求并不复杂,首先,用户持仓数据变化并不大,可以认为是固定的,其次股票的价格也不是每秒变化几千次。。。

一般像同花顺这类的炒股软件,数据更新延迟好像都有 200-300ms,哪有实时这个概念!你这个需求,无非是整个定时任务,隔一段时间算一次
jones2000
2020-10-11 02:20:59 +08:00
@SelectLanguage 像这些小的应用服务,尽力不要用 HADOOP 、SPARK 这些大型的框架, 除非你对他们的内部构架十分了解,否则都是坑,还不如自己写一个快。
行情数据都是实时过来的,只需要存最新的快照数据就可以,不大。
如果是用户多, 可以指定一个服务跑哪几个用户。 多部署几套服务就可以了, 用 docker 也可以。
realpg
2020-10-11 02:36:48 +08:00
搞过带杠杆的超保证金强行平仓,就需要实时计算用户的市值结合杠杆是否需要强平

如果用户不是复杂持仓(我那边估算,持有超过 17 种以下单一价格票证),有巧妙的算法解决,复杂持仓因为复杂度,就会让这个算法的效率无法接受了

搞这种应用的,算法都是很值钱的。如果搞不定一些黑科技,那就老老实实的所有用户每个周期跑
user8341
2020-10-11 04:26:14 +08:00
@realpg 17 种以下?如果是不超过 16,听起来像是用 SIMD 优化。
xuanbg
2020-10-11 07:48:25 +08:00
不需要实时,进入包含持股金额的界面时读取数据,然后让用户手动刷新就完了。
xuanbg
2020-10-11 07:50:18 +08:00
@SelectLanguage 你这个也不需要实时,设置一个定时任务就行。1 分钟处理 1 遍也就差不多了。
playniuniu
2020-10-11 07:50:58 +08:00
我觉得比较简单粗暴的方式是 redis 存股票价格 和每只股票所有绑定的用户 id 然后股票价格一变化 就把所有用户 id 放入队列算持仓 再把需要通知的用户放到通知队列 当然可以加个延时 比如用户已经算过一次的 可以 5 妙内不在计算 降低点系统负担
coyove
2020-10-11 10:03:19 +08:00
秒级数据都是直接进内存的,连 redis 都没用,一个服务器服务固定的用户

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/713759

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX