关于排队机内存定序

来源：9-6 定序和小结

慕少4057723

2023-10-19

请教下老师实际生产环境定序逻辑是否也是如课程中提到的这样的方式呢？这里有两个小问题，可能问的不太专业，还请麻烦您看下

1.关于定序操作在内存中完成的疑问：排队机leader节点会从各个gateway 收集委托订单数据（gateway-1,gateway-2…gateway-N）,如果订单量比较大，比如收集到 gateway-M 的时候，有没有可能出现排队机内存不够的问题，造成无法继续完成后续收集的任务，或者实际排队机内存超级大，生产中根本不需要考虑这个问题？

2.排队机定序操作在在内存中排序的过程中，排队机进程crash掉了或者断电重启等造成本次定序失败，后续排队机集群重新选择一个新的leader的再去（gateway-1,gateway-2…gateway-N）收集委托订单，但是此时以前定序失败的那些委托订单已经找不回来了，因为之前那个排队机拉取委托单的时候，gateway的内存队列已经清空了，那么这种情况需要如何处理呢，如何重新来处理以前定序失败的那些老的委托单呢。实际您的架构设计这块是采用怎样的一个补偿方案呢？

写回答

1回答

Gudy

2023-10-19

排队机是内存和磁盘相结合的，它主要作用是给委托订单打上编号（这个编号是全局递增的）并发给撮合模块，之后排队机就会把这个单子写磁盘，写数据库或者写到其他非易失的存储介质中，因此不需要很大的内存。
raft排队机其实不存在单点失效的问题，因为一笔委托能成功进排队机，raft集群已经把这笔委托同步到所有的排队机了，所以一台坏了不会导致以前的委托订单。

慕少4057723

请教老师，raft 一致性我理解是只有数据在大部分节点完成同步了，此时就是真正写入成功了哦但是排队机的逻辑是抓单-->定序-->insertToKvStore(入库) ，所以我的问题是抓单-->定序完成了但在insertToKvStore之前，节点crash 了，此时实际上数据还只是在leader节点，并没有完成同步呢吧，所以这种情况下以前的委托订单是否会丢失呢？

2023-10-19

共2条回复

SpringCloud+Vertx+Disruptor 撮合交易系统实战

独家掌握金融业务系统知识，培养金融IT工程师核心竞争力

469 学习 · 145 问题

查看课程

相似问题

关于排队机定序问题，再请教下老师

回答 1

请问撮合系统如何做到高可用的？Disruptor在撮合系统中作用是什么？

回答 3

请问：排队机与网关之间通信选型，为什么使用RPC通信，而不选择前面已经写好的TCP通信？这里选择RPC有什么特别的优势呢？

回答 1

请教老师下实际生产环境也是用自研的kv存储吗？

回答 1

老师，关于撮合系统还有以下四个疑问，麻烦抽空回答下，谢谢

回答 1

打开慕课网App查看更多内容