order queue

The transaction order book is actually composed of two order queues, a buy order queue and a sell order queue. Any query and operation on the transaction delegation ledger is actually the two queues of query and operation. The design of the order queue also directly affects the performance of the matchmaking. The previous article also briefly talked about the design of the order queue when talking about the data structure design. We mainly use two-dimensional links combined with Map to save all orders, relying on the container/list package. .

The structure of the order queue is as follows:

type orderQueue struct {
    sortBy enum.SortDirection
    parentList *list.List
    elementMap map[string]*list.Element
}

sortBy specifies the direction of price sorting, the queue for buy orders is in descending order, and the queue for sell orders is in ascending order. parentList holds all orders of the entire two-dimensional linked list, the first dimension is sorted by price, and the second dimension is sorted by time. elementMap is a key-value pair where Key is the price and Value is the second-dimensional order list.

The initialization function is relatively simple. It only assigns values to several fields. The code is as follows:

func (q *orderQueue) init(sortBy enum. SortDirection) {
    q.sortBy = sortBy
    q.parentList = list.New()
    q.elementMap = make(map[string]*list.Element)
}

In addition to the initialization function, five other functions are provided:

• addOrder(order): add an order

• getHeadOrder(): Read the head order

• popHeadOrder(): read and delete the head order

• removeOrder(order): remove order

• getDepthPrice(depth): read depth price

Only the first function of the above five functions will be more complicated. In order to make the processing flow easier to understand, I will not post the code and draw a complete flow chart for everyone to see:

!Picture

This process is indeed a bit complicated, you can read it several times to digest it well, and it is best to convert it into code by yourself.

The other functions are simple, and the last function needs to be explained. The purpose of reading the depth price is to facilitate the determination of the upper limit price when processing orders of market-opponent, market-top5, market-top10 and other types. Please see the code of the function to understand the logic and usage of the function:

func (q *orderQueue) getDepthPrice(depth int) (string, int) {
    if q.parentList.Len() == 0 {
        return "", 0
    }
    p := q.parentList.Front()
    i := 1
    for ; i < depth; i++ {
        t := p.Next()
        if t != nil {
            p = t
        } else {
            break;
        }
    }
    o := p.Value.(*list.List).Front().Value.(*Order)
    return o.Price.String(), i
}

Multiple order types

Our engine supports a total of six types of orders. The previous articles have briefly introduced them, but they have not explained in depth what the specific business logic of these different types should be. Therefore, this part is supplemented here.

1. limit The ordinary price limit is the simplest, and the code implementation has been shown in the previous article

The processing logic is:

1. Determine whether the new order is a buy order or a sell order.
2. If it is a buy order, read the head sell order from the OrderBook, that is, the head order in the sell order queue; if it is a sell order, read the head buy order from the OrderBook, that is, the head order in the buy order queue.
3. When the new order is a buy order, if the head order is empty, or the new order is smaller than the head order, that is, the transaction cannot be executed, then the new order will be added to the buy order queue, and the processing will end; when the new order is a sell order, if the head order is If the order is empty, or the new order is larger than the head order, that is, the transaction cannot be executed, then the new order is added to the sell order queue, and the processing ends.
4. Otherwise, if the matching conditions are met, the new order and the top order will be matched and traded.
5. After the matching is completed, if the remaining quantity of the new order is zero, it will end. If it is still greater than zero, go back to step 2 and continue to take the next head order, and so on.

1. limit-ioc There is only one difference between the IOC limit price and the ordinary limit price. If the new order does not match the head order, the ordinary limit price will be added to the order queue, while the IOC limit price will be processed as cancellation.

2. market The logic of the default market order is also relatively simple, it does not need to judge the price, as long as the head order is not empty, it will directly match the head order.

3. market-top5/market-top10 The logic of the optimal fifth/tenth market order is similar to that of the default market order. The difference is that the transaction price of the default market price has no upper limit or lower limit, but the optimal fifth/tenth market price has a price upper limit or lower limit. Orders with upper and lower limits will not be filled. Drawing is too tiring, let’s just paste the code directly. The following is the processing of the purchase order:

func dealBuyMarketTop(order *Order, book *orderBook, lastTradePrice *decimal.Decimal, depth int) {
    priceStr, _ := book.getSellDepthPrice(depth)
    if priceStr == "" {
        cancelOrder(order)
        return
    }
    limitPrice, _ := decimal.NewFromString(priceStr)
LOOP:
    headOrder := book.getHeadSellOrder()
    if headOrder != nil && limitPrice.GreaterThanOrEqual(headOrder.Price) {
        matchTrade(headOrder, order, book, lastTradePrice)
        if order.Amount.IsPositive() {
            goto LOOP
        }
    } else {
        cancelOrder(order)
    }
}

1. market-opponent The last type, the counterparty’s best price, this type only deals with the counterparty’s tier one price, but it’s a little different from the best 5th/10th tier: the untraded part of the best 5th/10th tier is For canceled orders, the last unfilled part of the counterparty's best price is converted to a limit order. Please see the code:

func dealBuyMarketOpponent(order *Order, book *orderBook, lastTradePrice *decimal.Decimal) {
    priceStr, _ := book.getSellDepthPrice(1)
    if priceStr == "" {
        cancelOrder(order)
        return
    }
    limitPrice, _ := decimal.NewFromString(priceStr)
LOOP:
    headOrder := book.getHeadSellOrder()
    if headOrder != nil && limitPrice.GreaterThanOrEqual(headOrder.Price) {
        matchTrade(headOrder, order, book, lastTradePrice)
        if order.Amount.IsPositive() {
            goto LOOP
        }
    } else {
        order.Price = limitPrice
        order.Type = enum.TypeLimit
        book.addBuyOrder(order)
        cache.UpdateOrder(order.ToMap())
        log.Info("engine %s, a order has added to the orderbook: %s", order.Symbol, order.ToJson())
    }
}

end

At this point, the whole series is over. However, my matchmaking program will continue to be iteratively upgraded. In addition, other components will also be developed, which will be used in conjunction with the current matchmaking engine. Welcome to follow-up news.

This article partly refers to the idea of this project：

https://github.com/jammy928/CoinExchange_CryptoExchange_Java

We all know that logs play an important role in a program, and the matching engine also needs a complete log output function to facilitate debugging and data query.

For a matching engine, the logs that need to be output mainly include the following categories:

1. The log of program startup, including the log of successful connection to Redis and the log of successful startup of Web service;

