256 views
0

昨晚的事件,对tqsdk来说,应该算是一次不小的事故。

看了一个坛友的帖子,对于其中的建议,坦白来说我是不置可否的。是否收费,收多少,怎么收,是tqsdk考虑的事情。但事情昨晚发生时,迟迟未见有效解决,对于已经购买了专业版的朋友来说,是一次打击,你也总不能跟他说,其实收费不贵,比其他某某程序来说是比较少的,但这不是出事故的理由,对吧。

因此,我也想在自己了解的范围内,谈谈对于昨晚这次事件的个人看法。首先事先声明一下,本人非程序员,也不是专业投资者,算是一个半路出道,妄想凭程序化做点懒投资的……人,而已吧。

1、tqsdk应注意灾备。主服务器要有冗余服务器,主备同时在线,加上负载平衡等等,在服务出现重大故障,无法对外提供可靠服务时,应能立即自动切换,对外提供无扰服务。重大故障,包括硬件及软件。我了解的一般的服务器都是虚拟的,无论其重启、切换都是非常快的,对用户来时基本上是不会察觉到的。

2、tqsdk程序升级上架前应该有更完备的测试程序。相对于之前各个版本也出现或多或少或大或小的bug来说,昨晚的事件明显不属于bug了。究竟是程序方面的问题,还是部署问题,应该都要严格把控,因为毕竟是用在实际生产环境中的,出现问题可能是灾难性的。

3、即使因为各种原因,存在无法解决灾备或者排除程序问题方面的困难,那至少在升级前的备份方面应该考虑好,至少在出现问题,又没法立即解决的情况下,也能快速地回滚到前一版,至少前一版是正常的,不至于造成更大的影响,问题接下来可以慢慢再查。

4、tqsdk备用服务器应该能提供与主服务器全部的功能。昨晚出现问题后,tqsdk迅速给出一个解决方案,就是连接到备用服务器,这个人员速度应该来说是值得称赞的。但是备用服务器不能使用query函数,这个让我有点费解。因为恰恰我的程序用到了query,因此昨晚也懒得改程序(主要是本人技术还差,短时间想把query全部去掉,难度太大),就让程序死了一个晚上。在我一直以来的印象中,备就是主的copy,或者主是备的子集,如果只能完成主的部分功能,算哪门子的备,不合格,顶多只能算是降级备胎。或者,我建议将上一版程序作为这个备胎(不是“备”)的程序,不要一起升级,这样是不是可以解决一些问题呢?

以上是个人的一些浅见,不对或者不合理的,大家看过就算了。

刚刚看了一下,程序运转正常了,总算是松了一口气,但仍是任重道远,不是吗?

Answered question
0

20年4月还是5月也出现了一次,当天夜盘服务器出错导致没法自动登录,而开盘的时候我在开车。导致我的该停损的没有停损。亏大了~

Answered question
0

收到并且感谢建议,希望天勤在你们的帮助下能越来越好

Answered question