生产环境中，有许多 1080p 的 jepg 图片要消费分析，这些图片大多数被分析后就不需要再保留了。 一种保险的方案是：把图片先上传到 S3 这种云存储服务，再将 url 发送到 kafka ，然后 consumers 拉取消息并下载图片分析，但其中 s3 的成本很高。 另一种方案是：把图片的 raw data 发送到 kafka 中，consumers 拉取并分析。但不清楚在生产环境中这样做会不会有很大的隐患。请问有成功的实践案例吗？
This topic created in 1334 days ago, the information mentioned may be changed or developed.
 |
zhchyu999Mar 14, 2023
1
带宽成本不高么
|
 |
suniceMar 14, 2023
2
不行的话先放到 redis 里面，用完销毁。kafka 也会磁盘多份存数据的
|
 |
sadfQED2Mar 14, 2023 via Android
3
你带宽，磁盘 io 足够的话，没啥影响。kafka 接受图片跟接收文本消息本质上没啥区别。但是你 1080p 的图片，怎么也有几兆吧，如果高并发大量推拉图片，肯定会把 kafka 集群的带宽跟磁盘 io 打满。满了以后影响就大了
|
 |
4
@sunice 用 redis 的话，确实不用考虑磁盘 io 的限制了。
|
|
5
@sadfQED2 嗯，峰值可能每秒 1 万多的图片，未来可能还得涨。
|
 |
tmsMar 14, 2023
6
用 redis 的话内存限制记得设置好。最好还是内网搞一个共享存储。
|
|
sadfQED2Mar 14, 2023 via Android
7
@OblivionStaff 峰值每秒一万张，一张按一兆算，那一秒也有 10G 了，你消费延迟 10 秒就有 100G ，就算你消费绝对实时，无论是 redis 还是 kafka ，都不会立刻删除数据，那你在 redis 或 kafka 将积压几百 G 或者 T 级别数据，这么大的数据量我感觉大概率出问题
就算你机器内存，磁盘空间，磁盘 io 足够高，一秒 10G ，你这得占多大的网络带宽啊，你这得把业务服务器，MQ 服务器带宽全打满吧 |
|
8
@sadfQED2 应该还是需要一个支持多节点读写的分布式文件存储服务。
|
Select Language