这个规模要并发、要简单 用 ssdb 多主就 ok 了，ssdb 的主从使用运维体验基本无敌，唯一就是注意业务上分 key 写节点，key 按日期前缀生成，直接扫前缀就能清理

用 fseek+fopen 自己撸一个 定时任务 要统计什么就统计什么 开销小 无依赖 一个字：舒服

docker 的目录挂载、卷性能在高并发下真的是灾难，内核调优、ssd 什么方法都试遍了，无论是官方推荐的 overlay2 还是别的 driver，数据都比裸跑差 20%，别问我怎么知道的，线上几十台 docker 实践出来的血泪史…

1. 在页面下载完后，自己注入 js 监听
2. js 里 hook xmlhttp 这类原生方法

重写一下隐藏 bucket 就行了

从大学开始坚持做了快 10 年副业，因为副业被挖去某个一线公司，突然有一天发现你的坚持够养活一家人了，又正好公司走下坡路，就辞职回二线城市了。
副业变成正业，一晃快 5 年了，如今自由职业，想玩就玩，想做就做。
产品、技术、设计、推广一人全包，新技术一个不落；只是目前只做兴趣驱动的项目。
关键词：技术驱动，大数据，老站长

楼主缺男朋友吗？选什么职业、哪怕 1w package 都支持你的那种

@dusu 好吧 审题错了 不是调试环境那就只能内网映射了

whistle 你值得拥有

这种需求单靠 sql 压根就是自讨苦吃

窗口按时间移动的需求

显然用 redis 写个 key+ttl 就好解决的问题

例如每 5 分钟内 每个用户使用固定 key

用户交易成功 incr 记录次数

每次都往前推 4 个 key 去计算和是否满足大于 20 次总量 ，如果超过，记录到异常 list 当中备查即可

如果精度要求高那就每 1 分钟一个固定 key

这实现不管是 30 分钟 1 个小时 6 个小时 12 个小时都可以做

sql 去做这个事…想想都蛋疼

显然是 redis pool 到了最高并发量 导致 hyperf worker 协程都卡在了 redis 这头 而 redis 又查不出慢查询的原因

建议把 qps 部分或者高频又低重要性的 redis 操作都换成 asyncQueue 或者其他异步单线程任务试试看看协程能不能缓解。

我司三千万文件，就是用 md5，几年都没有什么问题，楼主想多了

br 或者 gzip 一下充其量就是 1-2m 直接 post body 就 ok

在？给你表演一个练了十几年的 53231323 ？

村里刚通电，请问一下，是我大 Delphi 亡了么？

哦，年轻人，学什么语言都只是工具，学历甚马的都是浮云，相信我，重点还是在于你思考问题的方式和钻研的精神…

@anthoy

base 表

存公用 meta 信息

也就是你的所谓第一行 第二行

base_attr 表

每一行，代表

base_id=base 表 id
attr=属性名称或代号
val=属性对应的值

base_id+单个属性+单个值，例如：

第一行 id + 这是 a 属性 + a 的内容

第一行 id + 这是 b 属性 + b 的内容

第二行 id + 这是 a 属性 + a 的内容

第三行 id + 这是 c 属性 + c 的内容

....

后续无论是要加 x 还是 y 还是 z 属性都可以应对

优点是维护起来容易 拓展方便

缺点就是多了次额外查询

base 表

id-meta_info

base_attr 表

id-base_id-attr-val



把数据拆成行，attr-base_id 加上你的索引 轻松解决

可能微信回调坑！楼主可以检查一下，微信走的 http 回调，竟然不支持返回 content-encoding: gzip/br，曾经为了这个问题折腾了好几天，最后单独让 nginx 为这个接口原文返回。

大写的服。

只能说贵微信，真是神一样的团队。

LZ 先找到愿意给你提供这种发包的机器再说吧。