一般的，银行股票，淘宝京东，12306，携程，包括支付宝微信支付，都不需要吧。
一个是响应时间，秒级，一个是吞吐量，每分钟多少交易。
【 在 gfkid 的大作中提到: 】
: 可是mvtec说，高频交易都在抠cycle
: 可是如果网络延迟都有上百微秒了，是否还有必要呢
: 另外听说高频交易都有专门的网络，不知道是不是协议也是专有的
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*

都用数据库了，还抠个毛的速度啊

【 在 ylh0315 的大作中提到: 】
: 我设计的高频交易架构是这样：
: 服务器多核多线程，TPC模式，每个链接一个线程。多台服务器。服务器要处理数据库业务，只能使用简单的多线程模式。
: 加一个管理器，对多台服务器设置连接池。对每台服务器有限个链接（服务器有限个线程）。对多个服务器进行负载均衡和容错。
: ...................
--
FROM 183.128.164.*

是的。
但是具体到其中关键算法，扣一点指令还是会的。
比如管理器，取服务器的连接，将客户端数据发往服务器，等服务器返回后，先释放连接，后给客户端返回数据。保证连接能够尽快为下一个客户使用。
【 在 ziqin 的大作中提到: 】
: 都用数据库了，还抠个毛的速度啊
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*

在TUXEDO基础上的改进版。
性能比它高多了。
在交易过载的情况下，最长响应时间与平均响应时间之比，
TUXEDO是9，这个是1.25。
排队是公平的。负载均衡的管理也要比它均衡。
不过依然欢迎提出这个架构的缺点。
自己提两个：
服务器向客户端主动发通知是困难的，提供了消息订阅。TUXEDO也不过如此。

客户端互相交互是困难的，所以不适合游戏。

【 在 ziqin 的大作中提到: 】
: 你们这个所谓的交易构架，客户端有几万个，我就表示怀疑是不是正儿八经的交易构架
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*

听起来更像经纪商的平台构架，而不是交易构架，哪个正儿八经的交易系统，会有几个万个客户端

【 在 ylh0315 的大作中提到: 】
: 在TUXEDO基础上的改进版。
: 性能比它高多了。
: 在交易过载的情况下，最长响应时间与平均响应时间之比，
: ...................
--
FROM 183.128.164.*