USDC。超额抵押稳定币通过超额抵押其他加密货币而锻造，抵押品会被锁定在智能合约里，智能合约会根据抵押品的价值锻造出对应数量的稳定币，智能合约依靠价格预言机来维持与法币的锚定。此类型的稳定币主要以

的代码地址如下：https://github.com/Uniswap/v3-core/blob/main/contracts/libraries/Oracle.solObservation在

的时间窗口并非固定的，而是滑动的。这种算法的主要原理就是将时间窗口划分为多个时间片段，每过一个时间片段，时间窗口就会往右滑动一格，如下图所示：上图所示的时间窗口为

的人，则将得到奖金池里剩下的所有奖金，再没有任何损耗。场景分析为了有更直观的理解，我们代入一些具体场景分析下。我们先来看看第一个

只会从优质的数据聚合服务商获取数据，这意味着每个数据源都代表一个从所有中心化和去中心化交易所聚合的经过交易量调整的精细价格点，也因此可以有效抵抗闪电贷或价格异常偏差等攻击。第二层则是

就已经出现了不止一次长时间不出块的问题，每次都长达好几个小时。我们都知道，区块链不出块，那就什么都做不了了，无法交易，无法测试，只能干等网络恢复。这也可以算是接入

的实现机制其实很简单。首先，在配对合约里会存储三个相关变量：price0CumulativeLastprice1CumulativeLastblockTimestampLast前两个变量是两个

版本主要增加了几个支持交税费用的函数interfaces：接口都统一放在该目录下libraries：存放用到的几个库文件test：里面有几个测试用的合约examples：一些很有用的示例合约，包括

1000，该最小流动性会永久锁在零地址。这么做，主要还是为了安全，具体原因可以查看白皮书和官方文档的说明。如果不是提供最初流动性的话，那流动性则是取以下两个值中较小的那个：liquidity1

数量越多越好，所以，这些路径中，那条兑换结果数量最多的就能成为最优路径。有些人可能会陷入一个误区，觉得最优路径应该是最短路径，而实际上：最短路径不一定是最优路径。比如，ETH-WBTC

等，这些框架实现了服务发现、熔断等这些功能，从而开发人员使用较少的框架代码就可以将这些功能添加到服务中。这看上去很完美，但实际上存在几个比较致命的痛点：框架内容太多，学习门槛很高。

前言微服务架构背景下，随着服务和服务实例的数量不断增加，如果依然用传统的方式部署、配置和管理这些服务进程，就会发现，越来越多的时间花在了管理部署和解决部署过程中出现的问题上了。比如，需要新增服务实例进行扩容，服务器环境搭建就挺费时间的。另外，很多人肯定会经历过，同一份代码的程序在测试环境跑得好好的，但到了生产环境就出错了。部署上线的时候，大部分问题其实都是运行环境和配置问题，开发和运维就为了解决这些问题花费了很多时间。容器化就能很好地解决上面所说的问题。其实，虚拟机也是一种解决方案，但虚拟机相对来说太重了。容器则很轻量级，占用的资源也很少，启动又快。所以，无疑容器是解决微服务应用部署问题的更优选择。确切地说，虚拟机是为了实现在单个物理机上安装不同的操作系统，目的是操作系统级别的隔离；而容器则是为了实现在同一个操作系统中将不同的应用隔离开，目的是应用级别的隔离。那说到容器化技术，Docker

前言微服务架构下，会引入很多服务问题，所以少不了需要做服务治理，包括：服务注册与发现、服务配置、服务限流、服务熔断、服务降级、负载均衡、链路追踪等。关于服务治理的范畴应该包括哪些，业界其实也没有形成标准，但至少包括了前面列出来的内容，这是毋庸置疑的。另外，微服务架构下，服务集群规模会越来越大，服务治理也很难靠人工完成，因此，微服务治理的自动化程序要高。下面，我们就根据上面列举的内容，一一讲解每一块的服务治理如何实践。服务注册与发现在第三篇文章最后我们也有讲到注册中心，从

前言上一篇文章我们将整个交易系统进行了微服务化，拆分为了多个相互独立的业务组件，每个业务组件不只是包含自己业务的微服务，还包括了独立管理的数据库。那么，我们来考虑下单的场景，用户下委托单的时候，主要有三步操作：一是冻结金额，二是新增订单，三是投递给到撮合引擎。这三步需要保证事务的一致性。在服务和数据库都不拆分的情况下，是很容易满足的。但拆分之后，这几个步骤的操作也分开到不同业务组件了，服务是分开的，数据库也是分开的。在这种分布式的环境下，又要如何保证事务的一致性，这就是分布式事务问题了。那分布式事务问题都有哪些解决方案？怎么选型？如何落地？本篇文章我们就来一一解答这些问题。从

2PC、3PC，能够保证强一致性，但性能很差。大部分场景下的分布式事务其实对强一致性的要求不会太高，所以只要在一定时间内做到最终一致性就可以了。保证最终一致性的事务，称为柔性事务，其设计思想则是基于