2. Logs of interface request and response data;

3. The log of an engine is started;

4. The log of an engine is closed;

5. The order is added to the log of orderBook;

6. The log of transaction records;

7. Log of cancellation results.

In addition, the matching engine will generate a lot of logs, so log segmentation should also be done. Splitting by date is the most commonly used log splitting method, so we also divide logs of different dates into different log files for preservation.

Implementation ideas

First of all, we all know that logs are divided into levels. For example, log4j defines 8 levels of logs. However, there are 4 most commonly used levels, with priority from low to high: DEBUG, INFO, WARN, ERROR. Generally, different environments will set different log levels. For example, the DEBUG level is generally only set in the development and test environments, and the production environment will be set to INFO or higher. When set to high level, low level log messages are not printed. In order to print different levels of log messages, you can provide different levels of printing functions, such as log.Debug(), log.Info() and other functions.

Secondly, the log needs to be output to a file for saving, so it is necessary to specify the directory, file name and file object for the file to be saved. Generally, the saved file directory and the running program should be put together, so the specified file directory should preferably be a relative path.

In addition, the file should be divided according to the date, that is, the log messages of different dates should be saved to different log files, so naturally, the date of the current log should be recorded. And it needs to be monitored regularly. When it is detected that the latest date has crossed the date compared with the current log date, it means that the log needs to be split, then the current log file is backed up, and a new file is created to save the log of the new date. information.

Finally, if log messages are written to files, time-consuming I/O operations are indispensable. If the log is written synchronously, it will undoubtedly reduce the matching performance. Therefore, it is better to write the log asynchronously, which can be implemented by a buffered channel. .

Code

I re-customized a log package and created the log.go file where all the code is written.

The first step is to define several log levels and directly define them as enumeration types, as follows:

type LEVEL byte

const (
    DEBUG LEVEL = iota
    INFO
    WARN
    ERROR
)

The second step is to define the structure of the log, which contains many fields, as follows:

type FileLogger struct {
    fileDir string // Directory where log files are saved
    fileName string // log file name (no need to include date and extension)
    prefix string // prefix for log messages
    logLevel LEVEL // log level
    logFile *os.File // log file
    date *time.Time // log current date
    lg *log.Logger // system log object
    mu *sync.RWMutex // Read-write lock, which needs to be locked during log splitting and log writing
    logChan chan string // log message channel for asynchronous log writing
    stopTickerChan chan bool // stop the channel of the timer
}

The third step, in order to apply the log to any place in the program, it is necessary to define a global log object and initialize the log object. The initialization operation is a bit complicated, let's look at the code first:

const DATE_FORMAT = "2006-01-02"

var fileLog *FileLogger

func Init(fileDir, fileName, prefix, level string) error {
    CloseLogger()

    f := &FileLogger{
        fileDir: fileDir,
        fileName: fileName,
        prefix: prefix,
        mu: new(sync.RWMutex),
        logChan: make(chan string, 5000),
        stopTikerChan: make(chan bool, 1),
    }
    
    switch strings.ToUpper(level) {
    case "DEBUG":
        f.logLevel = DEBUG
    case "WARN":
        f.logLevel = WARN
    case "ERROR":
        f.logLevel = ERROR
    default:
        f.logLevel = INFO
    }
    
    t, _ := time.Parse(DATE_FORMAT, time.Now().Format(DATE_FORMAT))
    f.date = &t
    
    f.isExistOrCreateFileDir()
    
    fullFileName := filepath.Join(f.fileDir, f.fileName+".log")
    file, err := os.OpenFile(fullFileName, os.O_RDWR|os.O_APPEND|os.O_CREATE, 0666)
    if err != nil {
        return err
    }
    f.logFile = file
    
    f.lg = log.New(f.logFile, prefix, log.LstdFlags|log.Lmicroseconds)
    
    go f.logWriter()
    go f.fileMonitor()
    
    fileLogger = f
    
    return nil
}

The logic of this initialization is a bit too much, so let me split it up. First of all, the first step is to call the CloseLogger() function, which mainly closes files, closes channels, and other operations. To stop a constantly looping goroutine, closing the channel is a common solution, which was also mentioned in the previous article. Then, since the initialization function can be called multiple times to implement configuration changes, if the old goroutine is not terminated first, more than one goroutine with the same function will run at the same time, which will undoubtedly cause problems. Therefore, you need to close the Logger first. The code to close the Logger is as follows:

func CloseLogger() {
    if fileLogger != nil {
        fileLogger.stopTikerChan <- true
        close(fileLogger.stopTikerChan)
        close(fileLogger.logChan)
        fileLogger.lg = nil
        fileLogger.logFile.Close()
    }
}

After the Logger is closed, some fields are initialized and assigned. Among them, f.date is set to the current date, and the later judgment is based on this date. f.isExistOrCreateFileDir() will judge whether the log directory exists, and if not, it will be created. Next, concatenate the directory, the set filename, and the added .log file extension, concatenate the full name of the file, and open the file. After that, the file is used to initialize the system log object f.lg. When the log message is written to the file, the Output() function of the object is actually called. Two goroutines are started later: one is used to monitor logChan to write log messages into files; the other is used to regularly monitor whether the file needs to be divided, and when it needs to be divided, it will be divided.

Next, let's take a look at the implementation of these two goroutines:

func (f *FileLogger) logWriter() {
    defer func() { recover() }()

    for {
        str, ok := <-f.logChan
        if !ok {
            return
        }
    
        f.mu.RLock()
        f.lg.Output(2, str)
        f.mu.RUnlock()
    }
}

func (f *FileLogger) fileMonitor() {
    defer func() { recover() }()
    ticker := time.NewTicker(30 * time.Second)
    defer ticker.Stop()
    for {
        select {
        case <-ticker.C:
            if f.isMustSplit() {
                if err := f.split(); err != nil {
                    Error("Log split error: %v\n", err)
                }
            }
        case <-f.stopTikerChan:
            return
        }
    }
}

You can see that the logWriter() loop reads log messages from the logChan channel, and exits when the channel is closed, otherwise it calls f.lg.Output() to output the log. In fileMonitor(), a ticker is created that is sent every 30 seconds. When data is received from ticker.C, it is judged whether it needs to be split, and if so, the split function f.split() is called. And when data is received from f.stopTikerChan, it means that the timer will also end.

Next, let's look at the isMustSplit() and split() functions. isMustSplit() is very simple, just two lines of code, as follows:

