去年做外包时接了一单模拟实时交易的系统。在外包领域,难得接到这种高并发项目,分享下经验。

技术栈: Node + MySQL + 小程序 + WebSocket

服务器:腾讯云 4C8G

性能目标:能承受 500 人同时交易

主要技术难点

需求的难点:

  • 需要实时根据一定的规则撮合交易发生(价优者优先,同价情况,先到者优先)
  • 即使一个用户没有进行买卖,他的资产和可用资金也会实时变化
  • 需要实时计算所有用户的资产,并作出排行榜
  • 所有变化要实时推送到客户端

有这么几个坑:

  • 实时系统的设计与实现
  • 非常容易发生性能问题
  • 非常容易发生并发冲突

最终系统的大致设计如下:

  • 每秒进行一次撮合交易,相比真的实时,更容易优化性能问题。
  • 为了处理并发问题,所有委托默认隐藏状态,每次进行撮合交易时,先读取所有委托,撮合它们进行交易,之后未成交的委托取消隐藏。
  • 每秒撮合交易完成后,对所有客户端推送最新数据。一秒一次批量推送,能节省带宽和计算资源,也差不多刚好是小程序能处理的频率。

由于这个交易撮合的流程是单线程的,导致无法暴力地通过加核加主机来优化性能。 对高并发带来了更多的挑战。

下面就开始优化性能了。

上缓存

系统中,除了推送的数据之外,还有各种行情图,排行榜等,用户查看时通过 http 请求轮询。

这些请求要查询大量数据库和进行大量运算,消耗资源不少。

上一个 1 秒过期的缓存就能减小很多压力。

精简掉新连接时拉取数据环节

最初的设计中,每个用户连接时,系统会查询当前的实时数据并返回用户,当同时有大量用户连接时,就会卡。

解决方案:直接去掉这一步,用户连接时服务器不推送任何数据,而是在下一次撮合交易完后再批量推送数据。

好处是,只要系统能承载 500 人同时交易,就能承载 500 人同时加入交易。nice。

多线程处理重计算业务

虽然不能直接开多个进程,但我们还是可以把多核利用起来的,只要把重计算的部分交给其它核就行了。

给你安利一个库:worker-farm,基本上来讲,它可以把一个异步函数变成多进程的,同时调用多个时,会智能分配给各个 cpu,在不能简单粗暴地使用 cluster 时,可以用这种解决方案。

这下四个 CPU 能跑满了。

异步编程大法好,node 大法好,多线程编程一窍不通,也能写多线程程序。

增加 mysql 连接数

不解释。

使用主机商提供的 MySQL 云服务

之前 MySQL 是跑在本地的。众所周知,云服务器的磁盘读写性能堪忧。直接换成主机商的 MySQL 云服务,性能提升不少。

性能瓶颈竟然是…… Array.sort

考虑到会有很多用户登录一次后不再登录,上线后很可能是:五百用户同时在线,总用户数千个。

为此,往数据库里添加了数千个用户再次测试,果然出现了性能问题,排查后发现,性能问题竟然是:排行榜进行排序时,使用 Array.sort,这个函数跑了数百毫秒。好吧,毕竟是数千笔数据的排序。

解决方案:npm 上搜一个快速排序的库,替换掉,时间直接缩减到几十毫秒,美滋滋。

至此,差不多已经可以承受 500 用户同时访问了,上线!

数据库加索引

上线后没多久就开始卡了,直觉告诉我是因为数据库没加索引,而用户太过热情导致瞬间委托量就达到数万。

登录数据库加上索引,搞定。

总结

并发并不是这个系统中最困难的部分。

最困难的部分是交易撮合系统的设计开发和调试,很多 bug 只在非常特定的情况和时间点才会出现,交易一次没问题,两次没问题,但在不特定的 n 次时会出 bug,非常难定位。

此外,系统设计之初必须要考虑到并发问题,如果最初的设计是,每有用户下单时就推送一次数据,那么十几个在线用户就可以造成每秒数十次推送,需要推翻重新设计。

不过,这个系统的并发量并不算很高,可能这也是难度不大的原因。希望我司的产品能大卖,让我有机会做个千万级的并发,再回来吹牛逼说高并发不难,哈哈。