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