CtW Episodes

看了下，已经有宁夏 region 可选了， 不过这么偏，不知道网络怎么样，不敢用啊。

手上有台 15-inch, Late 2016，确实带着不方便。 也想入手一台 macbook

价格都不说，那就是无所谓了直接 LG UltraFine 5K 吧

incase

我以前公司也搞过同样的活动，我当时买了 200 多块的良品铺子，结果收到了一瓶冰红茶😡

并没有，能正常访问

小心 800G 没了

steam 已经停止 btc 交易了，不知道有没有什么影响

已 star

@fds 嗯。让客户端来做倒计时服务端验证应该是最好的。 我看了下 snapshot 确实是好多 scheduledJob 都在_cache 里，应该就是没 cancel 掉。 我先本地测试下，thanks。

@chairuosen 听你这么一说好像有点道理。 也没深入了解过这个库，我以为这种只执行一次的任务是不需要 cancel 的，我先把这部分修改了

@fds 旧的 task 没有 cancel，因为我这里的 task 都是只执行一次的，即在某个时间点执行一次，执行之后才会有新的 task 产生，我产生新的 task 是直接把新旧 taks 覆盖掉。不知道这里有没有问题。 因为都是只执行一次而且都是已经执行过了，task 再 cancel 已经没意义了吧？

@fds 嗯，不好意思，文中多打了一个 d

@solee 对消息队列这块比较陌生，有相应的资料吗？

@janxin 嗯。就想#1 说的，全局一个 setinterval，因为我这里的最小单位是 1s，那就让这个 setinterval 1s 执行一次，每次执行的时候 我就去处理是否有相应的逻辑触发？

@janxin 嗯，感谢。 是联机游戏，我和客户端讨论下。

@haozes
1.用户量很少的，因为是小范围的测试，同时在线就 100 多点。所以是代码问题
2.按道理单个正常情况下支持个上百人应该没问题吧，所以就暂时没考虑负载均衡了（正式上线肯定是需要的）
3.redis 通知这个一开始有考虑过，后来想到一个道具就 10 多秒就恢复了，就没用 redis 这一层

@janxin 关键是客户端的表现是，一开始这个道具在地图里，然后被吃掉后，这个道具就没了，服务端倒计时完毕，告诉客户端道具刷新了，然后客户端就在同样的位置刷出同样的道具。 让客户端去做的话应该不好实现，而且估计容易作弊