揭秘数字货币交易所技术难点，如何通过技术革新赢得用户口碑

前言：

随着数字货币价格的一路攀升，比特币三个月内涨幅近90%，其他主流数字货币也均有较大涨幅。与此同时，整个数字货币交易市场如万物般复苏，全球数字货币交易所呈现高速增长，交易者也因此拥有了更多选择。无论是选择久经沙场的老牌交易所还是野蛮生长的新晋交易所，在保障每一笔交易的安全、高效和稳定都离不开强大的技术支撑，那么在构建数字货币交易所又会经历哪些难点呢?

一、盘点数字货币交易所的技术难点。

1.安全性。

毫无疑问，用户资产安全是第一位的，这是数字货币交易所的生命线。每天有无数的黑客在盯着交易所，经常有交易所的被盗案例爆出，包括排名前几的交易所，近期币安也发生了7000枚BTC被盗事件，这是币安第三次大规模被盗，其他交易所的案例就更不胜枚举。当然除了资产安全，用户信息安全也是非常重要的。

2.高可用。

可用性是指一个系统处在可工作状态的时间的比例。数字货币都是7*24全天候交易，一旦系统出现故障，无论是一个进程异常退出了、一台服务器宕机了或者是某根网线(光缆)断了，都可能导致无法交易，直接导致客户损失。尤其是高杠杆的合约交易，可能就直接爆仓了。对于系统的维护和升级也一样，诸多大型交易所也经常频繁停机维护，如遇到重大行情但交易所停机维护，客户肯定难以接受的。目前有哪家数字货币交易所做完全做到了吗?据我所知好像没有，不是经常停机维护就是系统故障又或者是overload(系统超载)，包括全球几大知名交易所。这不但对架构设计的要求非常高，支持容灾容错;又要保证流程和执行上不能出错，敲错一个命令可能就毁了;还要经过完备的实战灾备演练，才可能演变成安全稳定且高可用的系统。工作时间可以有人盯着，及时发现问题和解决问题，万一节假日或者半夜发生问题呢?多久能发现和解决问题(术语叫RTO)就成为一个难题。

3.高并发/高吞吐量。

最核心的指标是每秒的下单量(TPS)。合约交易因为有杠杆的放大效应，每个客户的交易频率会比币币交易频繁的多。通过API做量化交易的订单又会远大于散客，尤其是做高频交易的。一旦并发下单数超过系统负载能力，就会导致overload无法下单，这会造成错失交易机会或者亏损，甚至被无故爆仓。所以高并发是每个合约交易所都在比拼追赶的能力，比如bitmex就经常会overload。

4.低延迟。

延迟主要指交易中发起下单到收到订单状态推送，如果是市价单立即成交的话再看收到成交推送这每一步所花的时间。日内交易者尤其是高频交易者会非常关心延迟问题，慢1毫秒甚至1微秒就可能丧失交易机会。

5.高可靠。

主要指数据的可靠性，在程序异常、服务器宕机、硬件故障、机房断电、甚至地震等各种极端情况下都能保证用户数据不丢失、不错乱。一般为了在异常和灾难情况下保持可靠性，程序和数据都会存储多份。如何让多份数据保持一致性，尤其是强一致性即任何时刻多份数据都是一致的，这是一个很有难度的问题。

二、Bybit如何解决这些难点?相比其他交易所有什么优势?

1.安全性。

Bybit和币圈知名的安全团队「慢雾」建立了合作，在以下几方面都做了详细的审计和渗透测试，多维度的进行了安全保障：

钱包方面，Bybit采用了分层确定性冷钱包和离线签名技术，存储私钥的机器永不连网，黑客绝对无法攻击。另外内部流程上也严格管控，需要多个人的多重签名才可以提币转账，每一笔提币操作通过自动审核加人工审核双重确认。签名服务器有独立的门禁和摄像头24小时监控，必须有权限才能进入。Bybit上线至今从未发生过任何一笔资金被盗事件。Bybit也做到了准实时的自动对账，每分钟对数据做快照来对账，如遇特殊情况，我们的技术团队也能在第一时间定位问题。

漏洞防护方面(包括服务器漏洞、网络漏洞、软件漏洞、账号漏洞、业务逻辑漏洞等)，Bybit技术团队联合慢雾团队在上线前和上线后都做了大量审计和渗透测试工作，确保消除安全漏洞，保障用户的账户资产和信息安全。此外，Bybit也有报告漏洞奖励计划，把漏洞扼杀在摇篮之中。截止目前，已有多位安全圈内的白帽子给Bybit反馈过漏洞，基本都属于低危漏洞，没有对用户账户及交易系统造成损伤，也没有任何黑客利用这些漏洞谋取利益，至于中高危的漏洞在Bybit还从未发生过，当然我们也一直防患于未然。

其他方面，如内部研发和运维流程、数据访问权限、内部系统权限、办公网络和办公设备安全、邮箱安全等等，Bybit内部也做了严格的控制，这里就不一一详述了。

2.高可用。

