zdking08135

大致能细化需求，用户会上报[user_id, start_time, end_time]一个三元组； start_time 和 end_time 可能互相会重叠。怎么保证对指定 user_id 的任务时间统计做近似实时查询。

问题 1：为什么用户的上报会有并发，同一个 user_id 会同时从多个来源上报？
问题 2：一个用户可以并发执行任务吗？即，会不会出现 B 任务的 start_time 在 A 任务的[s, e]区间内？
问题 3：任务的平均执行时长大约有多少？单用户一天上报平均多少次？

Referrer 策略：针对跨站请求，忽略对其限制较宽松的 referrer 策略 - “no-referrer-when-downgrade”： https://api.geetest.com/gettype.php?gt=ac597a4506fee079629df5d8b66dd4fe&callback=geetest_1750134718479

Uncaught Error: 网络错误
k https://s1.hdslb.com/bfs/seed/jinkela/short/mini-login-v2/miniLogin.umd.min.js:13
C https://s1.hdslb.com/bfs/seed/jinkela/short/mini-login-v2/miniLogin.umd.min.js:13
_ https://s1.hdslb.com/bfs/seed/jinkela/short/mini-login-v2/miniLogin.umd.min.js:13
i https://s1.hdslb.com/bfs/seed/jinkela/short/mini-login-v2/miniLogin.umd.min.js:13
onerror https://s1.hdslb.com/bfs/seed/jinkela/short/mini-login-v2/miniLogin.umd.min.js:13

尽量设计成一个实例操作一部分数据，没必要用锁竞争。
做好监控的话，实例挂了的情况其实很少见，直接处理就行了。

不要给。
你现在跟这个公司没有任何劳动/劳务合同，纳税，社保记录，
换句话说，老板用你的信息去为他的公司申报某某材料，先不说需要什么材料，就是这个申请本身，就是有问题的。
如果你决定给，你就要问清楚为什么需要。否则就不要给了，天知道他会拿去做啥。

@vopsoft 致钛不算山寨吧？贴吧老哥应该是测试过很多了

这是你这辈子最后一段有时间，有精力，有钱（能从父母那里接受资助）的时光了。去开开心心的玩吧，否则会后悔的。

分两种情况，一种是对着 IP 瞎鸡儿发包，一种是尝试构造异常请求。

如果是瞎鸡儿发包这种，设计的比较完善的交互协议，本身就有做强校验的。一般是在分两种情况。

如果是自有的二进制协议，适用于 app 请求场景，这种本身伪造的难度就很高。
一般是发到网络的请求包就带加密了，伪造协议无法正常交换密钥，在接入层解密的时候就会失败。

如果是公开协议，比如 http ，这一类很容易通过脚本构造请求包，
这类解决方式一般是在前端代码中混淆嵌入密钥和算法，然后给请求生成签名。
计算签名时，携带时间戳和随机数，然后接入层校验的时候就能拦截掉。
这类校验逻辑无上下文状态，节点很容易 scaling 。

实际业务中，除非是对内部实现有了解的人，否则很难通过非端环境构造合法报文。
大的系统都有专门的接入层，只负责协议加解密转发之类的，节点数远多于业务节点数，请求进接入层之前还要走 LB 。真正打垮接入层很难，成本极高。

如果是异常请求，但是通过了校验，比如别人拿了客户端代码改了直接发包。
这种就只能上验证码之类的了。

@yjhatfdu2

NB 了，感谢，看来要多研究一下这个软件。
话说，可以顺便尝试复杂查询？

比如(city = 100 or city = 101) and date < '2024-04-02' and date > '2024-03-31'