V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Tongwin  ›  全部回复第 1 页 / 共 24 页
回复总数  480
1  2  3  4  5  6  7  8  9  10 ... 24  
19 小时 20 分钟前
回复了 coloz 创建的主题 宽带症候群 宽带因为挂 NAS 被封了
@hcocoa 是运营商扫你的服务,封境外 ip 只能起到防攻击效果吧?
19 小时 55 分钟前
回复了 coloz 创建的主题 宽带症候群 宽带因为挂 NAS 被封了
@hcocoa 我搞过 wireguard ,应该跟 tailscale 这些差不多。走 vpn 管道,相当于哪个设备要连局域网内的服务都要搞一次代理才能够连。 你这连 sp 应该也是同理。还是挺麻烦的。
低端口更容易被运营商扫到吧
80 天前
回复了 erwin985211 创建的主题 iPhone 关于 iphone16 基础班猜测(个人向)
手持 xsmax ,是现在 8200 买一台 15pm 还是等等 16pm 呢?
113 天前
回复了 rookie333 创建的主题 问与答 不懂就问,这种私服会有大哥玩吗?
请问下这种场景能实现么?
动态公网 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 。
@flmn 你好,你提到的小坑,设置 max.poll.record 的同时是需要配合 fetch.min.bytes 使用是吧,我理解的是,如果一条数据本身不小,fetch.min.bytes 应该是有一个默认值,如果 max.poll.record*单条数据的大小 > fetch.min.bytes 默认值,实际还是按照默认值可获取的数量来获取吧。
@1Q1 目前我就是用谷歌 guava 的 RateLimiter 来限制指定时间最多 Poll 几次
@liuhan907 是的,我现在就是用令牌桶来实现 1 秒只 poll 一次,设定 poll 的最大数量来实现
@dd31san 感觉思路是可行的。不过现阶段 consumer 配置是 auto.commit 自动提交偏移量的。如果改成手动提交偏移量,得重新评估影响范围了。
@zhaogaz 目前是优先处理一下特殊情况,后续我们会排期在流量出口进行限流。流量入口的限流我们也是有计划排期优化的。感谢
@lsk569937453 这个项目我是从前辈那里接过来的。 目前已经在线上稳定运行一段时间。目前是不适宜在短时间内重构它。只想着在现有的情况下,特殊处理一下这个量大的 topic ,这个 topic 后续会下线掉。
@ZZ74 其实就是应用部署在云上有多个实例,每个实例在创建的时候都会尝试去创建 consumer 获取分区。由于都是用同一个消费者组,最终也就只有 topic 分区数的实力能够获取到该 topic 的其中一个分区,我这样理解是没问题的吧?
@ZZ74 谢谢大佬提供思路。我的想法是,只需要计算好 topic 对应的分区,多实例消费 topic 的时候,只有获取到分区的实例才能消费到数据。计算一下分区数*限流量应该就可以得到想要的结果了吧?
1  2  3  4  5  6  7  8  9  10 ... 24  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2858 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 03:59 · PVG 11:59 · LAX 20:59 · JFK 23:59
Developed with CodeLauncher
♥ Do have faith in what you're doing.