func (f *FileLogger) isMustSplit() bool {
    t, _ := time.Parse(DATE_FORMAT, time.Now().Format(DATE_FORMAT))
    return t.After(f.date)
}

split() is a bit more complicated. First, add a write lock to the log to avoid log writing during splitting, then rename and backup the current log file, and then generate a new file to record new log messages. The current global log object points to the new file, new date, and new syslog object. The implementation code is as follows:

func (f *FileLogger) split() error {
    f.mu.Lock()
    defer f.mu.Unlock()

    logFile := filepath.Join(f.fileDir, f.fileName)
    logFileBak := logFile + "-" + f.date.Format(DATE_FORMAT) + ".log"
    
    iff.logFile != nil {
        f.logFile.Close()
    }
    
    err := os.Rename(logFile, logFileBak)
    if err != nil {
        return err
    }
    
    t, _ := time.Parse(DATE_FORMAT, time.Now().Format(DATE_FORMAT))
    f.date = &t
    
    f.logFile, err = os.OpenFile(logFile, os.O_RDWR|os.O_APPEND|os.O_CREATE, 0666)
    if err != nil {
        return err
    }
    
    f.lg = log.New(f.logFile, f.prefix, log.LstdFlags|log.Lmicroseconds)
    
    return nil
}

Finally, it is left to define some functions that receive log messages. The implementation is very simple. Take Info() as an example:

func Info(format string, v ...interface{}) {
    _, file, line, _ := runtime.Caller(1)
    if fileLogger.logLevel <= INFO {
        fileLogger.logChan <- fmt.Sprintf("[%v:%v]", filepath.Base(file), line) + fmt.Sprintf("[INFO]"+format, v...)
    }
}

Debug(), Warn(), Error() and other functions are similar, just follow the cat and draw the tiger.

At this point, our log package that can split log files by date is complete. For the rest, just call the corresponding log level function where the log output needs to be added.

Summary

The core of this summary is to add a general log package, which can be used not only in our matching engine, but also in other projects. If you expand it, you can also split by other criteria, such as split by hour, or split by file size. Those who are interested can try it out for themselves. ```

Let's first review the directory structure of middleware in our matching program project:

├── middleware # middleware package
│ ├── cache # cache package
│ │ └── cache.go # Cache operation
│ ├── mq # message queue package
│ │ └── mq.go # MQ operation
│ └── redis.go # Mainly for Redis initialization

Although only one middleware of Redis is used now, designing a middleware package will facilitate adding other middleware such as Kafka or RocketMQ in the future.

Then subcontract the cache and message queue, the responsibilities are very clear, and the application is also very clear.

redis.go just does the initial connection, let's take a look at the code:

package middleware

import (
    "matching/log"

    "github.com/go-redis/redis"
    "github.com/spf13/viper"
)

var RedisClient *redis.Client

funcInit() {
    addr := viper.GetString("redis.addr")
    RedisClient = redis.NewClient(&redis.Options{
        Addr: addr,
        Password: "", // no password set
        DB: 0, // use default DB
    })

    _, err := RedisClient.Ping().Result()
    if err != nil {
        panic(err)
    } else {
        log.Printf("Connected to redis: %s", addr)
    }
}

Among them, viper is the third-party configuration library mentioned above. Through viper.GetString("redis.addr"), the address of the Redis to be connected is read from the configuration file, and then a new Redis client is created and connected to the Redis server. .

Cache design

When talking about data structure design, we have already said that there are two main purposes of using caches:

1. Request deduplication to avoid repeating the submission of the same order;

2. Restore data, that is, all data can be restored after the program is restarted.

Remember when the last article talked about the implementation of Dispatch, there is a logic to determine whether the order exists? It is to read whether the order already exists in the cache, so as to determine whether it is a repeated request or an invalid request. And, remember the initialization of the process package? It is the process of restoring data from the cache.

Let’s first understand what data we cache in total:

• Open the symbol of the matched transaction target;

• the latest prices of these trading subjects;

All valid order requests, including order placement and cancellation requests.

1. Cache symbols

There will be multiple symbols of the transaction target for matching, and they cannot be repeated. In fact, they can be saved as a collection set type. I designed the key of this set as matching:symbols, and after that, whenever a symbol is matched, I can use Redis's sadd command to add the symbol to this set. When closing the matching, you need to use the srem command to remove the symbol that closed the matching from the collection. To read all symbols, use the smembers command.

The operation of symbols in the program provides three functions, which are used to save symbols, remove symbols and get all symbols. The following is the implemented code:

func SaveSymbol(symbol string) {
    key := "matching:symbols"
    RedisClient.SAdd(key, symbol)
}

func RemoveSymbol(symbol string) {
    key := "matching:symbols"
    RedisClient.SRem(key, symbol)
}

func GetSymbols() []string {
    key := "matching:symbols"
    return RedisClient.SMembers(key).Val()
}

2. Cache price

The latest price of the transaction target is that each symbol will have a price, and there is no need to cache the historical price, then I will directly use the string type to save the price, and the key of each price contains its own symbol and key format design It is matching:price:{symbol}. If the symbol to be saved = "BTCUSD", the corresponding key value is matching:price:BTCUSD, and the saved value is the latest price of BTCUSD.

We also provide three functions to save the price, get the price and delete the price. The codes are as follows:

func SavePrice(symbol string, price decimal.Decimal) {
    key := "matching:price:" + symbol
    RedisClient.Set(key, price.String(), 0)
}

func GetPrice(symbol string) decimal.Decimal {
    key := "matching:price:" + symbol
    priceStr := RedisClient.Get(key).Val()
    result, err := decimal.NewFromString(priceStr)
    if err != nil {
        result = decimal.Zero
    }
    return result
}

func RemovePrice(symbol string) {
    key := "matching:price:" + symbol
    RedisClient.Del(key)
}

3. Cache order

The cache design for orders is not so simple, and two requirements need to be met:

1. It can cache both the order placing request and the order cancellation request;

2. Orders are subject to sequencing requirements.

Let’s talk about the first point first, why do you need to cache orders? And why do both order placement and order cancellation requests need to be cached?

Let’s answer the first question first. We match in memory. Each transaction target engine maintains a transaction entrustment ledger. When the program runs, these ledgers are directly stored in the program memory. Then if the program exits, these ledgers are emptied. If there is no cache, the ledger data cannot be restored after the program restarts. To meet this requirement, all orders in the ledger need to be cached.

Regarding the second question, let's consider such a scenario: if there is an order cancellation request queued in the order channel, and the program does not cache the cancellation request, then the program restarts, then all the orders in the order channel have not yet It is emptied before it is received and processed by the engine, and the cancellation request cannot be recovered.

Therefore, the program needs to cache the order, and the order and cancellation need to be cached.

Let's look at the second requirement, why should it meet the sequence? We know that the orders in the order channel are ordered, and the orders of the same price in the transaction order book are also ordered by time. If the order is not sequenced during the cache, it is difficult to ensure that the order is restored in the original order after the program is restarted.

So how to design the cache of this order? My solution is to divide into two types of caches. The first type saves each individual order request, including order placement and cancellation; the second type of sub-transaction object saves the order ID and action of all order requests corresponding to the symbol.

For the first category, the Key format I designed is matching:order:{symbol}:{orderId}:{action}, and symbol, orderId and action are the three variable values corresponding to the order. For example, if an order symbol = "BTCUSD", orderId = "12345", and action = "cancel", the key value of the order saved to Redis is matching:order:BTCUSD:12345:cancel. The Value corresponding to the Key is to save the entire order object, which can be stored in the hash type.

For the second type, the Key format I designed is matching:orderids:{symbol}, and the Value stores data of the sorted set type, saving all order requests corresponding to the symbol, and the value stored in each record is {orderId}:{action} , and the score value is set to the {timestamp} of the corresponding order. The ordering can be guaranteed by using the order time as the score. Remember in the previous article that we set the unit of order time to 100 nanoseconds to ensure that the timestamp length is exactly 16 bits? This is because if it exceeds 16 bits, the score will be converted to scientific notation, which will lead to digital distortion.

According to this design, the implementation logic when saving the order is shown in the following code:

func SaveOrder(order map[string]interface{}) {
    symbol := order["symbol"].(string)
    orderId := order["orderId"].(string)
    timestamp := order["timestamp"].(float64)
    action := order["action"].(string)

    key := "matching:order:" + symbol + ":" + orderId + ":" + action
    RedisClient.HMSet(key, order)

    key = "matching:orderids:" + symbol
    z := &redis.Z{
        Score: timestamp,
        Member: orderId + ":" + action,
    }
    RedisClient.ZAdd(key, z)
}

In addition, functions such as GetOrder(), UpdateOrder(), RemoveOrder(), OrderExist(), GetOrderIdsWithAction() are provided. Let's show you the implementation of the GetOrderIdsWithAction() function:

func GetOrderIdsWithAction(symbol string) []string {
    key := "matching:orderids:" + symbol
    return RedisClient.ZRange(key, 0, -1).Val()
}

The results obtained by this function are sorted according to the score value, which is what we want. After understanding the design, go back and look at the initialization of the process package, and you will understand the logic of those codes.

MQ design

We chose to use the Stream data structure of Redis as the MQ output. The Stream data structure adopts a design similar to Kafka, which is very convenient to apply. But because Redis runs in memory, it is much faster than Kafka, which is the main reason why I choose it as the output MQ of the matching program.

We only have two types of MQs, order cancellation results and transaction records. The implementation of sending messages is as follows:

func SendCancelResult(symbol, orderId string, ok bool) {
    values := map[string]interface{}{"orderId": orderId, "ok": ok}
    a := &redis.XAddArgs{
        Stream: "matchi
        ng:cancelresults:" + symbol,
         MaxLenApprox: 1000,
         Values: values,
     }
     RedisClient.XAdd(a)
}

func SendTrade(symbol string, trade map[string]interface{}) {
     a := &redis.XAddArgs{
         Stream: "matching:trades:" + symbol,
         MaxLenApprox: 1000,
         Values: trade,
     }
     RedisClient.XAdd(a)
}

Among them, matching:cancelresults:{symbol} is the Key of the MQ of the cancellation result, and matching:trades:{symbol} is the Key of the MQ of the transaction record. It can be seen that we also divide different MQs according to different symbols, which also facilitates downstream services to implement distributed subscriptions to MQs of different symbols as needed.

Summary

This section explains the design and implementation of cache and MQ. After understanding the design of this part, you can basically understand the core design of the entire matching engine.

Finally, there are still a few thinking questions: Is it possible to not use the cache? How to solve the problem of deduplication and data recovery without caching? ```

