matching_engine - GitLite

KO | EN

gitlite — search

#python #golang #go #android #deep-learning #linux #nodejs #windows #awesome #cli #awesome-list #pytorch #ios #mcp

matching_engine

(★ 475)

A simple financial trading matching engine. Built to learn more about how they work.

파일 탐색기

최종 버전 다운로드 (.zip)

- - main.go
- - main.go
  - tmain_test.go
- - main.go.disabled
- coordinator.go
- inmemory.go
- readwrite.go
- rmsg.go
- rmsg_serialise.go
- tbad_netwk_test.go
- test_util.go
- tinmemory_test.go
- trmsg_serialise_test.go
- reader.go
- - order.go
  - public_prioq.go
  - public_refprioq.go
  - rbtree.go
  - refprioq.go
  - slab.go
  - tprioq_test.go
- matcher.go
- tcompare_test.go
- tcoordinator_test.go
- testsuite.go
- tmatch_test.go
- trefmatcher_test.go
- maker.go
- msg.go
- serialise.go
- tmsg_test.go
- tserialise_test.go
- meddle_q.go
- meddlers.go
.gitignore
go.mod
go.sum
README.md

# 설치 가이드

1. 코드 내려받기

git clone https://github.com/fmstephe/matching_engine

깃허브에서 프로젝트 코드 전체를 내 컴퓨터로 내려받습니다.

cd matching_engine

방금 내려받은 프로젝트 폴더 안으로 이동합니다.

2. Go

보통 추천

사전 준비물

Git GitHub에서 프로젝트 코드를 내려받으려면 필요합니다.
Go Go 언어 컴파일러 및 도구 모음입니다.

go build ./...

Go 프로그램을 컴파일해 실행 파일을 만듭니다.

go run .

따로 빌드하지 않고 바로 Go 프로그램을 실행합니다.

✅ 빌드가 에러 없이 끝나면 성공입니다. go run . 을 썼다면 터미널 출력을 확인하세요.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# matching_engine
===============

A simple financial trading matching engine. Built to learn more about how they work.

This system is not a complete implementation of a full matching engine system. It contains a basic set of internal components for a matching engine but doesn't include any networking components which would be required to actually use it in production.

## msg

The `msg` package defines the basic messages which are processed by a matching engine. The system was designed to be _entirely_ driven by these messages, so we find both the expected buy/sell limit-order type messages as well as new-trader and shutdown messages which change the state of the matching engine without actually engaging it trading activity.

The rationale behind this choice was that the state of a matching engine should be determined _exclusively_ by the serise of messages which have passed through it. This allows us to perfectly reproduce any matching engine state simply by replaying these messages.

There is some initial work done on a binary serialisation format. This was intended to be used for storing messages in logs, and for sending over the network. I don't think the approach taken here was very well conceived, and I would probably use an efficient encoding library if I was to work on this now.

The `maker.go` file is interesting in that it generates random sets of buy/sell messages. While the code-base has many traditional run-code/assert-outcome style unit tests, we also employed a lot of system-invariant style tests with randomly generated test data.

## matcher/pqueue

This is a priority queue implementation custom built to support the matching engine. This is definitely the most complex piece of code in the system. The pqueue is a pair of linked red-black trees. The two trees share the nodes. Specifically an `OrderNode` is a member of two red-black trees, one tree is ordered by price and the other is ordered by the id of the order. A feature of having a single order object linked to two trees is that when we remove an `OrderNode` from one tree we can remove it from the other, without having to perform a search through the tree to find it.

The red-black tree is an internal detail the publicly exposed type is the `pqueue.MatchQueues` this is a trio of red-black trees, one for buys and one for sells and one for all orders sorted by guid. This exposes the operations needed to submit a buy, or sell order as well as cancel an existing order (using its guid).

The testing approach used here is primarily invariant based testing. We perform operations on the rb-trees and then test to ensure that the structural invariants of the trees has not been violated. In the development of these trees I first started with a body of hand-written operations, followed with assertions on the result. Even after writing a very large number of unit tests I was not able to find any bugs. However, when I built the randomly generated invariant based testing I was able to find a number of subtle bugs and fix them

If I did this now I would have kept the 'normal' style unit tests as well as the more complex invariant style tests. Although invariant testing was more valuable in finding bugs, the 'normal' style of unit tests are easy to read and are a useful form of documentation of the expected behaviour of the rb-trees.

## matcher

The matcher implements an actual matching engine. This uses a `pqueue.MatchQueues` to manage incoming orders. As each new order comes in an attempt is made to match the order, buy or sell, and the resulting matches are written to the output. Cancelling orders is supported, as-is shutting down the order book.

## coordinator

This package is designed to allow us to wrap a `matcher.M` with an input and output queue. There are two implementations available, one which uses a Go channel and one which uses an imported high performance queue. The queue imported is from another project I authored which can be found at `github.com/fmstephe/flib`.

I would not use this approach if I was building this system again today. I think that the choice to make the `matcher.M` struct embed the `coordinator.AppMsgHelper` interface is unnecessarily complicated.