- 主题:stackoverflow 有个比较 c++ stackful 和 stackless 协程的帖子
一般的，银行股票，淘宝京东，12306，携程，包括支付宝微信支付，都不需要吧。
一个是响应时间，秒级，一个是吞吐量，每分钟多少交易。
【 在 gfkid 的大作中提到: 】
: 可是mvtec说，高频交易都在抠cycle
: 可是如果网络延迟都有上百微秒了，是否还有必要呢
: 另外听说高频交易都有专门的网络，不知道是不是协议也是专有的
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
是的。
但是具体到其中关键算法，扣一点指令还是会的。
比如管理器，取服务器的连接，将客户端数据发往服务器，等服务器返回后，先释放连接，后给客户端返回数据。保证连接能够尽快为下一个客户使用。
【 在 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.*
交易管理器也可以配置多个，可以更多的客户端。
也可以级联使用，级数不限。
服务器的数量和规模，可以无限扩展。
允许在全球部署，分布应用。它的数据传输是加密和压缩的。
客户端的接人需要认证。可以在不安全的互联网进行安全的交易。
【 在 ziqin 的大作中提到: 】
: 你们这个所谓的交易构架，客户端有几万个，我就表示怀疑是不是正儿八经的交易构架
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
银行的ATM不是吗，股票不是吗？京东淘宝不是吗？
小到几百个也可以呀。
还可以与WEB接口，一个网站给它若干连接。它的业务用到我的数据时才调用这些连接。这样服务的用户数几乎是无限的。
【 在 ziqin 的大作中提到: 】
: 听起来更像经纪商的平台构架，而不是交易构架，哪个正儿八经的交易系统，会有几个万个客户端
:
--
FROM 221.218.61.*
其实重点是，在高频交易系统中，在交易管理环节，需要协程技术，而且是多线程的协程。需要高效率的切换，一个服务完成后，尽可能快速切换到另一个用户，尽量减少服务的空等时间。
有点像银行的排队机，一个窗口空了，马上叫下一位。
单线程的协程不行，一个连接空闲了，线程还在别的协程忙活，慢慢悠悠轮到这个协程再处理。
我比较担心fiber框架能否处理多线程协程。线程协程没有绑定关系，任何线程有空就处理任何协程。
【 在 ziqin 的大作中提到: 】
: 听起来更像经纪商的平台构架，而不是交易构架，哪个正儿八经的交易系统，会有几个万个客户端
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
管理器不连数据库。只负责协调资源，和安全隔离。
多线程协程只在管理器使用。用于在客户端与服务器间传递数据。线程无需与核绑定，协程也无需与线程绑定。谁有空谁处理，不要耽误时间。
架构见48楼。
【 在 mvtec 的大作中提到: 】
: HFT根本不可能在trading过程中
: 连数据库的
: 所有的app全是single thread
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
它关心一个任务的响应速度，交易系统关心的是总体的交易吞吐量。
【 在 mvtec 的大作中提到: 】
: HFT根本不可能在trading过程中
: 连数据库的
: 所有的app全是single thread
: ...................
--
FROM 221.218.61.*
做过一个压力测试，服务器8台各16核，
管理器12核，12线程。模拟了10000个客户端，把8台服务器干到了100%，管理器也干到了85%的CPU利用率。
多线程协程自己写的，用的makecontext那一组函数，stackfull。自己造轮子，没有哪个现成的适用。
有意思的那些服务器登录都登不进去了，Linux，非抢占的。
【 在 mvtec 的大作中提到: 】
: HFT根本不可能在trading过程中
: 连数据库的
: 所有的app全是single thread
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*
本来就是这种队列。协程是每个客户端链接一个协程。一共16000个（可设置1000～65534）。
每核一个线程。用epoll进行调度，激活的是哪个协程就干哪个协程，挺简单的。
哪个协程需要进入IO，就设置好epoll，然后挂起。等待epoll激活。一堆线程在进行epoll_wait。就这么简单。
【 在 hgoldfish 的大作中提到: 】
: 这个太简单了。弄个生产者消费者队列就行了。每个线程启动 100 个协程，一共 16 个核心是 1600 个协程。这些协程都在消费者队列里面抢任务。
: 如果打算节约资源，就在每个线程里面启动一个监管协程，检测空闲协程的数量。空闲协程太多，就杀掉一些协程，少了就再启动预备状态的协程。
: 由编程语言，比如 go, java, c# 那样子把协程自动地在各种线程之间调来调去一般都是没有必要的。
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*