The previous articles have talked about some of the internal designs of the black box, including the core software structure, data structure, directory structure, etc. From this section, we will go deeper and decipher more design and implementation details inside the black box.

The first step in decrypting the black box is to know what the internal data processing process is. When we want to design a new system, the same is true. The first step is to sort out the business process and data flow. For the matching engine, it is necessary to understand: From input to output, what processing processes have passed through the middle.

As mentioned in the previous article, this matching engine defines three types of inputs: Open matching, process orders, and close matching. Let's take a look at the process behind these three inputs separately.

Enable matchmaking

Opening a matching is to open the matching engine of a certain transaction target (trading pair). The transaction target that has not been matched cannot process the order, and the transaction target that has been matched cannot be opened again. Otherwise, there will be two at the same time. It is unreasonable for the engine to process orders for the same transaction target. Orders for the same transaction target can only be processed serially by one engine.

Why can't it be done in parallel? If orders for the same transaction object can be processed in parallel by multiple engines, at least a few problems will arise:

1.**Which is the transaction price? **Theoretically, there can only be one transaction price at each moment. After parallelization, multiple transaction prices will be generated, and the transaction price will be difficult to determine. 2.**How to maintain a unified entrusted ledger? **Theoretically, each transaction target has an entrustment ledger that saves all orders. After parallelization, how to maintain this unified ledger among multiple engines? If the database is maintained uniformly, it will undoubtedly reduce the matching performance; if it is divided into multiple sub-ledgers, it is difficult to guarantee the principle of price priority and time priority.

Both of the above problems are not easy to solve, so all orders can only be sequenced first and then thrown into the engine for serial processing.

When it comes to sequencing, a sequencing queue is naturally required, so when matching is enabled, the order sequencing queue corresponding to the transaction target needs to be initialized. After initializing the sequencing queue, you can actually start the engine corresponding to the transaction target. In a Go program, the engine of each transaction target runs as an independent goroutine; in other languages, such as Java, it runs as an independent thread.

After the engine is started, the transaction order book needs to be initialized to save the order. Then wait for the ordering queue to have orders taken out one by one for processing.

