最近比特币势头很猛，已经超过5w美金，群里有人问了，这样高频的数字货币交易系统有哪些技术挑战呢？

比特币交易系统应该长这个样子：

挑战关键点应该是：

• 计算实时性（价格统计计算，根据排序展示）；

• 推送实时性（价格变化，实时感知）；

• 写操作高并发（买入卖出短线高频）；

先说计算的实时性，如果统计计算、排序完全基于DB操作，比如select sum(xx) from table group by xx，肯定会全表扫描，如果放缓存可能存在数据不一致，用户感知就有延迟，进而影响用户交易。

再就是推送问题，如果成交一笔才刷新推送，显然不行。

我们可以一步步抽象问题。

首先说推送，用http短连接肯定不现实，三次握手、四次挥手连接建立销毁成本太高，轮询也有延迟，好的方式就是长连接了，选型websocket或sse即可，性能好，降低服务端压力。

结合之前做网关和IM的经验，我们需要做到技术与业务分离，建立一个独立的长连接服务，专门做长连接维护和推送，也就是推送服务集群。这样如果客户端数量多，用户量变大，可以简单线性扩容推送集群提高推送能力。

由于推送服务主要做的就是长连接维护与推送，不做任何业务相关的逻辑，所以说推送服务所推送的数据理论上是已经计算好的了，不需要在推送服务集群进行处理了。

既然采用推模式，那么推送服务集群也是由“推”驱动的，方式是订阅一个MQ集群，一旦某个事件有新的计算结果了，推送集群进行消费，实现消息推送。

而计算逻辑在于后面的业务服务集群，和推送服务集群直接通过MQ解耦。

如何提高推送服务推送性能呢？

参考kafka的设计有两种方式，一个是多线程并行推送，一个是暂存批量发送，最好可以做成可配置的解决不同频次和实时性业务需求的推送。

我们再说下写操作高并发解决方案，其实逻辑差不多，用户操作以http短连接提交到业务后端服务，如果量大引入mq削峰填谷，如果不大可以直接落DB，由于这些交易流水比较重要，需要做持久化，方式就是按照着股票的Id做分库即可，水平扩容。

回到第一个问题就是统计计算与排序问题，这个问题应该是最难处理的了，直接读MySql必然不靠谱，慢查询必有，DB压力巨大。折中考虑是引入缓存，就是将时间窗口内的计算结果放入缓存当中，供前台服务调用。

我们可以通过异步线程，秒级从DB获取数据进行计算，将结果放入缓存中。有缓存必然有数据一致性问题，那究竟这个数据不一致窗口是多少就需要结合业务考虑了。比如可以考虑异步计算1s三次，推送三次，这样如果有延迟也就300ms吧，理论上不耽误交易。

我问了几个做交易所的架构师，思路基本是这样多级缓存，堆服务器。数据全在内存里做，upd组播消息总线，存储会考虑一些TIDB之类的或是自己基于Mysql做分区，类似于我们之前做的SET化方案，还没有上升到金融的MGR方式。

还有的交易系统的看盘数据，一级行情是6s推送一次，二级行情是3s推送一次。行情原始数据在内存，新行情数据来了之后，根据不同业务生成直接在内存计算。前端也会有一些设计，做一些规整diff计算之类的，我觉得和IM端处理差不多。

技术栈都想好了，推送服务websocket+netty，做好压缩，全内存数据存放，变化时推redis，多级缓存。我了解了下美股期权交易开盘峰值大概6w/s，堆100台4c8g的好像都可以了。

总的来说上面的方案对于大部分虚拟币交易所架构是比较普世的了，解决交易所的撮合、推送都不是问题，最重要的还是实时清算啊，这个有机会再聊。