也不同，如果设计得不好，依然会浪费资源，因此，有必要说明一下。首先，客户端与服务端建立连接之后，客户端需要什么数据，一般是通过发送订阅消息的方式通知服务端的，比如像这样：{

前言近几年，我在资产证券类交易系统领域做得比较多，从2016年开始，在贵金属交易领域深耕了两年，负责的交易平台用户量曾达到几百万，日活也有几十万，日流水更是千万级别。2018年之后，在数字资产交易行业又沉淀了两年，虽然用户量级没达到之前在贵金属交易平台的级别，但因为交易标的明显比在贵金属时多得多，所以整体的并发量和交易量却大得多。基于我这几年的经验总结，我将以数字资产交易平台为案例，聊聊从

欢迎关注「Keegan小钢」公众号获取更多文章价值超5万的撮合引擎：开篇价值超5万的撮合引擎：MVP版本撮合引擎开发：数据结构设计撮合引擎开发：对接黑箱撮合引擎开发：解密黑箱流程撮合引擎开发：流程的代码实现撮合引擎开发：缓存和MQ撮合引擎开发：日志输出本小节是该系列文章的最后一篇了，将讲解剩下的一些东西，包括交易委托账本中订单队列的实现逻辑、更多订单类型的实现逻辑。另外，不少朋友在问，完结后所有代码是否会开源放上

欢迎关注「Keegan小钢」公众号获取更多文章价值超5万的撮合引擎：开篇价值超5万的撮合引擎：MVP版本撮合引擎开发：数据结构设计撮合引擎开发：对接黑箱撮合引擎开发：解密黑箱流程撮合引擎开发：流程的代码实现撮合引擎开发：缓存和MQ日志需求我们都知道日志在一个程序中有着重要的作用，撮合引擎也同样需要一个完善的日志输出功能，以方便调试和查询数据。对一个撮合引擎来说，需要输出的日志主要有以下几类：1.程序启动的日志，包括连接

欢迎关注「Keegan小钢」公众号获取更多文章价值超5万的撮合引擎：开篇价值超5万的撮合引擎：MVP版本撮合引擎开发：数据结构设计撮合引擎开发：对接黑箱撮合引擎开发：解密黑箱流程撮合引擎开发：流程的代码实现中间件先来回顾下我们撮合程序项目中关于中间件的目录结构：├──

欢迎关注「Keegan小钢」公众号获取更多文章价值超5万的撮合引擎：开篇价值超5万的撮合引擎：MVP版本撮合引擎开发：数据结构设计撮合引擎开发：对接黑箱撮合引擎开发：解密黑箱流程程序入口我们要开始聊代码实现逻辑了，如果不记得之前讲的目录结构，请回去翻看前文。聊代码实现的第一步自然从程序入口开始，核心就两个函数：init()

价值超5万的撮合引擎：开篇价值超5万的撮合引擎：MVP版本撮合引擎开发：数据结构设计撮合引擎开发：对接黑箱业务流程前面的几篇文章已经陆续讲到了黑箱内部的一些设计，包括核心的软件结构、数据结构、目录结构等。而从本小节开始，我们将会更加深入，来解密黑箱内部的更多设计和实现细节。解密黑箱的第一步就是要清楚其内部对数据的处理流程是怎样的。当我们要设计一个新系统的时候，也是一样的，第一步要梳理清楚业务流程和数据流向。对撮合引擎来说，就是要了解：从输入到输出，中间都经过了哪些处理流程。前面的文章已经讲过，本撮合引擎定义了三种输入：开启撮合、处理订单、关闭撮合。后面就分别来看看这三种输入背后的流程。开启撮合开启撮合即是开启某个交易标的（交易对）的撮合引擎，未开启撮合的交易标的是无法处理订单的，而已经开启了撮合的交易标的也无法再次开启，不然就会出现同时有两个引擎处理同个交易标的的订单，这是不合理的，同个交易标的的订单只能由一个引擎串行来处理。为什么不能并行呢？如果同一交易标的的订单可以用多个引擎并行处理的话，那至少会产生几个问题：1.成交价以哪个为准？理论上，每一时刻只能有一个成交价，那并行之后，就会产生多个成交价，那成交价就难以确定了。2.如何维护统一的委托账本？理论上，每个交易标的有一本保存了所有委托单的委托账本，那并行之后，如何在多个引擎之间维护这个统一的账本呢？如果用数据库统一维护，那无疑会减低撮合性能；如果分为多个子账本，那就很难保证价格优先、时间优先的原则。以上这两个问题都不好解决，因此，只能先对所有订单进行定序，然后丢入引擎进行串行处理。说到定序，自然就需要一个定序队列，因此开启撮合时需要初始化对应交易标的的订单定序队列。初始化好定序队列后，就可以真正启动对应交易标的的引擎了。在

价值超5万的撮合引擎：开篇价值超5万的撮合引擎：MVP版本撮合引擎开发：数据结构设计黑箱引擎我们的撮合引擎作为一个相对通用的组件，其实就是一个黑箱，如果想将它应用到各种不同的交易系统，只要有标准的输入和输出，对接是很容易的。写作此文时的撮合引擎为

价值超5万的撮合引擎：开篇价值超5万的撮合引擎：MVP版本交易委托账本交易委托账本(OrderBook)是整个撮合引擎里最核心也是最复杂的数据结构，每个交易对都需要维护一份交易委托账本，账本里保存着指定交易对所有待撮合的委托单。每份账本都有两个队列，一个卖单队列和一个买单队列，两个队列都需要按照价格优先、时间优先的原则进行排序。所谓价格优先、时间优先，即是说：卖单队列的委托单是按价格由低到高排序，买单队列则相反，按价格由高到低排序；相同价格的委托单，则是按下单时间的先后来排序。如上图，每个小方格表示一个委托单，标

价值超5万的撮合引擎：开篇前言开篇文章发出去之后，我的撮合引擎被一位超级大佬（曾担任上交所的首席架构师）定位为玩具，直接将我的撮合引擎和国家级撮合引擎作对比了。如果我的撮合引擎达到上交所级别，那就不止值5万了，估计至少值500万了。不过，我的撮合引擎随着不断升级迭代，以后能达到国家级别也说不定。为了避免再次出现这种尴尬，我还是先说明清楚对此撮合引擎的定位。MVP版本需求《精益创业》有个核心概念叫

前言自从有人在微信群里开价5万求购Golang版的撮合引擎之后，我就想自己开发一款，毕竟，以我的经验来说，开发个高性能的撮合引擎并没什么难度。说干就干，于是，利用业余时间慢慢开发出了一款Golang版的高性能撮合引擎，前前后后花了大概一个月的时间。再想想自己好久没更新文章了，我的个人IP都已经生锈了，也应该发大招磨一磨了。因此决定，干脆就以连载的方式，分享下我是如何设计与实现这款价值超5万的撮合引擎的。本来，想发成掘金小册，收点稿费，毕竟这是个具有很大商业价值的软件，但问了掘金的人员，他们目前不接收这类主题。最终决定免费发布，还可以多发几个渠道，说不定还能给我多带来些关注量。好了，下面开始进入撮合引擎系列的正题。撮合引擎简介撮合引擎是所有撮合交易系统的核心组件，不管是股票交易系统——包括现货交易、期货交易、期权交易等，还是数字货币交易系统——包括币币交易、合约交易、杠杆交易等，以及各种不同的贵金属交易系统、大宗商品交易系统等，虽然各种不同交易系统的交易标的不同，但只要都是采用撮合交易模式，都离不开撮合引擎。撮合引擎是可以具有通用性的，一套具有通用性的撮合引擎实现理论上可以应用到任何撮合交易系统中，而无需做任何代码上的调整。即是说，同一套撮合引擎实现，既可以应用在股票交易系统，也可以应用在数字货币交易系统，可以用于现货交易，也可以用于合约交易等。那么，一套具有通用性的撮合引擎应该具备哪些功能呢？确定该问题的答案之前，我们先简单梳理一下一个完整的交易流程是怎样的？一般会包括以下步骤：1.系统开放某个交易标的的交易功能。2.用户提交该交易标的的买卖申报，即委托单。3.系统验证委托单是否有效，包括交易标的是否处于可交易的状态、订单的价格和数量是否符合要求等。4.确定该委托单的挂单(Maker)费率和吃单(Taker)费率。5.检查用户的资产账户情况，包括账户状态是否交易受限，是否有足够资金用于下单等。6.将详细的委托单数据持久化到数据库，并冻结用户账户中相应数量的资金。7.将委托单进行撮合处理，即在交易委托账本(OrderBook)中寻找能与该委托单匹配成交的订单，匹配的结果可能是：全部成交、部分成交或无匹配。全部成交或部分成交时，可能在交易委托账本中存在一个或多个匹配的订单，即会产生一条或多条成交记录。当无匹配或部分成交时，委托单的部分数据包括剩余未成交的数量会暂时保存到交易委托账本中，等待与后续的委托单匹配撮合。8.将撮合产生的成交记录持久化到数据库，并根据历史成交记录生成市场数据，如K线数据、今日涨跌幅等。9.更新数据库中所有成交订单的委托单数据，以及更新订单用户的资产账户余额。10.将更新的订单数据、市场数据等发送给到前台。整个交易流程中涉及到多个服务，包括用户服务、账户服务、订单服务、撮合服务、市场数据服务等。其中，只有第7步是撮合引擎处理的。从单一职责原则来说，撮合引擎就应该只做一件事，那就是负责撮合订单。撮合之前的委托单持久化、冻结资金等，以及撮合之后生成K线数据等，都不应该属于撮合引擎的职责。撮合竞价方式撮合竞价方式一般有两种，一是集合竞价，二是连续竞价。股票交易系统一般会在不同交易时间段采用不同的竞价方式，比如在开盘或收盘时采用集合竞价，从而产生开盘价或收盘价，其余时间采用连续竞价。而大多数字货币交易系统则没有集合竞价，只有连续竞价，开盘价一般是在开始交易之前就设定好的。集合竞价所谓集合竞价，是指对一段时间内接收的买卖委托单一次性集中撮合的竞价方式。以深沪的股票交易系统为例，在每个交易日的