Architecture

设计目标

1. 支持每秒万笔以上的交易订单
2. 支持多种货币对的交易
3. 分布式集群架构，高可用服务

技术选型

传统的比特币交易所使用关系型数据库实现交易撮合引擎，好处是依赖数据的索引和事务等机制，可以方便快速的实现业务逻辑，并保证数据的准确性和可靠性，但带来的问题是数据库成为瓶颈，性能差。随着量化交易的发展，越来越多的交易是由程序执行的，大多数量化交易为高频交易，特点是订单数量很大，对交易接口延迟要求很高。传统的依赖于数据库的架构无法满足日益提升的交易需求，主流的交易所都面临着技术问题。为了突破数据库的性能瓶颈，我们使用单进程避免数据库事务和锁的开销，使用内存计算避免持久化的开销，放弃完全的持久化以带来性能的大幅提升。

交易所撮合引擎面临的问题本质上非常简单，按照顺序提交的交易订单，照价格优先，时间优先的顺序进行撮合交易，交易结果反映到用户账户的余额的变化上面。另外还有出入金等操作会影响用户账户余额。那么，根据同样的操作流水，最终结果必然是完全一样的。这和和 Redis 的 AOF 模式非常类似，本质上是一个内存数据库，依赖于操作日志进行数据恢复。另外，通过定期生成数据状态切片，这样重启服务时可以先加载切片数据，再加载切片数据之后的流水数据完成数据恢复，降低重启服务加载历史数据所需要的时间。

根据 Redis 的 Benchmark 来推算，单台写服务器完全可以支撑万笔以上的订单量。同属为了实现高可用的目标，撮合服务需要实现一主多备的集群，我们使用 Zookeeper 来实现集群服务的管理。另外，订单记录，交易记录，资金变化记录等需要使用数据库进行异步持久化存储。

整体架构

• 基础系统：Zookeeper 集群，kafka 集群，Redis Sentinel 集群, MySQL 集群
• 撮合模块：一主多从，读写分离
• 行情模块：生成 K 线数据
• 量化模块：给用户提供基本的策略交易
• HTTP接入：给内部系统提供HTTP接口
• WEBSOCKET 接口：给用户提供 WEBSOCKET 接口

第一期任务

不考虑高可用，实现单实例的撮合服务。