Also, consider another scenario, what happens when the matchmaking program restarts? Does it need to be restored after restarting the transaction target that has been matched? If necessary, how to restore it? The simplest solution is of course to use a cache, use Redis to cache the transaction targets that have been matched, and then load and reopen these transaction targets from Redis when restarting.

Therefore, there are actually two scenarios for triggering matchmaking. One is triggered by the active call of the interface, and the other is automatically loaded and started from the Redis cache after the program restarts.

Finally, the result of enabling matching is returned synchronously, so it has no asynchronous output.

To sum up, the internal process of opening matchmaking is roughly as follows:

Process the order

Once matchmaking is enabled, you can receive input for processing orders. When the matching program receives a request to process an order, the first step needs to do some checks, including whether each parameter is valid, whether the order is repeated or exists, whether the engine corresponding to the transaction target has been opened, etc. After passing the check, the entire order can be cached in Redis, and then added to the ordering queue corresponding to the transaction target, waiting for the engine corresponding to the transaction target to consume it for matching processing. The process is as follows:

When the order is successfully added to the sequencing queue, the interface can synchronously return a successful response result. Subsequent processing results are output through asynchronous MQ. After the engine of the transaction target receives the order, it will produce different output results according to different situations.

We know that there are two types of action for processing an order: Place an order and Cancel an order. The business logic of order cancellation is very simple. It is to query whether the order exists in the transaction entrustment ledger. If it exists, delete the order from the entrusted ledger, and then output the order cancellation result of successful order cancellation; if it does not exist, output the order cancellation failure. Cancellation result. The business logic of placing an order is more complicated, and it needs to be processed differently according to different order types. The matchmaker version at the time of writing supports 6 different types, including two limit price types and four market price types. The following will explain the results of placing orders of different order types under different conditions.

•limit: ordinary limit price. When there is an order in the order book that can match the order, one or more transaction records may be generated, and each transaction record will generate an asynchronous output; when there is no matching order in the order book, it will be The order (full quantity or remaining quantity) is added to the order book, at which point no output is produced. •limit-ioc: IOC limit price - immediate transaction remaining cancellation. When there is an order in the order book that can match the order, one or more transaction records may be generated, and each transaction record will generate an asynchronous output; when there is no matching order in the order book, it will be The order (all or the remaining quantity) is processed for cancellation, and an output of successful cancellation will be generated at this time. •market: Default market price - immediate transaction remaining cancellation. Like the IOC price limit, when there is an order in the order queue in the opposite direction of the order (also called the counterparty) in the order book, one or more transaction records may be generated, and each transaction record will generate an asynchronous output; When the counterparty does not have an order in the order book, the order (all or the remaining quantity) will be cancelled, and an order cancellation success will be output. The difference from the IOC limit order is that the IOC limit order is specified by the user with the order price, while the market price does not need to specify the order price, and will be directly filled with the counterparty's head order until the order has been fully filled or the counterparty Until there are no more orders. •market-top5: market price - the best five levels of immediate transaction remaining cancellation. The market can be filled with orders of all price levels of the counterparty, but market-top5 can only be filled with orders within five price levels of the counterparty at most, and orders beyond the five levels will not be filled. The remaining unsettled orders will be cancelled and an output of successful cancellation will be generated. •market-top10: market price - the best ten levels of instant transaction remaining cancellation. At most, it will only trade with orders within ten price levels of the counterparty. •market-opponent: market price - the best price of the counterparty. If the counterparty does not have an order, the order will be cancelled directly and an output of successful cancellation will be generated; if the counterparty has an order, it will only be traded one level at most. The price of the counterparty's first tranche is converted into a limit order and added to the order book, and no output will be generated at this time.

In addition, every request to process an order—whether it’s placing an order or canceling an order—will also be cached in Redis, and the cache will be updated when changes are made. In this way, the order can be resumed after the program restarts.

close matchmaking

When a transaction target is ready to be delisted, or the transaction is cancelled, or the transaction is suspended, the engine needs to be shut down. Before shutting down the engine, it is best for upstream services to stop calling the interface for processing orders, otherwise some unexpected errors may occur, although the program has already done fault-tolerant processing.

When closing the engine, there are also some simple judgments, such as judging whether the engine of the transaction target has been opened, and the engine that is not opened naturally cannot be closed.

When shutting down the engine, if there are still unprocessed orders in the sequencing queue, it should wait for these orders to be processed before actually shutting down the engine.

Finally, clear the cache as well, and clear all orders for the subject of the transaction from the cache.

The result of shutting down the engine is also returned synchronously, and there is no asynchronous output.

Summary

This section explains the core business process inside the matching black box, including the internal logic of the three inputs of opening matching, processing orders, and closing matching. After understanding these processes, we will start to talk about the code implementation in the next article.

It is customary to leave a few thinking questions: if there are concurrent requests for placing orders while the matching is closed, is it easy to cause problems? If so, where will it be generated? what is the problem? How can it be solved?

As a relatively common component, our matching engine is actually a black box. If you want to apply it to various trading systems, as long as there are standard inputs and outputs, it is easy to connect.

The matching engine at the time of writing this article is version 1.3. I compiled it into an executable file that can run in the Linux amd64 environment, and compressed it into a compressed package matching.zip together with the dependent configuration files. This becomes a black box engine.

However, in addition to the requirements for the running system, the black box engine also has requirements for Redis. Redis is required to be at least version 5.0 due to the use of Redis's new MQ feature, the stream data structure.

Actually, I can also compile executables built into other system environments, such as Windows or Mac systems. But as a commercial software and some performance requirements, it is more suitable to run in a Linux environment.

Later, let's take a look. If you want to apply this black box engine to your own trading system, how to connect it?

Install and deploy

The system environment for installation and deployment needs to be Linux amd64. In addition, if you want to make the matching performance faster, it is recommended that Redis and the matching engine can use the same server, which can reduce the transmission time between different servers.

Follow the steps below to install and deploy the matching engine to the running environment:

1. Upload the matching.zip archive to the runtime environment;

2. Unzip the matching.zip archive in the runtime environment. After unzipping, there is an executable file and a folder:

• matching: This is the executable file of the matching engine program

• conf: The directory where the configuration files are stored, there is a configuration file config.yaml

1. Modify the configuration file to the configuration value you want:

server:
  port: :9466 //The port on which the matching engine program starts listening
log: //Output log configuration
  fileDir: logs //The directory where the output logs are stored
  fileName: matching //log file name, split by date
  prefix: //log message prefix
  level: debug //Log level, from low to high: debug, info, warn, error