Bybit目前已经做到了99.99%的可用性，即一年的不可交易时间小于52分钟。要做到四个9的可用性，就必须做到以下几点：

1)在线维护&热更新。大多数交易所在做系统维护和升级的时候都需要停机，导致无法交易，用户体验糟糕。Bybit做到了所有的维护和升级都必须在线完成，做到绝不主动性停机。这对技术架构、程序开发、运维支持的要求都非常高，所有数据迁移、服务重启、运维变更等都必须做到平滑，让用户无任何感知。虽然需要付出大量的成本去做，但为了不影响用户的交易体验，这些代价是非常值得的，我们必须把用户的体验和口碑放在第一位。事实上，我们每周都会进行大大小小的3-5次系统迭代升级或变更，用户几乎感知不到，除非是对用户体验做了升级或者发布了新功能。

2)灾备架构、Auto Failover(自动灾备切换机制)和灾备演练。对于大规模的服务来说，经常会遇到程序异常退出或重启、服务器硬件故障、网络故障等各种错误和灾难。但要在发生这些灾难的时候做到服务连续可用，所有的服务必须部署多份，或者做成集群。当发生异常和灾难时，必须能够自动实现服务切换或者灾难恢复，这样才能保证比较高的可用性。在Bybit内部有很多个服务集群，通过服务发现和leader选举来实现自动灾备切换。并且有一套高性能高可靠的消息总线，很好的实现了消息确认和回溯机制，当服务切换时，程序能够根据消息序号完美地做到无缝切换。还有，灾备演练至关重要，不做灾备演练就像让只是通过了理论考试的学员直接开车上路一样危险。

Bybit消息架构

3)灰度发布。对于一些核心模块的上线和更新，一般Bybit会采用灰度发布的方式。即先发布给少量用户体验(用户也可能无感知)，一般是先给乐于向Bybit反馈问题和提建议的活跃用户体验。当体验一段时间没问题的话再逐步扩大用户范围，直到全量发布给所有用户。这样可以尽量减少新功能或新系统可能存在问题或者不太稳定的问题，可以大大降低影响范围。万一体验新功能或新系统的用户遇到问题导致某些损失，Bybit平台也会全额赔付给用户。

4)立体化监控。包括硬件、网络、服务(健康状况、性能指标、访问次数和频率、错误异常等)、客户端(错误异常、页面性能、网络状况、软硬件环境等)、业务指标(注册量、访问量、下单量等)。Bybit会监控一切有价值的指标，通过事前预警、事后快速响应，针对不同级别的问题通过邮件、短信、电话等不同告警方式给到相对应的负责人。

3.高并发/高吞吐量。

Bybit的撮合服务采用C++语言，全内存设计，采用epoll网络接入，能实现单线程每秒10万+的撮合(事实上我们去掉调试日志后压测已经到了30万+的TPS)，并且可以根据未来需要调优到每秒百万级TPS。除了高性能撮合服务，Bybit近期上线了全新的内存化订单系统，可以做到单机每秒10000TPS，如果部署n台机器，总TPS=10000*n。要注意永续合约的下单逻辑要远比币币交易来的复杂，因为涉及到合并仓位的保证金计算、只减仓(reduce only)等复杂的下单策略。并且下单服务做到了可以平行扩展，通过sharding的方式提供服务，每个用户都有独立的协程处理下单，不会因为某些高频交易用户订单量特别大从而影响了其他用户下单。

4.低延迟。

撮合单线程单币种每秒10万TPS，即意味着单笔撮合20微秒完成。因为采用了几乎是全球领先的LMax交易所发明的Disruptor内存无锁队列，以及内存零拷贝等技术，撮合是交易所最核心的部分，必须追求极致性能。除了撮合以外，我们的行情系统、下单系统、推送系统也已经陆续完成了内存化的改造和升级，还有些持仓系统等也正在内存化改造当中。我们的目标是从下一个市价单开始，到撮合再到订单状态、成交推送和仓位更新推送，整个交易链路的内部处理时间控制在5毫秒以内。当然，从用户端视角来看，整个交易链路的时间还要再加上网络传输时间，这就取决于用户的网络情况。

Disruptor/Ring Buffer原理

5.高可靠。

高可靠主要是指数据的高可靠性，必须在任何情况下保证用户数据的正确性，以及不能丢失。所有的数据必须冗余多份，并且在发生这些灾难的时候能够丝毫不差地恢复出来，即RPO要做到0，不允许任何数据丢失。在大部分情况下，我们能做到秒级的RTO，即在几秒钟内自动完成数据和服务的恢复。Bybit核心的消息总线实现了数据持久化和集群化，只要进来的消息就不会丢失。消息的可回溯性能够支持系统从任一个时刻恢复数据。比如t时刻后的所有持久化订单数据都丢了，我们能快速找到t时刻对应的消息序号n，并从n+1开始回播所有订单消息，实现订单数据的恢复，并且我们的系统设计上能保证回播产生的数据和恢复前是完全一致的。

