3个真实案例揭秘炒外汇系统开发中的新手避坑指南
官方文档那几千页的代码规范，你翻完只想睡觉？别急，我见过太多新手在“炒外汇”模拟交易系统的开发中栽跟头。不是代码写不出，而是根本抓不住重点。
做金融类后端，尤其是涉及资金划转的模块，容错率几乎为零。很多教程只教你怎么调API，却不告诉你怎么防“脏数据”、怎么在极端行情下保证订单一致性。今天这篇不聊虚的，直接带你从零搭建一个高可用的外汇模拟撮合引擎核心模块。
我们不只写代码，更要把那些坑提前填上。你会发现，真正的新手避坑，不是背多少API，而是理解数据流在极端情况下的行为。
项目目标与风险边界
在动手前，先明确我们要做什么。这不是一个真实交易接口，而是一个内存级的高性能模拟撮合引擎。
为什么这么做？因为真实环境涉及合规、风控、第三方网关，环境极其复杂。而核心难点在于订单状态机与并发一致性。
岗位执业风险与法律责任：
在实际工作中，这类系统通常由资深后端或架构师负责。新手如果直接触碰核心资金逻辑，一旦因逻辑漏洞导致用户资金异常，即便在模拟环境，也会暴露出严重的职业素养问题。根据《网络安全法》及金融行业相关规范，开发人员在代码中必须预留审计日志接口。我们的项目目标，就是构建一个具备完整审计能力的核心撮合服务。
核心指标：吞吐量：单机支持 10,000 TPS 的订单处理。
一致性：同一时刻，同一标的的订单必须严格串行化处理，避免超卖（即持仓计算错误）。
低延迟：P99 延迟控制在 5ms 以内。目录结构与工程化规范
不要一上来就建 main.py。工程化是新手避坑的第一步。混乱的文件结构是后期维护的噩梦。
我们采用 Python + FastAPI + Redis + SQLite(用于日志持久化) 的技术栈。Python 开发速度快，适合原型验证；FastAPI 性能优秀；Redis 用于存储实时账户状态，避免频繁磁盘IO。
标准目录结构：
forex-sim-engine/
├── app/
│ ├── main.py # 应用入口，初始化生命周期
│ ├── core/
│ │ ├── config.py # 配置管理
│ │ ├── exceptions.py # 自定义异常
│ │ └── security.py # 模拟鉴权
│ ├── models/
│ │ ├── order.py # 订单数据模型 (Pydantic)
│ │ └── position.py # 持仓数据模型
│ ├── services/
│ │ ├── matcher.py # 核心撮合逻辑 (最核心部分)
│ │ └── risk.py # 模拟风控检查
│ ├── db/
│ │ ├── redis_client.py # Redis 连接池
│ │ └── sqlite_logger.py # 审计日志持久化
│ └── utils/
│ └── logger.py # 统一日志格式
├── tests/
│ ├── test_matcher.py # 撮合逻辑单元测试
│ └── fixtures/ # 测试数据
├── docker-compose.yml # 本地环境一键启动
├── requirements.txt # 依赖管理
└── README.md关键点：services 层只处理业务逻辑，不直接操作数据库，通过 db 层解耦。
所有涉及资金变动的方法，必须经过 risk.py 的校验，这是合规要求。核心代码实现：撮合引擎
这是整个项目的灵魂。很多新手在这里犯最大的错误：使用简单的 if-else 判断价格，而没有考虑并发下的原子性。
我们将采用 Redis Lua 脚本 来实现原子性的订单撮合。为什么？因为 Python 的 GIL 并不能保证跨进程或跨服务调用 Redis 时的原子性，而 Lua 脚本在 Redis 中是单线程原子执行的。
1. 定义订单模型
# app/models/order.py
from pydantic import BaseModel, Field
from enum import Enum
from datetime import datetimeclass OrderSide(str, Enum):BUY = BUYSELL = SELLclass OrderStatus(str, Enum):PENDING = PENDINGFILLED = FILLEDREJECTED = REJECTEDclass OrderRequest(BaseModel):order_id: str = Field(..., description=唯一订单ID)symbol: str = Field(..., description=交易对，如 EURUSD)side: OrderSideprice: floatquantity: float = Field(..., gt=0)client_id: str2. 核心撮合逻辑 (Redis Lua)
我们需要一个 Lua 脚本，它接收订单，检查账户余额，更新持仓，并返回结果。
-- app/db/scripts/match_order.lua
-- KEYS[1]: account_balance_key
-- KEYS[2]: position_key
-- ARGS[1]: order_id
-- ARGS[2]: symbol
-- ARGS[3]: side (BUY/SELL)
-- ARGS[4]: price
-- ARGS[5]: quantity
-- ARGS[6]: margin_rate (保证金比例，简化为0.1)local balance_key = KEYS[1]
local position_key = KEYS[2]local order_id = ARGV[1]
local symbol = ARGV[2]
local side = ARGV[3]
local price = tonumber(ARGV[4])
local quantity = tonumber(ARGV[5])
local margin_rate = tonumber(ARGV[6])-- 1. 获取当前余额
local balance = tonumber(redis.call('GET', balance_key) or 0)-- 2. 计算所需保证金
-- 简化模型：所需保证金 = 手数 * 价格 * 保证金比例
local required_margin = quantity * price * margin_rate-- 3. 检查余额是否充足
if balance required_margin thenreturn {0, INSUFFICIENT_MARGIN}
end-- 4. 更新余额 (扣除保证金)
redis.call('DECRBY', balance_key, math.floor(required_margin * 100))
-- 注意：这里为了演示简化，实际需使用 Redis 的 Float 处理或分单位存储-- 5. 更新持仓
local position = redis.call('HGET', position_key, symbol) or 0
position = tonumber(position)if side == BUY thenposition = position + quantity
elseposition = position - quantity
endredis.call('HSET', position_key, symbol, tostring(position))-- 6. 返回成功及新持仓
return {1, tostring(position)}3. Python 服务层调用
# app/services/matcher.py
import redis
from app.models.order import OrderRequest, OrderStatus
from app.core.config import settings
import timeclass MatchEngine:def __init__(self):self.redis_client = redis.Redis(host=settings.REDIS_HOST,port=settings.REDIS_PORT,db=settings.REDIS_DB,decode_responses=True)# 加载 Lua 脚本with open(app/db/scripts/match_order.lua, r) as f:self.match_script = self.redis_client.register_script(f.read())def process_order(self, order: OrderRequest):start_time = time.time()# 构造键balance_key = fuser:{order.client_id}:balanceposition_key = fuser:{order.client_id}:positionstry:# 执行原子脚本result = self.match_script(keys=[balance_key, position_key],args=[order.order_id,order.symbol,order.side.value,str(order.price),str(order.quantity),str(settings.DEFAULT_MARGIN_RATE)])status_code, message = result[0], result[1]if status_code == 1:# 记录审计日志self._log_audit(order, OrderStatus.FILLED, message)return {status: OrderStatus.FILLED,position: message}else:# 记录拒绝日志self._log_audit(order, OrderStatus.REJECTED, message)return {status: OrderStatus.REJECTED,reason: message}except redis.exceptions.RedisError as e:# 异常处理：网络抖动等self._log_audit(order, OrderStatus.REJECTED, fSYSTEM_ERROR: {str(e)})raise Exception(System Error)finally:# 计算延迟latency = (time.time() - start_time) * 1000print(fOrder {order.order_id} processed in {latency:.2f}ms)def _log_audit(self, order: OrderRequest, status: OrderStatus, detail: str):# 此处简化，实际应写入数据库或消息队列print(fAUDIT: {order.order_id} | {status} | {detail})逐行讲解避坑点：register_script：不要在每次请求时加载 Lua 脚本，这会极大地增加网络开销。
浮点数精度：在 Lua 中处理货币时，tonumber 默认转为浮点数。在生产环境中，严禁直接使用 Float 存储金额。建议将金额放大100倍（转为分）作为整数存储，或者使用 Redis 的 GEORADIUS 等特定结构（不推荐用于金额），最稳妥的是使用 String 存储整数分位，在应用层转换。上述代码为了演示简洁做了简化，实际项目中请务必修改为整数运算。
异常捕获：Redis 连接超时是常态，必须捕获 RedisError，并记录详细日志，绝不能让异常直接抛给前端，否则用户会看到 500 错误，体验极差。运行与测试：验证一致性
代码写完只是开始，测试才是新手避坑的核心环节。
1. 环境启动
使用 docker-compose 一键启动 Redis 和 Python 服务。
# docker-compose.yml
version: '3.8'
services:redis:image: redis:7-alpineports:- 6379:6379app:build: .ports:- 8000:8000environment:- REDIS_HOST=redisdepends_on:- redis2. 并发压力测试脚本
我们需要模拟 100 个用户同时下单，验证余额是否会出现负数或持仓错误。
# tests/test_concurrent.py
import asyncio
import httpx
from app.models.order import OrderSide, OrderRequestasync def send_order(client_id: str, side: OrderSide, price: float, qty: float):url = http://localhost:8000/orderspayload = {order_id: fORD-{client_id}-{asyncio.get_event_loop().time()},symbol: EURUSD,side: side,price: price,quantity: qty,client_id: client_id}async with httpx.AsyncClient() as client:response = await client.post(url, json=payload)return response.json()async def main():# 初始化 100 个用户，每个余额 10000# 这里省略初始化 Redis 数据的代码tasks = []for i in range(100):# 每个用户下 10 单，总数量 1000 单for j in range(10):tasks.append(send_order(fuser_{i}, OrderSide.BUY, 1.1, 100))# 并发执行results = await asyncio.gather(*tasks)# 统计结果filled = sum(1 for r in results if r['status'] == 'FILLED')rejected = sum(1 for r in results if r['status'] == 'REJECTED')print(fFilled: {filled}, Rejected: {rejected})# 关键校验：检查 Redis 中所有用户的余额总和是否守恒# 这里需要读取 Redis 进行断言if __name__ == __main__:asyncio.run(main())测试发现的一个典型 Bug：
在初次测试中，我发现部分订单被拒绝，原因是 Lua 脚本中 DECRBY 不支持浮点数。当我把金额改为整数后，问题消失。这就是为什么官方文档太长你抓不住重点的原因——它不会告诉你 DECRBY 只能处理整数。
优化扩展与进阶技巧
系统跑通了，但还不够。
1. 引入消息队列解耦
当前架构中，撮合完成后直接返回结果。但在真实高并发场景下，审计日志写入数据库可能会阻塞撮合线程。
优化方案：
引入 RabbitMQ 或 Kafka。撮合成功后，将订单信息发送到 MQ，由独立的消费者服务异步写入数据库。这样撮合引擎只负责计算，不关心持久化，性能提升 30% 以上。
2. 行情数据的处理
当前代码中，价格是由客户端传入的。这在真实交易中是致命错误。
正确做法：客户端只能提交“限价单”或“市价单”。
服务器端维护一个行情订阅服务，从第三方数据源（如 Binance WebSocket）获取最新价格。
撮合引擎在匹配时，必须使用服务器端当前最新价格，或者严格检查客户端限价是否在允许滑点范围内。代码片段示意：
# app/services/market_data.py
class MarketDataService:def __init__(self):self.latest_prices = {} # {symbol: price}self.lock = asyncio.Lock()async def update_price(self, symbol: str, price: float):async with self.lock:self.latest_prices[symbol] = pricedef get_price(self, symbol: str) - float:return self.latest_prices.get(symbol, 0.0)3. 监控与告警
在 main.py 中集成 Prometheus 指标：order_processing_latency_seconds：直方图，监控延迟分布。
order_rejection_total：计数器，监控拒绝原因。当拒绝率超过 5% 时，触发告警。这可能是行情异常或系统负载过高的信号。
小结与岗位边界
通过这个项目，你不仅搭建了一个撮合引擎，更理解了金融后端开发的几个核心逻辑：原子性：涉及资金操作，必须使用原子机制（Lua、事务、锁）。
幂等性：订单 ID 必须唯一，重复请求不能导致重复扣款。
审计合规：每一笔变动都要可追溯，日志是法律证据。岗位日常职责边界：
作为后端开发，你的职责是保证系统的稳定性与数据一致性。不要做：不要自己定义行情算法，不要绕过风控模块直接写库，不要在没有测试的情况下上线核心逻辑。
要做：写好单元测试，配置好监控告警，详细记录每一行代码的变更原因。很多新手觉得炒外汇系统很神秘，其实拆开看，就是高并发 + 强一致性 + 严格合规的工程问题。技术本身不难，难的是对细节的敬畏。
这个知识点你面试被问过吗？
特别是“如何在高并发下保证订单不超卖”或者“Redis Lua 脚本的局限性”，留言说说你的看法。如果是你，你会选择用 Redis 还是直接上数据库事务？ 3个真实案例揭秘炒外汇系统开发中的新手避坑指南
3个真实案例揭秘炒外汇系统开发中的新手避坑指南
官方文档那几千页的代码规范，你翻完只想睡觉？别急，我见过太多新手在“炒外汇”模拟交易系统的开发中栽跟头。不是代码写不出，而是根本抓不住重点。
做金融类后端，尤其是涉及资金划转的模块，容错率几乎为零。很多教程只教你怎么调API，却不告诉你怎么防“脏数据”、怎么在极端行情下保证订单一致性。今天这篇不聊虚的，直接带你从零搭建一个高可用的外汇模拟撮合引擎核心模块。
我们不只写代码，更要把那些坑提前填上。你会发现，真正的新手避坑，不是背多少API，而是理解数据流在极端情况下的行为。
项目目标与风险边界
在动手前，先明确我们要做什么。这不是一个真实交易接口，而是一个内存级的高性能模拟撮合引擎。
为什么这么做？因为真实环境涉及合规、风控、第三方网关，环境极其复杂。而核心难点在于订单状态机与并发一致性。
岗位执业风险与法律责任：
在实际工作中，这类系统通常由资深后端或架构师负责。新手如果直接触碰核心资金逻辑，一旦因逻辑漏洞导致用户资金异常，即便在模拟环境，也会暴露出严重的职业素养问题。根据《网络安全法》及金融行业相关规范，开发人员在代码中必须预留审计日志接口。我们的项目目标，就是构建一个具备完整审计能力的核心撮合服务。
核心指标：吞吐量：单机支持 10,000 TPS 的订单处理。
一致性：同一时刻，同一标的的订单必须严格串行化处理，避免超卖（即持仓计算错误）。
低延迟：P99 延迟控制在 5ms 以内。目录结构与工程化规范
不要一上来就建 main.py。工程化是新手避坑的第一步。混乱的文件结构是后期维护的噩梦。
我们采用 Python + FastAPI + Redis + SQLite(用于日志持久化) 的技术栈。Python 开发速度快，适合原型验证；FastAPI 性能优秀；Redis 用于存储实时账户状态，避免频繁磁盘IO。
标准目录结构：
forex-sim-engine/
├── app/
│ ├── main.py # 应用入口，初始化生命周期
│ ├── core/
│ │ ├── config.py # 配置管理
│ │ ├── exceptions.py # 自定义异常
│ │ └── security.py # 模拟鉴权
│ ├── models/
│ │ ├── order.py # 订单数据模型 (Pydantic)
│ │ └── position.py # 持仓数据模型
│ ├── services/
│ │ ├── matcher.py # 核心撮合逻辑 (最核心部分)
│ │ └── risk.py # 模拟风控检查
│ ├── db/
│ │ ├── redis_client.py # Redis 连接池
│ │ └── sqlite_logger.py # 审计日志持久化
│ └── utils/
│ └── logger.py # 统一日志格式
├── tests/
│ ├── test_matcher.py # 撮合逻辑单元测试
│ └── fixtures/ # 测试数据
├── docker-compose.yml # 本地环境一键启动
├── requirements.txt # 依赖管理
└── README.md关键点：services 层只处理业务逻辑，不直接操作数据库，通过 db 层解耦。
所有涉及资金变动的方法，必须经过 risk.py 的校验，这是合规要求。核心代码实现：撮合引擎
这是整个项目的灵魂。很多新手在这里犯最大的错误：使用简单的 if-else 判断价格，而没有考虑并发下的原子性。
我们将采用 Redis Lua 脚本 来实现原子性的订单撮合。为什么？因为 Python 的 GIL 并不能保证跨进程或跨服务调用 Redis 时的原子性，而 Lua 脚本在 Redis 中是单线程原子执行的。
1. 定义订单模型
# app/models/order.py
from pydantic import BaseModel, Field
from enum import Enum
from datetime import datetimeclass OrderSide(str, Enum):BUY = BUYSELL = SELLclass OrderStatus(str, Enum):PENDING = PENDINGFILLED = FILLEDREJECTED = REJECTEDclass OrderRequest(BaseModel):order_id: str = Field(..., description=唯一订单ID)symbol: str = Field(..., description=交易对，如 EURUSD)side: OrderSideprice: floatquantity: float = Field(..., gt=0)client_id: str2. 核心撮合逻辑 (Redis Lua)
我们需要一个 Lua 脚本，它接收订单，检查账户余额，更新持仓，并返回结果。
-- app/db/scripts/match_order.lua
-- KEYS[1]: account_balance_key
-- KEYS[2]: position_key
-- ARGS[1]: order_id
-- ARGS[2]: symbol
-- ARGS[3]: side (BUY/SELL)
-- ARGS[4]: price
-- ARGS[5]: quantity
-- ARGS[6]: margin_rate (保证金比例，简化为0.1)local balance_key = KEYS[1]
local position_key = KEYS[2]local order_id = ARGV[1]
local symbol = ARGV[2]
local side = ARGV[3]
local price = tonumber(ARGV[4])
local quantity = tonumber(ARGV[5])
local margin_rate = tonumber(ARGV[6])-- 1. 获取当前余额
local balance = tonumber(redis.call('GET', balance_key) or 0)-- 2. 计算所需保证金
-- 简化模型：所需保证金 = 手数 * 价格 * 保证金比例
local required_margin = quantity * price * margin_rate-- 3. 检查余额是否充足
if balance required_margin thenreturn {0, INSUFFICIENT_MARGIN}
end-- 4. 更新余额 (扣除保证金)
redis.call('DECRBY', balance_key, math.floor(required_margin * 100))
-- 注意：这里为了演示简化，实际需使用 Redis 的 Float 处理或分单位存储-- 5. 更新持仓
local position = redis.call('HGET', position_key, symbol) or 0
position = tonumber(position)if side == BUY thenposition = position + quantity
elseposition = position - quantity
endredis.call('HSET', position_key, symbol, tostring(position))-- 6. 返回成功及新持仓
return {1, tostring(position)}3. Python 服务层调用
# app/services/matcher.py
import redis
from app.models.order import OrderRequest, OrderStatus
from app.core.config import settings
import timeclass MatchEngine:def __init__(self):self.redis_client = redis.Redis(host=settings.REDIS_HOST,port=settings.REDIS_PORT,db=settings.REDIS_DB,decode_responses=True)# 加载 Lua 脚本with open(app/db/scripts/match_order.lua, r) as f:self.match_script = self.redis_client.register_script(f.read())def process_order(self, order: OrderRequest):start_time = time.time()# 构造键balance_key = fuser:{order.client_id}:balanceposition_key = fuser:{order.client_id}:positionstry:# 执行原子脚本result = self.match_script(keys=[balance_key, position_key],args=[order.order_id,order.symbol,order.side.value,str(order.price),str(order.quantity),str(settings.DEFAULT_MARGIN_RATE)])status_code, message = result[0], result[1]if status_code == 1:# 记录审计日志self._log_audit(order, OrderStatus.FILLED, message)return {status: OrderStatus.FILLED,position: message}else:# 记录拒绝日志self._log_audit(order, OrderStatus.REJECTED, message)return {status: OrderStatus.REJECTED,reason: message}except redis.exceptions.RedisError as e:# 异常处理：网络抖动等self._log_audit(order, OrderStatus.REJECTED, fSYSTEM_ERROR: {str(e)})raise Exception(System Error)finally:# 计算延迟latency = (time.time() - start_time) * 1000print(fOrder {order.order_id} processed in {latency:.2f}ms)def _log_audit(self, order: OrderRequest, status: OrderStatus, detail: str):# 此处简化，实际应写入数据库或消息队列print(fAUDIT: {order.order_id} | {status} | {detail})逐行讲解避坑点：register_script：不要在每次请求时加载 Lua 脚本，这会极大地增加网络开销。
浮点数精度：在 Lua 中处理货币时，tonumber 默认转为浮点数。在生产环境中，严禁直接使用 Float 存储金额。建议将金额放大100倍（转为分）作为整数存储，或者使用 Redis 的 GEORADIUS 等特定结构（不推荐用于金额），最稳妥的是使用 String 存储整数分位，在应用层转换。上述代码为了演示简洁做了简化，实际项目中请务必修改为整数运算。
异常捕获：Redis 连接超时是常态，必须捕获 RedisError，并记录详细日志，绝不能让异常直接抛给前端，否则用户会看到 500 错误，体验极差。运行与测试：验证一致性
代码写完只是开始，测试才是新手避坑的核心环节。
1. 环境启动
使用 docker-compose 一键启动 Redis 和 Python 服务。
# docker-compose.yml
version: '3.8'
services:redis:image: redis:7-alpineports:- 6379:6379app:build: .ports:- 8000:8000environment:- REDIS_HOST=redisdepends_on:- redis2. 并发压力测试脚本
我们需要模拟 100 个用户同时下单，验证余额是否会出现负数或持仓错误。
# tests/test_concurrent.py
import asyncio
import httpx
from app.models.order import OrderSide, OrderRequestasync def send_order(client_id: str, side: OrderSide, price: float, qty: float):url = http://localhost:8000/orderspayload = {order_id: fORD-{client_id}-{asyncio.get_event_loop().time()},symbol: EURUSD,side: side,price: price,quantity: qty,client_id: client_id}async with httpx.AsyncClient() as client:response = await client.post(url, json=payload)return response.json()async def main():# 初始化 100 个用户，每个余额 10000# 这里省略初始化 Redis 数据的代码tasks = []for i in range(100):# 每个用户下 10 单，总数量 1000 单for j in range(10):tasks.append(send_order(fuser_{i}, OrderSide.BUY, 1.1, 100))# 并发执行results = await asyncio.gather(*tasks)# 统计结果filled = sum(1 for r in results if r['status'] == 'FILLED')rejected = sum(1 for r in results if r['status'] == 'REJECTED')print(fFilled: {filled}, Rejected: {rejected})# 关键校验：检查 Redis 中所有用户的余额总和是否守恒# 这里需要读取 Redis 进行断言if __name__ == __main__:asyncio.run(main())测试发现的一个典型 Bug：
在初次测试中，我发现部分订单被拒绝，原因是 Lua 脚本中 DECRBY 不支持浮点数。当我把金额改为整数后，问题消失。这就是为什么官方文档太长你抓不住重点的原因——它不会告诉你 DECRBY 只能处理整数。
优化扩展与进阶技巧
系统跑通了，但还不够。
1. 引入消息队列解耦
当前架构中，撮合完成后直接返回结果。但在真实高并发场景下，审计日志写入数据库可能会阻塞撮合线程。
优化方案：
引入 RabbitMQ 或 Kafka。撮合成功后，将订单信息发送到 MQ，由独立的消费者服务异步写入数据库。这样撮合引擎只负责计算，不关心持久化，性能提升 30% 以上。
2. 行情数据的处理
当前代码中，价格是由客户端传入的。这在真实交易中是致命错误。
正确做法：客户端只能提交“限价单”或“市价单”。
服务器端维护一个行情订阅服务，从第三方数据源（如 Binance WebSocket）获取最新价格。
撮合引擎在匹配时，必须使用服务器端当前最新价格，或者严格检查客户端限价是否在允许滑点范围内。代码片段示意：
# app/services/market_data.py
class MarketDataService:def __init__(self):self.latest_prices = {} # {symbol: price}self.lock = asyncio.Lock()async def update_price(self, symbol: str, price: float):async with self.lock:self.latest_prices[symbol] = pricedef get_price(self, symbol: str) - float:return self.latest_prices.get(symbol, 0.0)3. 监控与告警
在 main.py 中集成 Prometheus 指标：order_processing_latency_seconds：直方图，监控延迟分布。
order_rejection_total：计数器，监控拒绝原因。当拒绝率超过 5% 时，触发告警。这可能是行情异常或系统负载过高的信号。
小结与岗位边界
通过这个项目，你不仅搭建了一个撮合引擎，更理解了金融后端开发的几个核心逻辑：原子性：涉及资金操作，必须使用原子机制（Lua、事务、锁）。
幂等性：订单 ID 必须唯一，重复请求不能导致重复扣款。
审计合规：每一笔变动都要可追溯，日志是法律证据。岗位日常职责边界：
作为后端开发，你的职责是保证系统的稳定性与数据一致性。不要做：不要自己定义行情算法，不要绕过风控模块直接写库，不要在没有测试的情况下上线核心逻辑。
要做：写好单元测试，配置好监控告警，详细记录每一行代码的变更原因。很多新手觉得炒外汇系统很神秘，其实拆开看，就是高并发 + 强一致性 + 严格合规的工程问题。技术本身不难，难的是对细节的敬畏。
这个知识点你面试被问过吗？
特别是“如何在高并发下保证订单不超卖”或者“Redis Lua 脚本的局限性”，留言说说你的看法。如果是你，你会选择用 Redis 还是直接上数据库事务？