|
锁定老帖子 主题：讨论证券公司一个技术方案
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-09-10
springluo 写道 模仿新浪行情是肯定不行的，我看有的用flex主动请求刷新
但是flex有些莫名其妙的问题，不太稳定。 我也想知道用什么做比较好 应该就用普通的web页面，分页加载比较可取。 我自己想的，不知道行不行，把行情数据加载到服务器内存中用两个缓存new，back来区分行情的新数据和旧数据，然后每次请求都是从new中取，back取了之后将new和back，back再从证交所取新的行情。 因为客户多，大致可以分散在几个区域，用ip分段进行第一次的均衡。然后是weblogic的二次均衡。 大家有好想法多多指教！ 我比较赞同springluo的方案，我也是考虑建分区服务，IP分段访问。再在服务器上做缓存，还是采用客户端刷的方式，server-push建长连接不大可能，那不知要买多少台服务器才行。 |
| 返回顶楼 | |
|
发表时间：2011-09-10
memcache client定时刷新
|
| 返回顶楼 | |
|
发表时间：2011-09-11
并发量，性能，实时，要求有点高啊
|
| 返回顶楼 | |
|
发表时间：2011-09-11
cdredfox 写道 服务器上直接缓存即可，不用区分back,new,请求通过缓存，取不到则直接拿最新的行情。按股票+时间缓存，股票总共一那么多支，命中率因该还可以。
另外可缓存一部分行情到客户端，比如15分内的，一次推送过去，用于画五分钟线等。 客户端缓存，感觉不错 |
| 返回顶楼 | |
|
发表时间：2011-09-11
每30秒将结果静态化，由http服务器应付多少请求都抗得住
|
| 返回顶楼 | |
|
发表时间：2011-09-11
kaneg 写道 每30秒将结果静态化，由http服务器应付多少请求都抗得住
是否考虑在生成静态的瞬间会有文件访问不了？要在这个位置考虑一下。 |
| 返回顶楼 | |
|
发表时间：2011-09-11
websocket当然好， 当前还不成熟，浏览器实现的还不够。
所以可以考虑cometd框架，采用长轮询，这个是client pull的方式。能很好的处理大并发量的实时数据请求。 cometd 这个框架是bayeux协议的实现，Java语言版本的实现 基于Jetty Continuation API 浏览器端可以用dojo的库或者jquery的库，官方有直接的支持。 你的应用来看，客户端和服务器端缓存肯定都需要。至于缓存结构的设计，看你的具体情况。 再来说说cometd，你可以看看官方的文档，api demo 比较齐全 网址 http://cometd.org/ 当然有必要先看下 bayeux协议 网址 http://cometd.org/documentation/bayeux/spec |
| 返回顶楼 | |
|
发表时间：2011-09-11
jinyanhui2008 写道 kaneg 写道 每30秒将结果静态化，由http服务器应付多少请求都抗得住
是否考虑在生成静态的瞬间会有文件访问不了？要在这个位置考虑一下。 静态化，每次覆盖前一次生成的文件，或加一层缓存! |
| 返回顶楼 | |
|
发表时间：2011-09-12
做证券公司的技术架构一定要考虑证券公司的特点和证券的特点，否则会走很多弯路。
1。证券方面后台很少用数据库，用文件存储，日线一个股票一个文件。证券的特征就是从没有同时查询2个股票的需求。 2。每天实时行情有个特点，就是每天9点前就确定了今天开盘的股票，这个在架构设计上一定要考虑。实时行情也用文件存储。 3。30s刷新一次行情太慢，按照6s设计吧，后期肯定会被要求修改。 还有一个最大问题就是真的需要考虑100万并发么？目前最大的证券公司也就几百万用户数，其中90%都是用pc客户端登录的，真正没几个会用页面看行情，不用太多虑。 |
| 返回顶楼 | |
|
发表时间：2011-09-16
最后修改：2011-09-16
看了下QQ的股票， 也是定时主动去请求的。目测了下定时6秒
|
| 返回顶楼 | |
