@NerbraskaGuy mate50 的摄像头看下，裸机用很影响手感

@SteveRogers 并且 14 内部还重新布局了，散热也有提升，哈哈

@SteveRogers 那必须的啊，所以 14 基础版还是可以的，内存基带都有提升

@Alexc 信号和处理器无关，跟基带有关，这次 14 系列全系升级基带

怎么办理呢？

@rshinich 还有比 xs 信号更差的吗🐶

@ispinfx pro max 那么大那么重，不是谁都能接受的

@huaes 那感觉还得买个 mac mini 作为网关，不然只能装了 surge 的设备用

抢不到不代表抢手，也可能是备货量少

@huaes 你们聊的都不是一个东西，你这个只是机场分流

@zilil #25 国内三大运营商目前 5G 最多跑 1000M 多点

@noparking188 #13 是这样的，mafka 某个 topic 下面有几十个消费组（只有几台消费实例（机器）），spark 瞬间往 mafka 发了几千万消息，导致机器网卡瞬态流量非常大（网络流量约等于消费组数量*消息数*每条消息大小），cpu 瞬态使用率过高

所以在想是不是通过对 Spark 写入进行分布式限流，往 topic 里写慢点，这样消费组就不会出现瞬态负载过高的问题

消费端目前是只要来了立马消费

日版相机还有声音吗？

@zilil 国内跑 3000M ？上个图看下呢

@kkeep #5 是这样的，MQ 采用 mafka ，有多个消费组订阅 topic ，对于某个消费组来说，有很多无关消息（上亿），导致瞬态流量很大（虽然直接 return ），cpu 瞬态使用率过高

@noparking188 #9 是这样的，有个问题在于，MQ 采用 mafka ，有多个消费组订阅 topic ，对于某个消费组来说，有很多无关消息（上亿），导致瞬态流量很大（虽然直接 return ），cpu 瞬态使用率过高

@noparking188 #9 感谢，一般实践中是不会去控制"Spark 写 Parquet 文件"的速度，二是控制"DataX 之类工具读 Parquet 写 DB"的速度，是吧？

所以到我这块是要控制 MQ 消费的速度，而不是 Spark 发送 MQ 的速度

@kkeep #4 或者再假设一个场景，比如 Spark 将最终处理结果写入 DB ，但是 DB 的写入 QPS 有限，这块该如何限制呢？

@winglight2016 #6 或者再假设一个场景，比如 Spark 将最终处理结果写入 DB ，但是 DB 的写入 QPS 有限，这块该如何限制呢？