券商内部的口语里，"柜台"泛指整套交易系统——"这单走了哪个柜台"问的是下单通道，"柜台系统升级"说的是那套大而全的核心。同一个词指两个粒度的东西，不是口误，而是行业历史：集中交易改造（2000 年代券商把分散在营业部的交易集中到总部一套系统）造出了"集中交易系统"这个词，后来量化私募兴起，低延迟通道从里面分化出来，"极速柜台"这个词又叠了上去。这篇把这两个层次拆开讲。
主柜台：一个系统装下整个券商
集中交易之前，每个营业部有自己独立的小系统，客户换营业部等于换券商，总部看不到全局风险。集中交易改造的核心决策是客户、账户、资金、证券全部上收总部，一套系统服务全部分支机构和全部渠道（现场、电话、网上交易）。
这套主柜台今天看是个典型的"单体巨石"：客户管理、账户体系、委托接入、订单管理、事前风控、清算结算、核算、查询报表，全部在一个技术栈里。它的架构选择由业务性质决定：
- 账务强一致：委托、成交、资金、持仓四张核心表必须时刻对得上，所以交易路径上大量逻辑用数据库事务 + 存储过程实现——这也是后面基础设施篇要讨论的"券商为什么偏爱 Oracle/存储过程"的根源；
- 功能全集：合规要求的功能（适当性、双录、留痕）和业务需要的功能（融资融券、期权、基金代销）都得有，功能堆叠三十年，没人敢做大重构；
- 日终吞吐优先：批量清算跑几个小时的架构，和毫秒级交易路径的架构，在一套系统里互相妥协。
极速柜台：砍功能换延迟
2010 年后量化私募规模化，委托从"人点鼠标"变成"程序发单"，延迟从秒级卷到微秒级。主柜台的架构做不到：数据库事务一次要毫秒级，功能全集意味着代码路径长、依赖多。于是出现极速柜台——它不是把主柜台优化快一点，而是把主柜台砍掉只剩交易通道：
- 状态全内存：资金、持仓、订单全部加载进内存，账务不走数据库事务，靠日志持久化（细节在"内存撮合 vs 数据库撮合"篇展开）；
- 功能砍到底：开户、销户、改资料、清算、报表一概不做，只保留"接委托 → 风控 → 报交易所 → 收回报 → 记内存账"；
- 报盘直连：到交易所的链路专门优化（低延迟网卡、内核旁路，见低延迟手段篇）。
功能砍掉的前提是主柜台还在。极速柜台是寄生的：客户资料、权限、日终清算、监管报表全部仍由主柜台负责。极速柜台每天开市前从主柜台同步资金和持仓快照，盘中用自己的内存副本做风控校验，收市后把成交回报和余额变动同步回主柜台，由主柜台完成日终清算。两个系统各记一份账，权威以主柜台为准，极速柜台的内存账是缓存不是账本——这个关系必须时刻清楚，否则对账时谁都说不清哪个数是真的。
并存架构的一致性难题
双柜台并存带来三个工程问题。
快照时点的取舍。 开市前同步的余额快照，和开市后主柜台上发生的银证转账、其它渠道的委托，天然存在裂缝。客户在 App 上转钱进来，极速柜台不知道；极速柜台风控按旧快照校验，可能错误拒绝。解法通常是转账类业务限制：走极速柜台的账户，资金划转走专用通道实时同步，或干脆规定快速通道客户的钱必须通过指定入口进出。
成交回报的回传时序。 极速柜台成交后异步推给主柜台，中间有时间差。如果客户同时在两个通道都有委托，主柜台侧的可用余额计算会短暂失真。设计上把"极速通道的冻结/扣款"也做成事件流实时推给主柜台，两边用同一套事件驱动的余额模型，而不是各自读改写。这和前面讲过的"同一账户串行"是同一个问题在系统间的版本。
故障切换的边界。 极速柜台崩了，量化客户的委托停了——但客户资金状态停在内存里。切换回主柜台前必须把内存账对平：已报未回的委托状态、冻结的余额，要么落库要么作废，绝不能让两个柜台同时对同一账户记账。实务上的切换 SOP 是"先冻结账户交易 → 对平 → 放行"，宁可停几分钟，不要账乱。
给开发者的视角
面对一套券商交易系统时，先问三个问题就能定位任何功能的归属：这个操作碰不碰账务（碰就是主柜台的地盘）、延迟预算是多少（毫秒级预算走交易链路，秒级预算走异步任务）、监管要不要留痕（要留痕的不会出现在极速柜台里）。极速柜台的存在本身是个架构宣言：一致性、功能全集、低延迟，三者最多同时拿两个。主柜台选了前两个，极速柜台选了后两个加"寄生在主柜台上的一致性"——这不是妥协失败，是把两套约束拆到两个系统里，各自最优。