- 博客(291)
- 收藏
- 关注
RSS订阅原创 跟单业务订单分库分表
摘要：Gate.io跟单业务采用"用户ID哈希分库+时间分表"架构设计，应对日均20万订单的高并发场景。通过user_id%4算法分4个库，按月分表实现数据水平拆分。该方案具有高扩展性、查询高效（支持用户/时间双维度定位）、便于数据归档等优势。当前系统已处理超1.5亿订单，有效解决了单表千万级数据瓶颈和多维度查询问题，保障了系统稳定性和未来扩展需求。
2025-06-01 00:47:18
425
原创 跟单业务并发量分析
虚拟货币交易所跟单业务并发量分析 跟单交易在虚拟货币交易所中具有显著的"并发洪峰"特性，主要特点包括： 触发集中：主交易员下单瞬间触发所有跟随者订单 交易同步性强：需要毫秒级同步成千上万个跟随账户 根据交易所规模，高峰下单并发量差异明显： 小型交易所：1,000~5,000 QPS 中型交易所：10,000~50,000 QPS 大型交易所：100,000+ QPS 以Gate.io为例估算： 假设100名交易员同时操作，每人1000跟随者 每分钟产生20万次跟单请求 折合3,300~6
2025-05-31 23:11:45
1001
1
原创 跟单业务和量化交易业务所涉及到的设计模式
📌 金融系统设计模式应用摘要 在跟单业务中，观察者模式实现大V与跟随者的异步订单同步，策略模式灵活处理不同跟单方式，责任链模式完成风控校验流程。量化交易系统更复杂，常用策略模式切换交易策略，模板方法固定执行流程，命令模式封装订单操作，工厂模式选择交易通道，状态模式管理订单生命周期，装饰器模式增强策略功能，单例模式确保全局服务唯一性。这些模式有效解耦系统组件，提升扩展性和可维护性，面试时可结合具体技术栈（如消息队列、AOP、IoC容器）展现设计深度。
2025-05-31 18:16:56
650
原创 Pod 节点数量
在 Kubernetes 中，量化交易系统的 Pod 副本数是否变化取决于多个因素。如果设置了可伸缩控制器（如 HPA、VPA 或自定义控制器），默认副本数为 5 的情况下，副本数可能因资源不足、负载升高等原因自动扩容，也可能因负载低而缩容。具体来说，CPU 或内存使用率超过阈值、消息堆积、延迟上升或并发请求量猛增都可能触发扩容；而 CPU 或内存使用率长期低于阈值、消息消费滞后清零或请求量减少则可能触发缩容。默认值 5 并非最小值，除非显式设置 minReplicas: 5，否则副本数可能低于 5。对于广
2025-05-19 17:29:07
331
原创 Kafka 中过多的 topic 导致整体上性能变慢的原因
在 Kafka 中，过多的 topic 数量会对整体性能产生显著影响，主要原因包括： 资源消耗增加：每个 topic 的分区会占用文件句柄、内存、线程调度和操作系统资源，导致系统负担加重，性能下降。 Controller 压力增大：Controller 需要管理所有 topic/partition 的元信息，频繁处理元数据变更和大规模重平衡，导致集群稳定性下降。 客户端压力上升：生产者和消费者在启动时需要加载大量元信息，初始化、元数据刷新和负载分配耗时增加，监控工具也会变慢。 垃圾回收压力加大：分区多导致
2025-05-15 19:24:11
477
原创 SpringBoot 自动装配流程
Spring Boot 的自动装配（Auto Configuration）是其核心特性，通过 @EnableAutoConfiguration 注解启用，配合 AutoConfigurationImportSelector 类动态加载配置类。这些配置类通常从 META-INF/spring.factories 或 spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件中读取，并通过 @Conditional 系列注
2025-05-15 19:11:22
713
原创 Kubernetes 中 Pod 节点相关问题
在 Kubernetes 中，Pod 的名称是否变化取决于其创建方式。手动创建的裸 Pod 在重启后不会自动恢复，名称可能变化；由 Deployment 管理的 Pod 在重启后会重建，名称会变化；而 StatefulSet 管理的 Pod 名称保持不变。生产环境中，Deployment 是最常用的无状态服务部署方式，StatefulSet 用于有状态服务，DaemonSet 用于节点级守护进程，裸 Pod 不推荐用于生产。Pod 中通常运行一个主容器，但在需要辅助功能时也可运行多个容器（如 Sidecar
2025-05-15 14:51:13
760
原创 Redis 大 key 问题解决方案
在 Redis 中，“大 key”问题（如字符串过长或数据结构元素过多）会导致性能问题，如阻塞主线程、复制开销大、慢日志和内存碎片等。识别大 key 可通过 MEMORY USAGE、SCAN 脚本、redis-cli --bigkeys 工具或监控工具。解决方案包括：1) 拆分大 key 为多个小 key；2) 分页访问数据结构；3) 避免一次性删除大 key，使用异步或分批删除；4) 合理设计数据结构，避免超大数据；5) 开启 Lazy-free 模式支持后台异步删除；6) 设置 TTL 控制过期。此外
2025-05-15 14:10:24
450
原创 量化交易系统技术方案设计
策略实例的生命周期包括创建、启动、暂停、恢复、终止和异常等阶段。在Java中，可以通过策略实例管理器来统一调度这些生命周期，使用ConcurrentHashMap来管理活跃的策略实例，并提供启动、停止、暂停和恢复等方法。策略状态的持久化与恢复可以通过Redis或数据库实现，确保系统重启时能够恢复策略状态。Redis在量化交易系统中适用于策略配置缓存共享、策略状态同步、分布式协调与调度以及订阅推送等场景，但不适合存储复杂、有状态的Java对象或高频调度核心逻辑。最佳实践是采用本地内存与Redis协同的方案，将
2025-05-12 01:30:10
779
原创 Kafka topic 中的 partition 数据倾斜问题
某些 Partition 接收到大量消息，而其他 Partition 接收很少甚至没有；导致部分 Kafka Broker 压力过大；消费端负载不均，有的 Consumer 处理不过来，有的却很空闲；严重时会造成消费延迟、系统资源浪费甚至服务不稳定。
2025-05-11 19:13:06
925
原创 量化交易策略的运行
问题现实是否需要写几十万个策略类？❌ 不需要需要写多少？通常 10～50 个“策略模板类”足够每个实例怎么来？通过参数 + 模板动态创建这样会不会耦合很高？用策略模式 + 工厂解耦很好支持扩展吗？非常灵活，添加新策略类只需注册即可方法是否推荐原因每个策略开一个线程❌ 不推荐极度浪费资源，线程调度开销大使用线程池调度✅ 推荐限制线程数量，高并发低资源占用批量处理策略实例✅ 推荐能更好地调度资源，适合超大规模系统使用协程（如 Kotlin）或 Reactor。
2025-05-09 16:00:33
863
原创 为什么消息队列系统不像数据库系统那样可以配置读写分离？
特性消息队列数据库（Redis/MySQL）是否可读写分离❌ 一般不行（顺序/偏移敏感）✅ 可读写分离（副本滞后容忍）副本的作用容灾，高可用查询负载均衡 + 容灾是否能接受滞后读否是消费是否有状态有状态（消费偏移）无状态（SELECT 查询）
2025-05-09 15:20:26
383
原创 量化策略兼容性设计
/ 策略名称（对应 Spring Bean 或脚本名）// 策略类型 (JAVA / DSL / SCRIPT)// 策略参数数据库策略数据结构示例idparams1JAVA2SCRIPT3customDslDSL4PYTHON总结：执行 Spring 管理的 Java 策略。：执行自定义 DSL 策略（你可以通过 DSL 解析器来扩展）。：执行脚本语言策略（如 Groovy、JavaScript）。：调度器负责选择并执行正确的策略执行器。
2025-05-08 15:07:45
630
原创 量化交易系统和量化策略
项目量化交易系统量化策略本质软件系统策略逻辑功能自动化执行策略决定交易决策依赖关系执行多个策略需要系统来运行示例Hummingbot、私有Bot系统网格、套利、趋势策略等功能所属系统是否属于量化交易系统内部行情系统交易所（外部）❌（不属于）但需要接入数据采集模块量化交易系统内部✅（接收行情数据）风控系统（如强平）交易所平台风控❌（你无法控制）风控逻辑模块（如止损）量化交易系统内部✅（你必须自己写）风控位置属于交易所平台可否依赖实际用途。
2025-05-07 11:06:59
481
原创 Elasticsearch 8.x 在 java 中的使用情况
在 Java Spring Boot 微服务中集成，推荐使用官方的（不同于 7.x 的 High Level REST Client）。以下是。
2025-05-07 10:35:14
538
原创 JDK 发展历史及其版本特性
JDK（Java Development Kit，Java开发工具包）是用于开发Java应用程序的核心工具之一。它由Oracle（最初由Sun Microsystems）提供，包含了Java编译器、Java运行环境（JRE）、Java标准类库等。
2025-05-06 22:35:59
885
原创 Java 中的 HashMap 详解
在 Java 中，如果你使用 并且不指定容量，它会使用默认的初始容量为 16，负载因子（load factor）为 0.75。等价于：默认初始容量（Initial Capacity）：16默认负载因子（Load Factor）：0.75当 中的元素数量超过 （即 16 × 0.75 = 12）时，就会触发**扩容（resize）**操作，容量会翻倍为 32。如果你在 Java 中使用 并指定容量为 50，例如：这表示你希望这个 至少能容纳 50 个键值对而不发生扩容，但这并不意味着底层
2025-05-05 23:27:23
728
原创 微服务系统设计
微服务设计是一种“系统性工程”，建议从业务出发、按领域拆分、合理控制粒度，并引入必要的基础设施如服务网关、服务注册发现、配置中心、监控告警等。
2025-05-05 17:26:57
616
原创 雪花算法中的时针回拨问题
轻量应用：使用逻辑时间戳 + 5ms 容忍机制，性能高、风险小核心系统：引入持久化、集群协调（如 Leaf 或 Redis + Zookeeper）高可用系统：多机房、ID 服务集群、避免单点。
2025-05-05 17:00:47
925
原创 Nacos 中的临时节点和永久节点
问题答案Nacos 是否有临时/永久节点？✅ 有，分别为 ephemeral=true / false默认是哪种？✅ 默认是临时节点（ephemeral=true）哪种更可靠？看场景：临时节点适合动态服务，永久节点适合静态服务如何切换？注册时通过设置来注册永久节点项目临时节点（ephemeral = true）永久节点（ephemeral = false）心跳机制✅ 需要❌ 不需要是否自动下线✅ 是，超时后自动剔除❌ 否，需手动删除存活判定依据心跳包永久保留。
2025-05-03 16:59:34
844
原创 Nacos 中的 AP 和 CP 模式
功能模块一致性模型默认行为服务注册与发现偏 AP最终一致性为主配置管理偏 CP使用 RaftNacos 1.xAP高可用优先Nacos 2.x混合 AP/CP支持 Raft 模式Nacos 是一个“默认偏向 AP、部分场景可支持 CP”的系统。使用 Nacos 2.x 并开启 Raft 模式时，某些核心功能（如配置中心）可以达到 CP 级别的一致性保障。
2025-05-03 16:45:45
418
原创 交易所常见订单类型
订单类型成交条件用途限价单（Limit）达到目标价成交常规交易、挂单策略市价单（Market）立即按市价成交快速进出市场止损市价单达触发价，市价卖止损保护止损限价单达触发价，限价挂单精准控制风险跟踪止损单动态调整止损动态止盈、追涨保利冰山单部分显示订单大额交易隐蔽执行止盈单达设定价位卖出锁定利润委托单（Order）：是用户提交给交易所的交易请求，用于指定买入或卖出的方向、数量、价格及条件。
2025-05-01 19:52:54
951
1
原创 MySQL 从单库单表向分库分表的平滑过渡
问题建议写入漏写（新库未写）加强双写日志或链路追踪数据不一致使用校验工具对账 + 定期 checksum查询分页异常分表分页需重新设计，如用时间戳游标等跨库事务困难避免强一致事务，改为最终一致性方案回滚困难保留旧表一段时间，便于快速回滚抽象数据访问逻辑；引入路由中间层；配合双写+灰度+校验机制；保障可回滚能力。
2025-05-01 14:28:21
643
原创 Mysql 在什么样的情况下会考虑分库分表？
单表行数超过1000 万查询频繁出现慢查询（优化后仍无改善）每天数据量增加超过数十万条并发写入和查询造成明显性能瓶颈才真正考虑使用分库分表，避免过早优化导致复杂度升高。
2025-05-01 14:14:50
412
原创 如果 Nacos 宕机，依赖它的微服务还能不能成功启动？
功能角色Nacos宕机影响服务能否启动注册中心注册失败，调用受限✅（默认可启动）配置中心依赖配置加载情况✅ 或 ❌（取决于 fail-fast 与本地缓存）
2025-05-01 01:55:29
419
原创 Nacos vs Eureka
需要注册中心 + 配置中心一体化；使用 Spring Cloud Alibaba；需要多环境隔离、灰度发布、动态配置等高级功能。项目较老，依赖 Spring Cloud Netflix；不需要配置中心功能；功能需求简单、部署轻量。
2025-05-01 01:44:33
320
原创 跟单业务收益率
普通用户跟随某位交易员下单后的资产变化情况，用于衡量跟单投资是否带来了盈利。虚拟货币跟单业务中的“收益率”既是交易员绩效指标，也是用户投资决策依据。平台需要真实、透明、及时地计算和展示这些收益率指标，同时建立防刷机制，避免误导用户。Java 实现“跟单收益率功能”本质上是一个资产追踪 + 收益计算 + 排行榜展示的系统，涉及定时任务、数据存储、历史快照、数学计算和接口层。
2025-04-29 21:52:54
569
原创 跟单业务中的分润功能
是否建议用定时任务计算分润？| ✅ 是，主流方式 || 是否可以实时？| ⚠️ 一般不建议，除非需求强制要求 || 定时任务触发频率？| 建议每 5~30 分钟或每日定时（按业务粒度调整） |方案是否推荐备注单节点@Scheduled❌ 不推荐多实例部署会重复执行Redis分布式锁 +@Scheduled✅ 可用适合轻量任务，代码量少XXL-JOB / Elastic-Job 等✅✅ 推荐。
2025-04-29 18:56:04
739
原创 大批单分批成交
大单提交到撮合引擎时，一般会分批成交。每批的成交价格可能不同，最终组成这笔大单的完整成交。跟单时机是否推荐说明每一小笔成交立即跟单❌ 不推荐易碎片化、手续费高、滑点大等整单成交完毕后统一跟单✅ 推荐价格更稳定，执行更统一部分成交达到一定比例后跟单➡️ 可选需要防止偏离太大成交顺序问题就是指撮合系统成交是有顺序的，但因为异步推送，跟单系统收到成交消息的顺序可能是乱的，所以必须缓存+按时间戳/成交ID重新排序，才能正确、安全地处理跟单动作。带单员大单发出↓跟单系统监听带单员成交明细。
2025-04-29 15:31:49
1020
原创 Redis 主从节点下写入数据问题
Redis 集群本身不提供直接的机制来确保在写入数据时所有主从节点都同步确认写入。WAIT命令：等待一定数量的从节点确认写入。AOF 持久化：确保数据持久化到磁盘。事务：通过MULTI/EXEC确保操作原子性。但对于 Redis 集群来说，真正的主从节点同步确认需要在应用层进行更多定制化处理。在高可用性和分布式架构下，完全的同步确认往往会影响性能，因此大多数应用会选择在数据一致性和性能之间做折衷。主节点挂掉前如果还没同步到从节点，是有可能丢数据的。因为 Redis 默认是异步复制。
2025-04-28 14:26:31
1370
原创 如果 WebSocket 断开了，交易所一般怎么处理行情和订单同步补偿？
步骤处理方法发现断开立即重连WebSocket补拉快照用HTTP API拉最新快照（订单簿或账户信息）衔接增量应用快照后收到的WebSocket增量消息补齐同步本地数据和服务器一致后继续实时推送✅ 这样就算WebSocket断了，也能完整同步，不漏数据。✅ 这是币圈交易所设计稳定跟单系统、做市系统时必须要做的防护措施。Session复用，也叫连接恢复（session resume）你WebSocket断开后，重新连接时，不用从头订阅所有内容。而是带上。
2025-04-28 10:23:27
1020
原创 分布式架构下的多级缓存问题
在单体应用或少量副本、变化少的集群里，本地缓存分片（比如用Caffeine、EHCache）还能凑合用。但在现代微服务、弹性伸缩（AutoScaling）、高并发、大规模场景下，依赖Pod分片+本地缓存很高的复杂度很难维护的一致性很容易出问题的边缘场景扩缩容代价大灰度发布/滚动更新时容易出错Pod本地缓存分片，想法很好听实现成本极其高维护风险也极大。在现代分布式微服务里，越来越多的人选择牺牲一点本地缓存的极致性能，换取系统整体的可靠性和一致性。
2025-04-27 18:45:38
816
原创 CAP 原则
P（Partition）指的是分布式系统中部分节点之间因为网络故障而无法通信的现象。分布式系统必须具备在这种情况下保持生存和服务的能力。分区一定会发生，所以 CAP 理论中 P 是必选的，剩下的只能在 C（一致性）和 A（可用性）中做取舍。A：Availability，可用性。每一个对系统发出的请求，不管当前系统部分节点是否故障，都必须在合理时间内给出响应（不挂掉、不超时）。能响应响应及时系统每个非故障节点在有限时间内必须对每个请求作出响应（成功或失败的响应）。响应并不要求一定是正确的！
2025-04-26 18:20:18
721
原创 分布式微服务数据库
问题答案每个微服务有独立数据库吗？✅ 应该有，遵循“数据库私有”原则同一个微服务的多个 Pod 副本用同一个数据库吗？✅ 是的，副本共用同一个数据库连接一个微服务（user-service）├── 多个 Pod 副本（Pod1，Pod2，Pod3）│ └── 都访问同一个数据库（user_db）其他微服务（order-service, product-service）├── 自己有自己独立的数据库（order_db, product_db）
2025-04-26 17:09:17
313
原创 Kubernetes 分布式集群部署微服务
✅ 如果你要用 K8s 部署微服务，并做集群部署，那你这个微服务就会运行在多个 Pod 中，每个 Pod 是同一个服务的一个副本，用于实现高可用、负载均衡和弹性扩容。在 Kubernetes 中，即使你有多个微服务实例（Pod），它们对外通过Service 暴露的是统一的 IP 和端口，由 K8s 自动进行负载均衡和服务发现。NodePort简单粗暴，适合云上直通公网，Ingress是功能最强大的入口网关，适合微服务架构下的生产环境。
2025-04-26 16:52:36
733
原创 量化交易系统和撮合引擎系统
模块定义主要作用量化交易系统使用算法、策略模型自动进行买卖决策和下单操作决策层，负责“交易策略”和“下单行为”撮合引擎（Matching Engine）负责接收订单并根据价格优先、时间优先等规则撮合成交执行层，真正完成“订单成交”在币圈，量化交易系统是独立于撮合引擎的一层，它主要负责执行交易策略、生成订单、提交给撮合引擎；而撮合引擎是执行核心，负责订单的撮合成交。两者配合实现完整的自动交易闭环。“行情系统”和“撮合引擎”是输入输出最核心的两个环节“账户系统”是下单前的权限和额度判断“风控”
2025-04-26 15:31:51
778
原创 了解常用的数据结构和算法，并能应用于解决实际问题
掌握这些常见的数据结构和算法能够帮助我们高效地解决各种实际问题。在实际编程中，选择合适的数据结构和算法，能够显著提升程序的执行效率和可维护性。通过不断练习和优化，能更好地应用这些知识。
2025-04-25 09:30:44
449
原创 风控业务分析
电商风控是一场永无止境的“猫鼠游戏”：风控团队不断升级武器，黑产不断挖掘漏洞。技术要跟得上，策略要灵活，体验不能差，真是“又要马儿跑，又要马儿不吃草”。
2025-04-21 16:45:18
707
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人