常见分布式应用系统设计图解(十二):证券交易系统

标签: System and Architecture 交易系统 图解笔记 应用系统 系统设计 | 发表时间:2020-12-27 02:09 | 作者:四火
出处:https://www.raychase.net

这篇讲的是证券交易系统,这类系统包含的内容很多,但是我们还是把目光放在核心的交易部分,比如说股票交易。在某个可交易时间,如果卖家 A 要以至少 y 的价格卖掉股票 x,卖家 B 愿以至多 y 的价格买入股票 x,那么这个交易就可以发生。

虽说是交易系统,但是它和任何一个支付平台的交易系统有着显著的不同,它的核心是一个竞价匹配的机制,而非货币支付的机制,简单地说,这个机制包含了这样四个步骤:

  • 挂单(可以是买单,也可以是卖单)
  • 匹配(或者叫做撮合)
  • 成交
  • 清算

从非功能的角度看,有这样几条需求是这样的系统尤其要强调的:

  • Consistency,从单个交易的角度来说,主要就是事务性,这是交易系统最最基本的要求。系统不能用了是个灾难,但是如果交易数据错误了这就是个大得多的灾难。
  • Durability,交易数据必须要持久化。
  • Throughput,很多股票市场都是对全球开放的,吞吐量意味着对于交易高峰的接纳能力。
  • Latency,和吞吐量关系密切,可以放在一起讨论。大型交易系统的延迟的最小单位都是 按微秒论的。从架构上看这类系统具备一些异步系统(比如下单支付系统)的特点,但是低延迟的要求决定了它的处理方式明显不同。
  • 整个系统来看,包括挂单、匹配、交易和查询这样几个部分。实线部分表示的是写或读写操作,虚线是读操作。
  • 假设有卖家和买家两个用户,分别在不同的时间提交了挂单请求,一个是卖单,一个是买单。
  • 鉴权分为两个部分来完成,基础的部分由 API Gateway 来完成。
  • Exchange Server 收到原始挂单请求以后,首先调用 Sequencer 去获取一个时间戳,也包括一个基于时间戳生成的 ID。这个时间戳非常重要,因为交易的逻辑里面,对于买单卖单的匹配,以及同价单的优先级,都要基于时间戳的规则来进行。时间戳不能仅仅基于 Exchange Server 自己的时钟来进行,因为每台机器的时钟很可能都不一样。
  • 对于买单,查询账户系统并扣住保证金。
  • 将买单或卖单放入指定的队列,不同的股票有不同的队列来维护。这个队列本身是一个优先级队列,从宏观上看就是 order book。对于买单来说,买价越高越靠前;对于卖单来说,卖价越低越靠前。
  • 不同队列的变更会被 router 通知到不同的匹配(撮合)引擎,这里有多个不同的引擎,每个引擎关注不同的队列变更。在每个引擎的内存中维护一个队列中靠近队列出口的买卖单集合,也是以优先级队列的形式维护在内存中(具体实现可以是堆)。
  • 这样迅速的匹配就可以在内存中迅速发生并完成,内存的数据结构以 Snapshot + WHL 的方式持久化,以达到效率和状态不丢失的平衡。
  • 如果这台机器崩溃,还有集群中的备用机可以顶上,并从上述的 Snapshot + WHL 中恢复之前的状态。这些机器都通过 Node Manager(比如 Zookeeper)来管理。
  • 每次匹配完成,都有一个事件加入到 exchange 的队列中,每只股票都有自己的 exchange 队列。
  • Router 将队列的事件通知到相应的支付系统和 Tick Calculator。支付系统(或者是清算系统)会完成用户扣款或打款的操作,而 Tick Calculator 会根据交易信息改变当前的股价并持久化到数据库中(这里的数据库需要较大的吞吐量,可以根据股票种类+时间序做 sharding)。
  • 用户可以查询自己的账户变更状况,用户也可以通过 Quotation 系统查询股价变更状况。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

相关 [常见 分布 应用] 推荐:

常见分布式应用系统设计图解(十二):证券交易系统

- - 四火的唠叨
这篇讲的是证券交易系统,这类系统包含的内容很多,但是我们还是把目光放在核心的交易部分,比如说股票交易. 在某个可交易时间,如果卖家 A 要以至少 y 的价格卖掉股票 x,卖家 B 愿以至多 y 的价格买入股票 x,那么这个交易就可以发生. 虽说是交易系统,但是它和任何一个支付平台的交易系统有着显著的不同,它的核心是一个竞价匹配的机制,而非货币支付的机制,简单地说,这个机制包含了这样四个步骤:.

