有可能是光猫太垃圾了，申请换一个（亲测试过换光猫网络就问题了）

@Neverc 黑裙可以的，我现在都是用这些 app 外网连回去

@godmiracle 请问车辆数据记录怎么用的呀?

@Tongwin 虽说工资单里填的是基础工资+绩效工资，但实际每月到手工资是固定的

@ashin op 你好，我想请问下，假如公司发放工资单里分有基础工资以及其他工资明细，然后公积金里的缴纳基数是按照基础工资缴纳的，这种也能成功追缴么？

@hcocoa 是运营商扫你的服务，封境外 ip 只能起到防攻击效果吧？

@hcocoa 我搞过 wireguard ，应该跟 tailscale 这些差不多。走 vpn 管道，相当于哪个设备要连局域网内的服务都要搞一次代理才能够连。 你这连 sp 应该也是同理。还是挺麻烦的。

低端口更容易被运营商扫到吧

手持 xsmax ，是现在 8200 买一台 15pm 还是等等 16pm 呢？

请问下这种场景能实现么？
动态公网 ip+DDNS+内网 docker 部署游戏， 能够提供给几个基友在外网玩么？

@codedreamstar 大佬真的万分抱歉，1 周后才来回复你信息。 最近杂事缠身。我们用 kafka 并不是自己封装的，也是使用正常的依赖，由于本身架构问题，所以没法使用 Spring for kafka 。不过后续我们需要重构这个项目，后面以 SpringBoot 来框架进行搭建就会用 Spring for kafka 去设计了。 尴尬的是中间进程下发 B 是没有限流逻辑，我们后面会优先开发这一块。之前的数据的实时速率都没有达到应用 B 的峰值。
后面应用重构，确实是考虑过把 redis 砍掉，原有 redis 功能是为了保证数据不丢失（比如应用 B 处理失败，应用 A 有相关的重发机制），后续重构我的想法是砍掉 redis ， 消费 topic 进而下发数据，如果应用 B 处理失败，则应用 A 把失败的数据推送到另一个 topic-C 。 应用 A 继续消费 topic-C 的数据来实现重发机制。
感谢大佬提供的思路，让我对 kafka 以及项目设计有了进一步的认识。

@flmn hi 大佬，我昨天就已经在测试了，配置大概是 max.poll.record 设置为 200 ，fetch.min.bytes 使用默认值。 通过限流打日志查看，每一次 poll 都是 200 。不过是在本地单实例跑的。 我大概懂你意思了，你说的情况应该是，我在消费的同时，上游也在造数据。如果我的消费速度超过生产速度，那么确实会出现，上游推来一条，我就消费 1 条的情况。

@flmn 我之前可能理解错意思了， 但我还是有点疑惑， 如果我设置 max.poll.record=1000 ，fetch.min.bytes 默认值是 1 ，你说的小坑是什么场景呢？ 我理解的是只要有数据就会获取， 一次 Poll 最多拿 1000 条，如果不足 1000 条就拿剩余的条数回来。

@codedreamstar 我大概讲一下场景出来吧。 应用 A 设计之初并没考虑到那么长远，初衷也是能消费多快就消费多快。因此就用上了多线程异步处理数据。 处理数据这块其实也只是为了把数据存到 redis 里。 然后我们有另外的进程去从 redis 的队列里拿到数据，然后把这些数据再下发到下游（通过调用下游接口，简称应用 B ）。 目前消费的 topic 都是推过来的实时数据，因此各项的 tps 都能够满足；不过应用 B 是有一个峰值的 tps 的。之前来了个需求，新接入一个 topic （简称(topic-new)，topic-new 推过来的量是固定的，我这边撑这块业务为：存量初始化。 之前协商好上游提供 topic 过来的时候是控制速率的（因此原本我这边不用考虑限速限流的），后来因沟通问题上游又不作限速处理，最终限速操作只能在应用 A 这边进行。
针对限速这块其实我是有过几个思考方案的
方案一：直接搞一个 Spark 应用来进行存量初始化，Spark 在控制批量消费还是很好控制的
方案二：使用令牌桶对应用 A 特殊的 Consumer 进行限流
方案三：对应用 A 的流入和流出都作限流操作（后续一定会排期对数据流出作限流操作，但是听各位大佬的建议，好像并不推荐对流入数据也作限流操作）
综合考虑各种因素，目前是考虑使用方案二进行限流操作，当完成存量初始化之后就可以下线该 topic 了，后续先实现流出的限流功能，其他功能再考虑可行性。

@codedreamstar 你好大佬，应用本身设计就是为了尽可能多消费来使用多线程实现的。 目前多线程主要是用来处理数据，且消费者处理的消息是无关的，提到 offset 提交，其实在 poll 到数据后，就先手动把 Offset 保存到 redis 里，然后配置 auto.commit.interval.ms=1 秒去自动提供 offset ，拿到的数据是直接丢到多线程里去异步处理了，应用不需要关注到当前批次的 records 处理完后才更新 offset 。这一点并不是很关注，主要是后续应用处理数据的时候会有各种机制把数据丢到 redis 里，成功的失败的处理都丢到 redis 里。

@ymz 感谢大佬提供 springboot 注解的思路，目前应用并不是依赖 springboot 框架搭建的，但后续是有升级到 springboot 框架的需求的。后续在应用需要迁移重构的时候，我会着重构思注解的可行性可实现方式。

@Takamine 应用里并不需要严格关注 kafka 自动提交 offset 与处理完 records 的数目一致。 目前设置的 auto.commit.interval.ms 是 1 秒，而且应用也有手动每秒往 redis 里写入当前读写的 offset 。