redis:
  addr: 127.0.0.1:6379 //Redis address

1. If the default configuration is used, please confirm that Redis has been installed and started locally in the operating environment and is running on port 6379;

2. If the default configuration is not used, it is still necessary to confirm that Redis can be connected correctly;

3. Run the following command to start the matching engine program in the background:

./matching &

1. Run the following command to check if the program starts successfully:

ps aux|grep matching

1. After the program starts successfully, a log file will be generated in the configured log directory. The default is the file in the same directory as the matching executable file. logs/matching.log;

2. So far, the matching engine program has been successfully installed and deployed.

Docking input

To access the matching engine, you only need to connect to three HTTP interfaces. The interfaces use the POST method, the parameters are in json format, and the body is passed.

1. Enable matchmaking

Enable the matching function of the specified trading target (trading pair).

HTTP request

• POST /openMatching

request parameters

• symbol: string type, required field, the identifier of the transaction target (trading pair), such as BTC_USDT

• price: numeric type, optional field, default is 0, opening price

request example

POST /openMatching
Body:
{
  "symbol": "BTC_USDT",
  "price": 8219.85
}

Response data

{"code":0,"msg":"OK"}

2. Close matchmaking

Turn off the matching function of the specified trading target (trading pair).

HTTP request

• POST /closeMatching

request parameters

• symbol: string type, required field, the identifier of the transaction target (trading pair), such as BTC_USDT

request example

POST /closeMatching
Body:
{
  "symbol": "BTC_USDT"
}

Response data

{"code":0,"msg":"OK"}

3. Process the order

Receive order placement and cancellation requests.

HTTP request

• POST /handleOrder

request parameters

• symbol: string type, required field, the identifier of the transaction target (trading pair), such as BTC_USDT

• action: string type, required field, order action, order=create, cancel order=cancel

• orderId: String type, required field, order ID

• side: string type, required field, buying and selling direction, buy=buy, sell=sell

• type: string type, required field, order type, including: limit, limit-ioc, market, market-top5, market-top10, market-opponent, see below for the description

• amount: numeric type, optional field, the default is 0, order transaction volume, must be passed when placing an order, but not required when canceling an order

• price: numeric type, optional field, the default is 0, the order price, it can be omitted when the order type is market price

Order Type Description:

• limit: ordinary limit price

• limit-ioc: IOC limit price - immediate transaction remaining cancellation

• market: default market price - immediate transaction remaining cancellation

• market-top5: market price - the best five real-time transaction remaining cancellation

• market-top10: market price-best ten real-time transaction remaining cancellation

• market-opponent: market price - the best price of the counterparty

request example

POST /handleOrder
Body:
{
  "symbol": "BTC_USDT",
  "action": "create",
  "orderId": "a0001",
  "side": "buy",
  "type": "limit",
  "amount": 0.012,
  "price": 8230.74
}

Response data

{"code":0,"msg":"OK"}

Docking output

The matching engine has two outputs: order cancellation results and transaction records. The input is unified in the way of MQ. MQ is saved as a new data structure Stream type introduced after Redis 5.0 version. Each message queue is actually a stream. I will not expand on the specific usage of stream. You can search and learn online by yourself.

1. Cancellation result

Set a stream for each different symbol, the key format is: matching:cancelresults:{symbol}, and the value contains two fields:

• orderId: order number

• ok: 1=success; 0=failure

2. Transaction History

Each different symbol also sets an MQ, the format of the key is: matching:trades:{symbol}, and the fields contained in the value are as follows:

• makerId: maker order ID

• takerId: taker order ID

• takerSide: taker buying and selling direction

• amount: transaction amount

• price: transaction price

• timestamp: transaction time

Downstream services can monitor these two outputs by subscribing, and then do subsequent processing, such as the K-line market service subscription and monitoring transaction records to generate K-line data. After the matching engine is completed, the next component I will develop is the K-line market service.

Project structure

Finally, let's take a look at the file directory structure of the entire Go project inside our black box:

├── conf # Configuration file storage directory, added in version 1.1
│ ├── config.yaml # Configuration file, added in version 1.1
├── engine # engine package
│ ├── init.go # Initialization
│ ├── order.go # order
│ ├── order_book.go # Transaction order book
│ ├── order_queue.go # order queue
│ ├── run.go # Matching engine startup entry for specific trading pairs
│ └── trade.go # Transaction record
├── enum # enumeration type package
│ ├── order_action.go # Order action, create is to place an order, cancel is to cancel an order
│ ├── order_side.go # Buy and sell direction, buy is buy, sell is sell
│ ├── order_type.go # Order type, MVP version (version 1.0) only supports limit, version 1.3 supports a total of 7 types
│ └── sort_direction.go # Sort direction, asc is ascending, desc is descending
├── errcode #
│ ├── code.go # Defines various error codes
│ └── errcode.go # Error code data structure, including code and msg fields
├── handler #
│ ├── close_matching.go # Receive a request to close the matching
│ ├── handle_order.go # Receive a request to process an order
│ └── open_matching.go # Receive a request to open matching
├── log # log package, added in version 1.2
│ ├── log.go # log output, added in version 1.2
├── main.go # The only entry to the Go program
├── middleware # middleware package
│ ├── cache # cache package
│ │ └── cache.go # Cache operation
│ ├── mq # message queue package
│ │ └── mq.go # MQ operation
│ └── redis.go # Mainly for Redis initialization
└── process #
    ├── close_engine.go # close the engine
    ├── dispatch.go # dispatch order
    ├── init.go # initialization
    └── new_engine.go # Start a new engine

Including the main package, the entire project is divided into 10 packages and 1 configuration file directory:

• conf: The directory where configuration files are stored.

• main: The main package has only one main.go file, which defines the program entry function.

• enum: The enumeration package implements several enumerated types of data structures, including order behavior, buy and sell direction, order type, and order direction.

• errcode: A package that stores error codes. errcode.go defines the data structure of error codes, with two attributes, code and msg; code.go defines some error code objects.

• handler: The functions that receive HTTP requests are all placed in this package, and there are currently only three handler functions.

• process: The process of starting, shutting down the engine and distributing orders is all in this package. The package also maintains order channels for different trading pairs, which are used to distribute orders for different trading pairs.

• engine: engine package, including the core data structures of orders, transaction order books, order queues, and transaction records, as well as entry functions for processing transaction pair matching.

• middleware: The package that stores middleware, currently only one middleware of Redis is used.

