背后的故事令人暖心，鼓励，支持

看过老梁的大唐雷音寺吗？也是一男一女搭配说故事。
这俩节目性质差不多，就是讲故事，内容大都来自各路野史或是小道消息那种。其中：
女的要表现得傻一点，呆萌一点；男的要表现出对各种信息了然于胸，信手拈来的气势。
区别是老梁讲的内容多少还跟历史、文化沾点边，听着还不是那么离谱。
老高可就离了大谱了，哪天他要是讲出当年孙悟空联手黑猫警长在佛罗伦萨大战哥斯拉与铁血战士，我都不觉得奇怪，那才叫对味儿呢。

哈哈哈哈，没想到楼主又是你，你这一天可太欢乐了。
参考楼主之前的帖子：“吃铜炉火锅被烫，所以建议不要吃铜炉火锅。”
哈哈哈哈，我感觉楼主你把论坛玩明白了。
😋 😋 😋

这个也挺简洁吧 https://www.lipijin.com/

楼主前一个帖子说一天吃一顿好处多
我在想一天吃一顿的另一个好处就是一天最多被烫一次
要是一天吃三顿的话就可能会被烫三次
是这么回事不...

现在知道电信诈骗为什么那么多了吧，感觉卧槽这么假还有人信？ 你不信，总有人会信。

看标题还以为是想实现在别人睡觉的时候我看书，然后惊艳所有人...

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 限流。
这个有点类似分布式事务的场景，需要在网络环境中保持不同系统间状态完全一致，想要做到完全一致是比较难搞的，何况你这还是在三方系统中。

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