为每个协作对象单独创建Fluid Framework容器是否属于反模式？

单对象对应单Container是否为反模式 #

单业务对象对应单个Fluid Container不属于反模式，反而属于官方推荐的主流实践方案。
你之前的判断是正确的：如果把多个无关业务对象的Shared Matrix塞进同一个Container，用户打开单个对象时会强制下载Container内所有的快照、操作日志数据，造成不必要的带宽浪费和首开延迟，在Shared Matrix数据量较大的场景下负面影响会被进一步放大。
你顾虑的大量Container占用内存影响扩展的问题无需担心：Fluid服务端原生面向海量Container场景设计，当前1000量级的Container完全在合理负载范围内。服务端实现了冷热数据自动换出机制，只有存在活跃协作连接的Container才会被加载到内存中，没有活跃用户的Container会被持久化到磁盘存储，不会长期占用内存资源，完全可以支撑高并发协作场景。

额外问题解答 #

• container是否会在某个时间点被自动“清理”？
  默认没有自动清理逻辑，所有Container的状态会默认持久化存储。如果是自行部署的Fluid服务，你可以自行配置过期规则实现闲置Container自动清理；如果使用托管式的Azure Fluid Relay服务，默认不会自动清理，数据会按你服务开通时配置的留存周期保留。
• 是否可以手动从fluid服务中移除/删除container？
  可以。如果是自行部署的Fluid服务，直接操作底层存储（通常为文档数据库、对象存储）删除对应Container的元数据、快照和操作日志即可；如果使用Azure Fluid Relay，可直接调用官方提供的管理接口删除指定Container，无需停服操作。
• 是否有办法查询fluid服务中当前存在的container总数量？
  可以。自行部署场景直接统计底层存储中的Container元数据记录数即可；如果使用Azure Fluid Relay，可通过Azure Monitor的指标面板直接查看总Container数，也可以调用对应管理接口拉取计数。

内容的提问来源于stack exchange，提问作者yohosuff