运行了两年的同步任务,还能继续支撑海量小文件的实时传输吗?

发布网友发布时间：2小时前

共1个回答

热心网友时间：2024-12-09 12:33

两年前，某互联网医院引入了RSync数据同步方案，旨在确保患者在就医期间能随时随地访问医学影像。该方案通过在院内存储服务器上挂载原始影像文件，并设置定时任务以实现影像文件准实时同步至云端对象存储OSS，供PACS系统调用，为患者提供服务。随着时间推移，日均文件数量显著增长，从最初的80w+增加至160w+，特定类型的文件占比超过总体文件的80%，导致同步过程出现严重延迟，从源端到OSS的时间长达24小时以上。

为何同类型文件数量剧增会引发如此严重的延迟？原始方案中，是否存在瓶颈环节？

回顾原始方案，医院为处理不同类型的影像文件（如CT扫描、MR磁共振检查、CRX射线），设置了单独的定时任务，每15分钟执行一次，对当日产生的不同类型的影像目录进行同步。然而，存储服务器上的影像文件目录呈树状结构，随目录层级的深入，文件数量呈爆炸性增长。每个PACS下存储1年文件，每日一个日期文件夹，每个日期下包含10+影像类型文件夹，每个类型下产生约600+影像文件夹，每个文件夹内包含10-1000个影像文件。因此，原始方案在设计时，为减少单次文件扫描量，将同步命令按影像类型拆分，但受限于无法预先得知且不可变更的文件夹命名规则，最大拆分只能到影像类型目录这一层，无法进一步细化至文件夹层级。当同类型文件增量明显，rsync在同步前进行的扫描耗时超过病患等待极限。

面临rsync漫长扫描等待、同步进度难以控制以及临时目录过大的问题，解决思路在于减小rsync单次扫描范围，减少其对目录的递归扫描判断。rsync几乎成为了海量小文件同步场景的唯一选择，但优化同步效率的常规方案也存在局限。

针对rsync的弊端，引入Sersync结合rsync方案，Sersync对监听事件进行过滤，记录发生变化的文件或目录名，并支持多线程同步，提高同步效率。然而，部署Sersync的同步服务器内核无法监听源端文件变化，导致方案不可行。因此，需探索其他同步方案。

引入Python脚本和RabbitMQ的解耦方案，实现文件遍历和同步的高效执行。生产者负责扫描目录并发送到RabbitMQ，相较于原始方案，下钻了一个目录层级，单次扫描文件量减少至原来的1/10。消费者则消费RabbitMQ中的数据并生成rsync任务执行。

优化措施包括：扫描去重、避免遗漏和校准检查。通过记录已扫描文件夹、比较文件数量和定期对比本地与云端文件列表，确保同步过程准确无误。

最终实现逻辑确保了文件实时同步，实际成效显著：每个影像文件从源端存储服务器同步至云端OSS的时间缩短至30分钟内，满足用户需求，提高了就诊患者的体验。