专业资深的架构师都知道，单单做到上面任何一点其实都没有那么难，但要同时做到高可用、低延迟、高可靠且高并发就很有难度。因为在这个问题上，理论计算机科学中有一个经典的CAP定理，对于一个分布式计算系统来说，不可能同时满足一致性、可用性、分区容错性这三点。那么Bybit是怎么解决这个难题，实现最优的三角平衡呢?

第一，要做到高可用，最好是做成无状态服务，或者做成集群服务，但无状态和集群服务就意味着要频繁通过网络来同步状态，这跟低延迟是矛盾的。要做到单次撮合20微秒甚至10微秒内完成，很难通过网络去同步状态。

第二，要做到低延迟，都必须是内存化的服务，但内存就意味着进程退出或机器掉电就会丢失，他是不可靠的。要同时做到低延迟和高可靠，即要在掉电的时候保证数据不丢，也是不容易的事情。

第三，要做到高可靠，数据就必须冗余多份，一旦是多份就会有一致性问题，这时还做到高可用，就必须做到数据强一致性，才能保证一份数据出问题时，冗余数据是实时可用的。这样又回到了第一个问题，要做到强一致性，一般的做法是做成集群，但这样又需要通过网络来同步数据，牺牲了低延迟。

具体我们是怎么做的呢?拿最核心的撮合引擎来说，撮合引擎的特点是有状态(内存里有orderbook等大量数据)且必须单点(单线程)按顺序一个一个处理撮合，严格来说不能并发不能乱序，当然也不能平行扩展。要做到高可用，那肯定要有多台服务器，当一台宕机了以后另一台能立即提供服务。难点是如何保证两台撮合引擎的数据是强一致的。一般的做法是做成集群，通过Paxos、Raft或者Quorum等分布式一致性算法来保证强一致，但这样就依赖于大量的网络通信来同步状态，显然每次处理的延迟会远高于单机处理时的20微秒。并且因为撮合不能平行扩展，所以这里一定会成为整个系统的吞吐量瓶颈所在。所以如果撮合做成集群的话，虽然满足了高可用和强一致性，但牺牲了分区容错性，且牺牲了低延迟和高并发。我们在这里有几个巧妙的设计：a)通过前端的消息队列集群来完成请求定序，且已经生成了全局唯一的订单号，两台撮合引擎都从这里订阅消息作为输入，所以输入是完全一致的;b)消息队列集群C的消息都是持久化的;c)撮合引擎内部全部采用确定性算法，如生成成交ID时不能带有时间信息或随机数等，保证2台撮合引擎输出到各自的消息队列集群的结果是完全一致的;d)撮合结果的每个消息有唯一且连续的序号，后端应用(如行情服务器)可以任意切换AB两个数据源。

以上设计的巧妙在于：1)撮合的处理不依赖于网络，是具备分区容错的，且延迟可以做到极低;2)因为每次撮合处理的延迟变低，所以吞吐量就变高，而这里又是不可扩展的瓶颈，所以整个系统的并发能力就变高;3)实现了高可用，当任意一台撮合服务器宕机以后，后端服务可以切换到另一个消息队列集群，从下一个消息开始处理;4)消息队列集群C的消息都是持久化的，可以通过回放从任一时刻开始的消息，把之后的数据完全恢复出来，实现高可靠性。5)依靠前置的唯一订单号和消息定序以及确定性算法，让两台互不通信的撮合引擎能够输出一样的结果，从而实现了一致性，在这个场景下可以认为做到了强一致性。

对撮合来说，这样的方案好像同时实现了C、A、P，还能做到低延迟高吞吐，是否打破了CAP定理呢?其实没有，其实是撮合把这个问题抛给了前置的消息队列集群，这个集群还是不可能同时满足CAP的，所以我们整个系统还是不能同时做到CAP。但这样换来的是撮合的高可用、高吞吐、低延迟、高可靠、强一致和分区容错性。作为整个交易平台最核心且不可扩展的模块，这样的设计我们认为是几乎完美的，因为它几乎满足了我们所有需求。

Bybit撮合容灾架构

三.未来会有哪些技术挑战以及如何去提升呢?

Bybit作为上线不到一年的交易所，在以上几方面已经完全不亚于全球几大知名交易所，甚至在有些地方已经领先于他们。但要完全解决好以上几个技术挑战，显然不是一朝一夕能够攻克的。很多交易所用了几年了，也没有解决好。Bybit也还需要深耕细作，比如延迟方面继续优化，达到整个交易链路5毫秒的目标;以及容灾能力方面，提升异地灾备能力;在浏览器体验上，我们的性能还不够完美，需要进一步去优化。我们深知技术保障对于交易所的重要性，Bybit的运营理念是“用户至上，技术为王”，良好的用户体验是建立在稳定可靠的技术前提下，我们肩负使命和重任，承载梦想，目标是做出在数字货币领域技术足够领先甚至超前的交易所，以我们的技术核心竞争力赢得用户的信任和选择。

原文出自：https://news.huoxing24.com/20190715185454329250.html

微信公众号→添加朋友→搜bitett