Azure Service Fabric可靠集合技术疑问：能否替代SQL Azure及应用场景等

作为玩过Service Fabric有段时间的开发者，我来给你拆解这些新手常问的问题：

1. Reliable Collections 是否能替代 SQL Azure？ #

答案是不能直接替代，两者定位完全不同：

• Reliable Collections是为Service Fabric集群内的有状态服务量身打造的，主打低延迟、强一致性、和服务深度集成，适合存储服务自身的业务状态——比如会话数据、正在执行的流程状态、实时业务指标这些，它能自动帮你处理状态的复制、故障转移，不用自己写冗余逻辑。
• SQL Azure是通用的关系型数据库，擅长复杂查询、跨服务共享结构化数据、完整ACID事务支持，比如多服务依赖的订单库、用户信息库，或者需要做报表分析的历史数据，这些场景还是得交给SQL Azure。简单说，Reliable Collections管服务“自己的事”，SQL Azure管跨服务的“公共事”。

2. 是否可替代数据库系统？ #

和上面的逻辑一致，不能替代通用数据库：
Reliable Collections的核心是服务本地的可靠状态存储，它的优势是和Service Fabric的服务生命周期绑定，比如服务扩容、节点故障时，状态会自动跟着服务实例迁移。但它不支持通用数据库的很多特性：比如复杂的JOIN查询、二级索引、多租户数据隔离的高级方案、跨服务的分布式事务（它只支持服务内部的事务）。如果你的场景需要这些，还是得搭配传统数据库使用。

3. 是否仅支持跨进程/节点状态共享场景？ #

当然不是，这是常见误解：
它首先是为单节点的有状态服务提供持久化状态存储设计的——即使你的服务只跑在一个节点上，Reliable Collections也会把状态持久化到本地磁盘，同时在集群内复制备份，保证节点故障时状态不丢失。跨进程/节点共享只是它的附加能力：同一个服务的多个实例（分布在不同节点）可以访问同一个Reliable Collection的状态，Service Fabric会自动处理一致性和同步，不用自己写分布式锁或者同步逻辑。

4. 是否仅应作为优化缓存使用？ #

绝对不是，这完全低估了它的价值：
缓存的核心是“临时、可丢失、加速访问”，但Reliable Collections是持久化、强一致的可靠存储，它的设计目标是替代服务自己管理的本地文件、内存状态，或者那种“缓存+持久化数据库”的组合。比如你可以用它存储用户的购物车状态、正在处理的支付订单——这些数据不能丢，而且需要实时一致，用Reliable Collections比缓存靠谱得多。当然硬要把它当缓存用也可以，但那是大材小用。

5. Reliable Collection的典型规模是多少？ #

行业内的推荐实践是单个Reliable Collection控制在0-5GB范围内：
超过5GB的话，会带来几个问题：一是复制到多个节点的时间变长，影响故障转移的速度；二是内存占用会增加，拖慢服务性能；三是备份恢复的时间会变长。如果你的数据量超过这个范围，建议拆分多个Reliable Collections，或者把非活跃的历史数据迁移到Blob Storage、SQL Azure这类存储系统，只把实时需要访问的活跃数据存在Reliable Collections里。

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