这是一个创建于 1827 天前的主题，其中的信息可能已经有所发展或是发生改变。
一共有几千支股票，价格每秒都在变化 每个用户初始持有股票，并且随着下单变化 现在要求每支股票价格变化、或者用户持股数量变化的时候统计出用户持股总额（每支股票数量*价格的和）
我遇到的问题是股票的价格每秒可能会有几千次变化， 每次变化都要去数据库查找这支股票被哪些用户的持有，实在太慢了，做不到实时统计 所以想来问下，大家有什么好看法，或者有什么框架可以套用这种场景？
 | 1 noahzh 2020-10-10 18:53:27 +08:00 用订阅模式,每个用户去订阅自己的股票就完了. |
 | 2 SelectLanguage OP @noahzh 服务端需要计算知道每个用户的总金额，在金额达到一定条件的时候通知用户，所以不能放在客户端去计算 |
 | 3 huayumo 2020-10-10 20:59:24 +08:00 为是什么是"每次变化都要去数据库查找这支股票被哪些用户的持有" 我的看法是用户打开自己的持仓界面的时候,开始获取数据,而且是根据股票代码获取股票价格,持仓数据,然后计算持仓总额. 这个数据要求延迟低,感觉起码是 redis 这样的数据库来存储,主要股票价格变动的实时化,只要接口速度快,持仓量可以做个缓存. 没做个这个,不过这个数据一般都会有延迟,股票的买卖是排队形式的,即使你看到了价格,你立即下单,可能排不上你,网络上的价格都是存在延迟的. 自己平台只要时间不要差太多就可以了,如果是证券公司,估计有交易所数据接口,会更快一点吧 纯属个人观点 |
| 4 SelectLanguage OP @huayumo 需求是要实时检测 比如某个用户持仓金额超过一万 就要发短信提醒他 所以就算用户没有打开自己的持仓界面，服务端也要计算 |
 | 5 Jooooooooo 2020-10-10 22:18:10 +08:00 @huayumo 你没理解需求. 需求是用户 A 对于股票 1 设定了一个通知价格 x, 到了这个价格立马通知用户 (无论是 push 还是短信) 因为用户数量大, 股票价格的阶梯数量也大, 怎么设计数据结构很关键 |
 | 6 yc8332 2020-10-10 22:18:44 +08:00 那你这个逻辑不现实。每秒变化，你可能通知用户还没操作就一直在变化，一直通知？ |
 | 7 9LCRwvU14033RHJo 2020-10-10 23:11:03 +08:00 一台机打算服务多少个用户？ |
 | 8 jones2000 2020-10-10 23:21:00 +08:00 单独做一个用户持仓信息计算的服务， 1. 订阅行情， 2. 用户信息放内存， 股票有变化就实时计算用户金额 3. 交易下单操作以后， 通知这个服务更新用户信息 |
 | 9 dizun 2020-10-10 23:25:39 +08:00 via Android  1 场外配资？？ |
 | 10 l00t 2020-10-10 23:31:44 +08:00 首先，股票的价格不会每秒变化几千次……一秒顶多也就一到两次。 然后，嫌慢你就别去数据库找……加载到内存里找啊。用户量多少？量大的话多搞点机器。 |
| 11 SelectLanguage OP |
| 12 l00t 2020-10-10 23:54:11 +08:00 @SelectLanguage #11 通知你可以用消息队列。节点故障现阶段你可以不考虑。机器挂了就是挂了。你单个机器挂了也是挂了。你如果有单个机器挂了热切备机的方案，那么同理给多个机器做上就行。 |
 | 13 wangbenjun5 2020-10-11 00:00:14 +08:00 1 看各位说的，我感觉这个需求并不复杂，首先，用户持仓数据变化并不大，可以认为是固定的，其次股票的价格也不是每秒变化几千次。。。 一般像同花顺这类的炒股软件，数据更新延迟好像都有 200-300ms，哪有实时这个概念！你这个需求，无非是整个定时任务，隔一段时间算一次 |
| 14 jones2000 2020-10-11 02:20:59 +08:00 @SelectLanguage 像这些小的应用服务，尽力不要用 HADOOP 、SPARK 这些大型的框架， 除非你对他们的内部构架十分了解，否则都是坑，还不如自己写一个快。 行情数据都是实时过来的，只需要存最新的快照数据就可以，不大。 如果是用户多， 可以指定一个服务跑哪几个用户。 多部署几套服务就可以了， 用 docker 也可以。 |
 | 15 realpg PRO 1 搞过带杠杆的超保证金强行平仓，就需要实时计算用户的市值结合杠杆是否需要强平 如果用户不是复杂持仓（我那边估算，持有超过 17 种以下单一价格票证），有巧妙的算法解决，复杂持仓因为复杂度，就会让这个算法的效率无法接受了 搞这种应用的，算法都是很值钱的。如果搞不定一些黑科技，那就老老实实的所有用户每个周期跑 |
| 16 9LCRwvU14033RHJo 2020-10-11 04:26:14 +08:00 @realpg 17 种以下？如果是不超过 16，听起来像是用 SIMD 优化。 |
 | 17 xuanbg 2020-10-11 07:48:25 +08:00 不需要实时，进入包含持股金额的界面时读取数据，然后让用户手动刷新就完了。 |
| 18 xuanbg 2020-10-11 07:50:18 +08:00 @SelectLanguage 你这个也不需要实时，设置一个定时任务就行。1 分钟处理 1 遍也就差不多了。 |
 | 19 playniuniu 2020-10-11 07:50:58 +08:00 via Android 我觉得比较简单粗暴的方式是 redis 存股票价格 和每只股票所有绑定的用户 id 然后股票价格一变化 就把所有用户 id 放入队列算持仓 再把需要通知的用户放到通知队列 当然可以加个延时 比如用户已经算过一次的 可以 5 妙内不在计算 降低点系统负担 |
 | 20 coyove 2020-10-11 10:03:19 +08:00 秒级数据都是直接进内存的，连 redis 都没用，一个服务器服务固定的用户 |
| 21 noahzh 2020-10-11 10:52:22 +08:00 @SelectLanguage 一样的的解决方法,这里不要区分什么服务端了,一个 topic 是股票代码,内容是股票价格,每个用户一个 topic 是 他持有股票总类和数量,保证金这些东西,就完全解决了. |
 | 22 imn1 2020-10-11 10:55:50 +08:00 1.变化的价格有实时系统就足够了 2.客户端只是显示的话，没必要绝对实时，况且很多并非每秒变化，真的做到每秒多个数据同时刷新，看的人眼睛很累的，甚至会晕厥 应该做 server push，这样就没必要每个股票*每秒查询了 3.至于服务端总额预警，应该另外采取一套计算，是判别价格而不是总额 为啥要每次价格变化就算一次总额？不如从预警总额反推预警价格（只计算一次就够了），比较第一条达到预警目的 4.above all，真要做到那种极致的实时，上硬件支持 |
 | 23 TypeError 2020-10-11 12:27:38 +08:00 via Android 雪球在股市风暴下的高可用架构改造分享 https://www.cnblogs.com/yudar/p/4782131.html |
Select Language