Charles 监听的应用层代理吗？如果是的话，对方有可能不是用的 HTTPS 协议，例如某电商 App 用的就是 SPDY 协议，如果是这种情况，可以试试按 sock 监听再看看。

抱团 https://www.lipijin.com/

@NX2023 你这别说之后了，第一步就得看造化

可能人压根没把你当朋友...

https://www.lipijin.com/ 不是大佬，但可能有趣。内容涉及技术、读书、摄影、做饭等等

这是一个典型的大 key 热 key 场景，不管是否存在推送慢的情况，可能分片都是应该做的。
楼主的思路我感觉没啥问题，成本也是最低的。
至于考虑到订阅计数器的单独维护问题，我觉得这点成本是应该的，毕竟你分片之后对于热门活动不可能在线上实时 zcount 1024 个分片吧，那也太慢了。
尽量保持线上业务快速响应，很多活可以异步处理，比如这个计数器就可以异步执行，不需要实时增加，不影响线上业务响应。

实际上我理解最好是特殊情况特殊处理，不需要一视同仁给所有活动都分片，可以动态地给大 key 做分片，不过一旦涉及到动态就会引入更多复杂的逻辑例如 rehash 或是引入哈希环等等，展开来就有更多东西可以讨论了，这个场景下有点舍本逐末就算了吧。

另外我觉得这个场景用 bitmap 不太合适，用户量级在百万级，那么单个 bitmap 的大小至少要上 M ，也算是大 key 了，而且很多绝大部分的活动都是冷门的，意味着 bitmap 中绝大部分都是非常稀疏的，这么搞不太划算。
我认知里 bitmap 更适合全体用户都参与的场景，例如是否活跃、是否在线等等吧。

一些临时的想法可能有不太合适的地方，可以一起讨论

小米 4 和 iPhone5

这种 App 死了好几个了，尤其是在 2021 年前后打击饭圈那阵子。

看起来你追求的是跟对方完全一致的限流进度，想要维持最大并发量又不想触发 QPS 限流。
这个有点类似分布式事务的场景，需要在网络环境中保持不同系统间状态完全一致，想要做到完全一致是比较难搞的，何况你这还是在三方系统中。

但我理解实际上你没必要自己搞一个限流对标对方的限流，限流本身就是保护后端的，你只需要处理一下发生限流时做退避重试就好了，只要关注自己的业务并发量够用就行。

啥意思，因河北、河南、山东、山西四省高等教育资源不足，学生自己搞了一个学校？自己教自己吗？还是说就是一个想象出来的乌托邦？

好像 2 点左右出的问题，发版发不上去。
貌似还在定位问题，估计一时半会好不了。
另外好像 loli 图床也挂了，所以你图目前我看是裂的。

@xstress 现在很多场次都不支持 Web 端售票了，只能 App 端。

@luhe 你这阅读理解能力给我整乐了

今天走了两万步，痛点是脚底板。