区块链交易所时区选择：服务器到底该设UTC还是本地时区

导读： 好多团队在交易所快要上线的时候, 才匆忙决定时区选哪一个, 结果就导致了账目对不整齐、风控系统判断错误的情况经常发生, 我亲眼见过太多个项目了, 因为一个时区的参数没有设定清楚...

好多团队在交易所快要上线的时候, 才匆忙决定时区选哪一个, 结果就导致了账目对不整齐、风控系统判断错误的情况经常发生, 我亲眼见过太多个项目了, 因为一个时区的参数没有设定清楚, 所以跨服务器的数据拼接出现了八个小时偏差, 主要原则一点都不复杂就是把服务器统一使用协调世界时也就是UTC, 而展示界面按照用户的本地时区进行显示和渲染。

交易所服务器时区怎么设

在生产环境里, 我一直坚持遵守一种约定俗成的规矩, 那就是要确保数据库、行情推送以及订单撮合引擎这三个部分全部都按照标准时间来进行统一, 并且严格限制为使用零时区。

至于在系统这一层级上面的时间戳也必须设定为与协调世界时一致的格式, 而在处理具体的业务相关字段的时候, 我们绝对不能去存储那种带本地偏移量的数据内容。

好处是跨节点对账的时候, 完全不用再费劲去搞什么换算。你看新加坡那个撮合节点, 还有法兰克福那个清算节点, 它们的日志时间戳本身就是天然对齐的。

回想早期, 有个节点设了什么IST, 结果订单时间戳和行情时间戳直接差了五个半小时, 风控系统因为这个问题误触发了告警, 一直拖了整整两个星期。掉进这个坑之后, 我得带着团队一起干活, 足足花了三个月的时间, 才终于把这个烂摊子收拾干净。

区块链交易所时区选择看什么

站在给用户使用的这一端来说, 时区的渲染工作完全交给前端代码来处理。如果用户在后台设置的是北京时间, 那么在前端页面上就会直接显示出北京时间；如果用户设置的是东京时间, 那么前端页面也就相应地显示出东京时间。

关于区块出块时间戳统一UTC秒级精度这一规则必须得到严格遵守, 而具体的时间偏移和换算工作则由前端程序来完成计算。

大家容易忽视的一个重点是合规审计这一事儿。如果你需要同时为亚洲用户和欧洲用户提供服务, 那么你的审计时间线必须是可以被回溯和追踪的。我们会把数据按照协调世界时来进行存储, 但是展示的时候会按照当地所属辖区的时区来显示。

这样的话, 审计人员拿到了原始日志之后, 就不需要去猜测你们是在哪一个时区运行的了。我把关于时区的策略写进了部署文档当中。在每一个节点上, 网络时间协议的服务来源都指向协调世界时的官方来源。一旦发现偏差超过了五十毫秒, 系统就会发出警报信息。

时区不是小事，定早比定晚好。