• cache: cache package, there is only one cache.go file, and cache operations are defined in this file.

• mq: message queue package, there is only one mq.go file, and the sending of messages is defined here.

• log: A log package that implements log messages split by date and output to a file.

Summary

In this section, we learned that the matching engine, as a general component, has standard input and output, and the input and output are very simple. It also began to show you the file directory structure inside the black box, and began to explore the internal logic of the black box. Subsequent chapters will reveal these internal implementation logic one after another.

OrderBook is the core and most complex data structure in the entire matching engine. Each transaction pair needs to maintain a transaction order book, which stores all the orders to be matched for the specified transaction pair. . Each ledger has two queues, a sell order queue and a buy order queue. Both queues need to be sorted according to the principle of price priority and time priority.

The so-called price priority and time priority mean that the orders in the sell order queue are sorted by price from low to high, while the buy order queue is on the contrary, sorted by price from high to low; orders with the same price are ordered by the time of the order. order in order.

As shown in the figure above, each small square represents an order, the order marked H is the order in the head, N is the same price as H but the order time is ranked behind H Order, S is the first order of the next tier price. It can be clearly seen from the figure that horizontally, the orders are sorted by time, and vertically, they are sorted by price.

When matching, the H order is first taken out to match the new order. If the new order is a buy order, get the H order in the sell order queue to match; if the new order is a sell order, get the H order in the buy order queue. If all H orders are matched and filled, the order marked with N will become a new H order. If all orders in the first row are matched, the S order will become a new H order.

The transaction order book can support some operation methods, including initialization, adding a buying and selling order, removing a buying and selling order, and obtaining a head order, etc. The class diagram of the transaction order book is roughly as follows:

Among them, the difference between getHead and popHead methods is: get reads the head order but does not remove it, while pop removes the head order from the queue.

order queue

The buy order queue and the sell order queue can be designed to use a unified order queue type. The only difference between the two is the price sorting direction, then the order queue can use an attribute to represent the sorting direction. All orders in the queue can be stored in a two-dimensional array or a two-dimensional linked list. Considering that the main operations are insertion and deletion, using a linked list is more efficient than using an array. If you want to operate more efficiently, you need to use a more complex data structure, such as a combination of skip tables. The current version is simple, using a simple two-dimensional linked list.

If a two-dimensional linked list is used, each element in the linked list stores an order linked list sorted by time horizontally, and these linked lists of orders form a linked list sorted by price vertically.

In addition, you can also save a Map, use the price as the Key, and use the order list of the same price as the Value, which can speed up the query of orders at the same price.

The operation methods supported by the order queue are also very simple, including initialization, adding an order, removing an order, and obtaining the head order. Its class diagram is roughly as follows:

sortBy specifies the direction of price sorting, parentList saves the entire two-dimensional linked list, the first dimension is sorted by price, the second dimension is sorted by time, elementMap means that Key is price and Value is the first A key-value pair for a two-dimensional order list.

order

The order form is the most basic data structure in the matching engine. Its data is mainly transmitted from the upstream service. The class diagram is roughly as follows:

action declares what kind of operation to perform on the order, we only need to support two operations: order (create) and cancel (cancel). symbol specifies the trading pair to which the order belongs, orderId is the unique identifier of the order, and side indicates whether it is buy (buy) or sell (sell) ). *type * indicates the transaction type, namely limit transaction(limit) or market price(market), etc. Our MVP version only supports limit transaction. **amount ** is the purchase quantity, price is the purchase price, and timestamp is the order time.

toJson() and fromJson() methods are used to support serialization and deserialization of order data transmission.

Transaction Record

The matched transaction order will generate the corresponding transaction record, and the transaction record needs to be published to MQ for downstream service consumption. The data structure of the transaction record is as follows:

maker refers to a pending order, which is an order originally hung in the transaction entrustment ledger, while taker refers to a taker order, which refers to an order that takes the maker. makerId and takerId are the order IDs of pending and taker orders. takerSide is the buying and selling direction of the taker. The transaction records we see in the market software will have different colors, which is determined by this takerSide. amount is the transaction quantity, price is the transaction price, and timestamp is the transaction time.

Redis cache

We need to use Redis to cache the order data and the transaction pair data in the matching process. There are two main functions. One is to deduplicate the request, and the other is to restore the data after the program is restarted.

Due to network interruption or delay, or other abnormal conditions, the upstream service may repeatedly send the same request to the matching engine. Therefore, the program needs to be deduplicated. With the data cache, the deduplication problem can be solved. In addition, since we use memory matching, the data when matching is directly stored in the program memory. Once the program exits, all the data will also disappear. After restarting, the data needs to be reloaded from other places, using Redis Cache can cache data and load data very quickly.

When opening a trading pair engine, you need to cache the trading pair, and when it is closed, it will be deleted from the cache to ensure that all running trading pairs are cached. When restarting, the matching engine of these trading pairs can be restarted. The trading pair data that needs to be cached includes two: symbol and price, that is, the symbol and the price. Regarding the price, every time a new transaction record is generated, the price also needs to be updated synchronously, so the price update will be very frequent. The identity basically does not need to be updated, so the two are best cached separately.

The symbols of all trading pairs can be uniformly cached in a set. We can set the key value to matching:symbols, and use Redis's sadd and srem commands to cache different symbols into the key value or delete them from the key. The price can be saved as a string type, and different keys can be set for the prices of different trading pairs. The key value can be set to matching:price:{symbol}, and {symbol} is the symbol value of a specific trading pair.

Each order also needs to be cached and updated. In order to read and update the order data from the cache as quickly as possible, it is best to set a separate key for each order. The key value can be set to matching:order :{symbol}:{orderId}:{action}, and the value value is recommended to be set to the hash type, because the hash type is especially suitable for storing structured objects.

Both the transaction pair and the order data are cached, which can solve the problem of deduplication and restart the matching engine of each trading pair after the program is restarted. However, there is still a problem, how to restore the transaction order book in the matching engine? This question is left to everyone to think about first, and I will explain my plan in the following chapters.

Summary

In fact, there are not many data structures involved in the matching engine, and the most complex is only the transaction entrustment ledger, and its design is also directly related to the speed of matching. The design of Redis cache also has some knowledge in it, and if it is not well designed, it will also affect the overall matching performance.

