Boring Blog
KK限制方案
KK的限制和使用哪个API无关，Rest Websocket 和Fix 共享同一个限频规则。
Rate of transactions（Main）
基本概念:
阈值:计数器能达到的最大值，取决于用户等级
计数器:当
衰减数:每秒钟计数器衰减的数量，取决于用户等级，当计数器不为0的时候，就会每秒进行一次递减 t * count。
等级参数:
1.start tier:
阈值：60 衰减数:1
2Intermediate Tier
阈值：125 衰减数:2.34
3Pro Tier
阈值:180 衰减数：3.75
初始化订阅订单websocket下单时从subscribe消息中可以获取到当前的阈值以判断当前的用户等级。
订单推送回来之后可以获取到ratecount来判断当前的衰减情况
根据用户等级设置参数:
再设置一个刹车空间阈值:
保留值:save_num
阈值:180
衰减数:2.35
传来count 之后记录当前的计数器数值count
count = n;
并记录count的时间record_time;
检查本次操作是否超频:
local_time - record_time = time_span // 上一次记录到当前的时间差
recover_num = time_span * 衰减数 // 计数器递减的值
real_count = count - recover_num // 当前计数器的真实值 计算得出
如果save_count > 阈值 - real_count 就限制访问接口
KC限制方案
Rest
Rest当前的限频规则为2.0版本，关于spot交易根据不同的vip等级会有不同的token数量,但是使用的算法是time window算法。
就目前看来VIP12 在30s内可以拥有40000token
请求头中会返回如下信息:
1 最多限制"gw-ratelimit-limit"：Max_Limit
2 剩余限制"gw-ratelimit-remaining"：Remain_Limit
3 周期重置时间"gw-ratelimit-reset":Rest_Time
因此可以按照如下策略限频:
设置刹车数值:Save_Count
下单和查询订单：均需要消耗Token=1
下单之前检查最近一次的Remain_Limit - Save_Count >= 1
如果符合条件就去下单
Websocket下单
websocket目前文档中未给出下单的限制,但是当前对于上行消息有限制,100条/10s 认为是time window 算法。若是该种限制可以使用特殊的token bucket算法进行限制。
2025.6.12
目前核实到websocket依然采用的是rest的限频规则，在订单推送之后,限频的上下限和周期剩余时间会在最近一次的订单明细中推送，且不受到正常websocket上行100条/s的限制。
{"id":"request-001""op":"spot.order""code":"20000""data":{"orderId":"123456","clientOid":"5c52e11203"}"inTime":1695190491421,"outTime":1695190491444,"rateLimit":{"limit":1600,"reset":15244,"remaining":1528,}
}
MX限制方案
1Rest限频
Rest限频目前主要是根据：
1IP
2UID
两种模式分别进行统计,二者相互独立,分别共用500权重/10s。
10s作为一个周期
IPtoken池1:500 权重
UIDtoken池:500 权重
已知 资产读取1times/s 资产获取需要IP权重 10,
因此固定周期内IP token池为400权重
查询订单需要IP权重2
下单 需要账号权重1和IP权重1
即理想情况下，单账户至多在10s内下400单。
从交易所核实到当前使用的是sliding Time window算法，目前多账户下无法处理限频问题，除非多账户统一管理。
最简单的方法就是多账户均分时间窗口内的权重,这样这样无需关心其他人的使用情况，不会造成超频的情况，但是可能大家的需求不同，有的人可能会浪费掉一些权重。
CB限制方案
首先Rest和Fix是完全独立的两个方案。Rest采用token bucket的限制模式，Fix则是time window的限制模式
Rest
CB的token bucket 有两个关键值:
burst和refresh_rate
burst即token_bucket的阈值
当前token的计算公式为
min(burst,previous_token + time_span * refresh_rate)公共节点的burst=15 refresh_rate=10
私有节点的burst=30 refresh_rate=15
Fix
Fix采用的是time window的限频规则
当你的第一条请求为0.0005s 是 截至 1.0005s 这个窗口内只能发送100条请求，
当请求超过200的时候就会断开fix连接