关于如何实现 QA 调整服务器时间的需求

[tqing1128]

我使用 docker 来部署测试环境，一台宿主机，N 个环境，每个 QA 一个环境（一组容器），需要提供 QA 改自己环境时间但是不影响其他环境（一组容器）的功能。

我使用 libfaketime 是可以实现该功能的，但是当我使用 jemalloc 后，就出现冲突了，原因如下：

issues

还有其他方式实现该需求吗

[cloudwu]

skynet 整个系统都不依赖 walltime ，你关于时间的需求应该是自己调用系统函数实现的。

你不需要修改系统时间，而应该自己实现一个管理时间任务的服务，类似 crontab 。给这个服务增加调试功能。

[tqing1128]

crontab 只能触发，只能解决部分，有些逻辑中使用的是时间戳，比如 每日重置 类业务，通常是记录上一次刷新的时间戳，然后与当前时间戳对比，是不同的 天 才刷新，天 发生变化时触发这个逻辑，如果时间没有真正的变化，业务是不会重置的

[huahua132]

https://github.com/huahua132/skynet_fly
可以考虑用我的这种加速时间方式

[tqing1128]

这种方式会不会影响容器宿主机的时间？

[huahua132]

这种方式是通过加速skynet内部定时器时间滴答数，不会影响到系统，像os.time不会受影响

[tqing1128]

我看到会执行 http://127.0.0.1:debug_port/fasttime/... ，最终是怎么实现的

[huahua132]

需要改动到源码，具体改动可以查看https://github.com/cloudwu/skynet/pull/1812。改动好的fork版本：https://github.com/huahua132/skynet

[tqing1128]

明白了，谢谢你的方案

[tqing1128]

上面扩展 skynet 是一个解决方案，但是正如云风大哥所说，这会带来额外的维护成本，对于 skynet 框架的使用者也是一样的。我更偏向于使用不修改 skynet 源码的方案，就像是 libfaketime，有没有类似的又不和 jemalloc 冲突的方案？

[huahua132]

触发60次，又不会导致你体力多加。时间可以1秒1秒的快进。
不是所有需求都可以通过时间差计算。比如状态机类的游戏：
定时器A触发后，有可能注册定时器B或者定时器C。假设定时器A需要30分钟后触发，BC也是30分钟。用以上方式加速1小时只会触发A，而B或者C还需要等30分钟才能触发。

[fanyh]

可以试试用 faketime来修改docker中的时间，不影响宿主机
btw：对docker中的进程产生的中间值（offset）做持久化，这不奇怪么？按题主思维来：offset是对docker的时间进行修饰，只不过刚好表现在skynet上

[tqing1128]

你看看我最初的问题

[tqing1128]

触发60次，又不会导致你体力多加。时间可以1秒1秒的快进。 不是所有需求都可以通过时间差计算。比如状态机类的游戏： 定时器A触发后，有可能注册定时器B或者定时器C。假设定时器A需要30分钟后触发，BC也是30分钟。用以上方式加速1小时只会触发A，而B或者C还需要等30分钟才能触发。

你应该看看前面关于时间参数的讨论

[huahua132]

我看过了，你是想要一个进程内全局，可加速到某个时间节点，不影响系统时间的时间参数skynet.time()
然后还想要同时刷新crontab(我可以理解为触发skynet定时器事件不？)
我修改skynet底层的方案就可以做到

之间我的例子说明，是基于仅仅修改skynet_updatetime()后，去调整时间会存在的问题，因为一开始我的想法就是这样做的