The matching engine is the core component of all matching trading systems, whether it is a stock trading system - including spot trading, futures trading, options trading, etc., or a digital currency trading system - including currency trading, contract trading, leverage trading, etc. There are different precious metal trading systems, commodity trading systems, etc. Although the trading targets of different trading systems are different, as long as they all adopt the matching trading mode, they are inseparable from the matching engine.

The matching engine can be universal, and a set of universal matching engine implementation can theoretically be applied to any matching trading system without any code adjustment. That is to say, the implementation of the same matching engine can be applied to both the stock trading system and the digital currency trading system, and can be used for spot trading or contract trading.

So, what functions should a universal matching engine have? Before determining the answer to this question, let's briefly sort out what a complete transaction process looks like? It generally includes the following steps:

1. The system opens the transaction function of a certain transaction target.

2. The user submits the purchase and sale declaration of the transaction target, namely Order Form.

3. The system verifies whether the order is valid, including whether the transaction target is in a tradable state, whether the price and quantity of the order meet the requirements, etc.

4. Determine the Maker rate and Taker rate for the order.

5. Check the user's asset account status, including whether the account status is restricted for transactions, whether there is enough funds to place an order, etc.

6. Persist the detailed order data to the database and freeze the corresponding amount of funds in the user's account.

7. Match the order, that is, find the order that can match the order in the OrderBook, and the matching result may be: full transaction, partial transaction or no match. When all or part of the transaction is completed, there may be one or more matching orders in the transaction order book, that is, one or more transaction records will be generated. When there is no match or a partial transaction, part of the data of the order, including the remaining unfilled quantity, will be temporarily saved in the transaction order book, waiting to be matched with subsequent orders.

8. Persist the transaction records generated by the matching to the database, and generate market data based on historical transaction records, such as K-line data, today's change, etc.

9. Update the order data of all executed orders in the database, and update the asset account balance of the order user.

10. Send the updated order data, market data, etc. to the front desk.

The entire transaction process involves multiple services, including user services, account services, order services, matching services, and market data services. Among them, only step 7 is processed by the matching engine. From the principle of single responsibility, the matching engine should only do one thing, and that is responsible for matching orders. Persistence of orders before matching, freezing funds, etc., and generating K-line data after matching, should not be the responsibility of the matching engine.

Matching bidding method

There are generally two ways of matching auctions, one is call auction, and the other is continuous auction. The stock trading system generally uses different bidding methods in different trading time periods, such as call auction at the opening or closing, resulting in opening price or closing price, and continuous bidding at the rest of the time. However, most digital currency trading systems do not have call auctions, but only continuous auctions. The opening price is generally set before the transaction starts.

Call auction

The so-called call auction refers to the auction method in which the buy and sell orders received within a certain period of time are matched at one time. During this time period, the orders received by the system will not be executed immediately, but all orders will be sorted according to the principle of price priority and time priority, and based on this, a benchmark price will be found. , so that it can satisfy the following three conditions at the same time:

1. The price that can achieve the maximum volume;

2. The price at which all buy orders higher than this price and sell orders lower than this price can be fully executed;

3. The price at which at least one of the buyers or sellers with the same price completes the transaction.

At the end of 9:25, the benchmark price is determined as the execution price, and all buy orders higher than this price and sell orders lower than this price will be filled at this price. Orders that fail to be filled will be automatically transferred to continuous auction.

The main purpose of a call auction is to determine the opening or closing price.

Continuous Bidding

The so-called continuous bidding is also the bidding method that we are familiar with, which refers to the bidding method that continuously matches the buy and sell orders one by one. The user's pending order, as long as the transaction conditions are met, can be executed immediately. The call auction will not be completed until the last minute.

When bidding continuously, the transaction principle of price priority and time priority should still be met:

1. Price Priority: For buy orders, those with higher prices will be given priority, and those with lower prices will be given priority for sell orders.

2. Time Priority: For orders with the same buying and selling direction and price, the orders declared first will be executed in priority over the orders declared later.

In addition, the bid price must be greater than or equal to the ask price in order to close the deal. When the bid price is equal to the ask price, the transaction price is the bid or ask price. When the buying price is greater than the selling price, the latest transaction price is determined by referring to the previous transaction price. Suppose the buying price is B, the selling price is S, the previous transaction price is P, and the latest transaction price is N, then:

• If P >= B, then N = B • If P <= S, then N = S • If B > P > S, then N = P

A set of general matching engines should support both bidding methods, but for the same transaction target, the two bidding methods cannot be performed at the same time. Therefore, the design needs to consider how to switch between the two bidding methods. The specific implementation ideas are in We will expand on it in the following chapters.

Quality requirements

In addition to meeting the above-mentioned functional requirements, our matching engine should also meet some quality requirements, especially high requirements for availability, scalability and performance. In addition, in order to achieve universality, it is also necessary to meet the requirements of reusability.

Let’s talk about reusability first. What we expect is that the matching engine can be used for both stock trading systems and digital currency trading systems, and can be used for both currency transactions and contract transactions. Therefore, the matching engine should avoid introducing business logic that is strongly related to the specific system to enhance its reusability.

Looking at the performance, to measure the performance of a matching engine, it depends on how high the TPS it handles for each trading pair, that is, how many orders for the same trading pair can be processed per second. In the past, with database-based matching technology, the TPS was generally only 10 transactions per second. Nowadays, memory matching technology is basically used, and TPS can easily reach 1,000 transactions per second. If an exclusive high-performance server is used, TPS of 10,000 transactions per second or even higher is not difficult to achieve.

Let’s talk about scalability. Each of our matching engines can process multiple transaction targets at the same time, or only a single transaction target. When transaction targets and concurrency increase, servers can be added and deployed into matching engine clusters to process different transaction targets respectively, so as to achieve load balancing.

Finally, let’s talk about availability. High availability is mainly reflected in two points. One is that the failure rate is low, and the other is that the time for repairing failures is short. To reduce the failure rate, the matching engine needs to have high robustness, and consider and design solutions for various abnormal conditions that may cause the engine to fail. In addition, multi-machine hot backup technology can also be used to improve availability, and to ensure data consistency between mutual backup servers, it is necessary to introduce a memory state machine replication scheme, which will be much more complicated to implement.

However, we do not achieve high quality requirements all at once, because the higher the requirements, the more complex their architecture and implementation will be. We can start with a simple version and continue to iterate.

Summary

Our purpose is to implement a set of general matching engines, to support collective bidding and continuous bidding, but also to achieve some quality requirements, and improve the reusability, performance, scalability, availability, etc. of the system.