券商高速高稳定性行情服务解决方案(单机qps28万/秒)

背景

前段时间和券商IT朋友交流，提到早盘高并发的情况下，行情系统经常卡死，用Java开发的服务端八万的并发已经扛不住了。之前也在百度做过类似的系统，所以第一反应想到的就是加机器，现在觉得这个想法还是有点幼稚了，因为时间原因，当时没有深入交流，最近刚好又有点时间，回想到那次交流，加上自己这几年的技术积累，感觉应该可以解决这个问题，利用一个周末的时间，用golang开发了一个行情服务，然后又经过几轮压测和优化，单机(32Core+64G)的requests/sec 最高能达到了28万/秒

方案设计

加机器不是一个好方案

1、机器成本

互联网公司有钱，可以短时间能准备准备大量的机器，一般中小型公司，又是自有机房，不可能短时间能凑够大量机器

2、运维成本

机器多了，尤其是达到了几十台或者几百台机器，运维成本会大幅上升，互联网公司有专业且强大的运维团队支持，开发人员不用太担心，记得当时在某互联网金融公司，仅仅一个微服务，多大30个结点的集群，每次部署得1个小时，经常要专门配备开发人员每天负责发布和部署。一个数据库用分库分表，竟然分了100个库，这种一般中小型公司，仅仅一两个运维人员，是不可能扛得住

为什么采用go而不是Java

Java出来有28多年了，刚开始的Java并不是为大并发设计的，虽然这几年java也在不断升级以追求大并发和低延迟，但是相比那种天生为并发和低延迟而设计的语言，有点差强人意，这其中主要代表就是golang，天生就是具备了大并发的基因

go语言的大并发靠就是协程，协程一般称为轻量级线程，也叫用户态线程，Java21即将推出的叫虚拟线程，其实都是一个意思，协程的好处在大并发情况下不会阻塞线程，而线程在大并发情况下会阻塞线程；而且单机线程数是有限的一般和CPU密切相关，单机协程数可以开到几十万。这里说的线程严格的说是内核态线程，因为线程是操作系统提供的，下面图是关于线程和协程的阻塞调度模型：

• 线程调度模型(Java）

• 协程调度模型（golang）

以上两种调度对比:

1、线程调度模型会阻塞线程，不能为其他任务服务，导致系统资源的浪费

2、协