常见分布式负载均衡工具介绍nginx lighttpd haproxy

- - 互联网 - ITeye博客
       在架构系统的时候,通常会涉及到分布式,而处分布式里面最前端的是负载均衡器(当然还有cdn). 在网上搜寻一份,对目前常见的负载均衡器做一些介绍和常见组合,不涉及具体配置. 第一种是常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器,它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,所以对于规模较小的网络服务来说暂时还没有需要使用;.

常见的iOS手机应用开发流程

- - Tech2IPO
iOS应用开发无疑仍会是未来一段时间内的热门,因此,不管是对开发者还是企业管理人员来说,或多或少了解一些应用开发流程十分有必要,本文涉及的大部分内容并不局限于iOS应用,同时也适用Android、Windows Mobile和Blackberry等其他移动平台. iPhone应用的开发并不是一个简单的过程,建议按照以下步骤逐条考虑:.

Android 应用中十大常见 UX 错误

- - 互联网的那点事
Android 开发者关系团队每天都会试用无数的 App 或者受到无数的开发者发来的请求评测的 App,在评测如此之多的应用之后,他们总结出了10个最常见的错误. 作为一个长期使用 Android 的用户,我在使用 Android 应用的时候经常遇到各种各样的交互上的问题,并且早就想整理它们写一篇文章了.

常见算法在实际项目中的应用

- - 博客 - 伯乐在线
近日Emanuele Viola在Stackexchange上提了这样的一个问题,他希望有人能够列举一些目前软件、硬件中正在使用的算法的实际案例来证明算法的重要性,对于大家可能给到的回答,他还提出了几点要求:. 使用这些算法的软件或者硬件应该是被广泛应用的;. 例子需要具体,并给出确切的系统、算法的引用地址;.

web图像的常见应用策略与技巧

- - 腾讯ISUX – 社交用户体验设计
本文介绍一些关于响应式图像的适配应用策略,回退原理,SVG的换色技巧,雪碧图的百分比定位计算公式等相关的一些小知识点,目的在于帮助一部分同学快速的理清图像应用思路,以及一些web图像的应用技巧. 1.响应式图像的应用与回退. 特点:应用简单,上手容易,性能表现良好. 根据不同设备,不同分辨率,不同像素比使用的响应式图像,常用的有两种场景:.

分布式事务解决方案常见误区与实用建议

- -
最近,工作中要为现在的老系统做拆分和升级,刚好遇到了分布式事务、幂等控制、异步消息乱序和补偿方案等问题,刚好基于实践结合个人的看法记录一下一些方案和思路. 首先,做系统拆分的时候几乎都会遇到分布式事务的问题,一个仿真的案例如下:. 项目初期,由于用户体量不大,订单模块和钱包模块共库共应用(大war包时代),模块调用可以简化为本地事务操作,这样做只要不是程序本身的BUG,基本可以避免数据不一致.

列举web应用程序设计中常见的10种错误

- - GamerBoom.com 游戏邦
作者:Jakob Nielsen. 撰写有关应用程序设计错误的文章是件很困难的事情,因为最糟糕的错误往往具有领域专门性和特殊性. 通常情况下,应用程序的失败有以下3种原因:解决了错误的问题;目标问题正确,但使用的是错误的功能;功能设计正确,但过于复杂使得用户难以理解. 这3个错误都可能导致应用的失败,而我却还无法告诉你怎么做才是正确的.

基于twemproxy的redis分布式应用

- - 数据库 - ITeye博客
根据以往的测试结论,单个redis的实例的内存总量最好控制在8G以内(最大不能超过20G),而实际上应用对redis的内存的需求可能会远远大于8G,因此需要一个保持redis server性能不下降,但可以有效扩充redis server的容量的方案. twemproxy是一个恰当的选择. twemproxy,也叫nutcraker.

分布式应用框架 Dapr

- - IT瘾-dev
微服务架构已成为构建云原生应用程序的标准,微服务架构提供了令人信服的好处,包括可伸缩性,松散的服务耦合和独立部署,但是这种方法的成本很高,需要了解和熟练掌握分布式系统. 为了使用所有开发人员能够使用任何语言和任何框架轻松地构建便携式微服务应用程序,无论是开发新项目还是迁移现有代码. Dapr是一种可移植的,事件驱动的,无服务器运行时,用于构建跨云和边缘的分布式应用程序.