根据这个属于JBoss文档的link，我理解 Infinispan is a better product than JBoss Cache 以及他们建议从JBoss Cache迁移到Infinispan的原因，这也是JBoss支持的原因 . 我理解的是对的吗？否则，有差异吗？
还有一个问题：谈论复制和分发，根据需要，其中任何一个都可以比另一个好吗？
谢谢
Question:
谈到复制和分发，根据需要，任何一个都可以比另一个好吗？
Answer:
我直接从Clustering modes - Infinispan参考
分布式：
份数表示数据性能和耐久性之间的权衡
您维护的副本越多，性能越低，但由于服务器中断而丢失数据的风险也越低
使用一致的哈希算法来确定群集条目应存储在何处
无需在每个节点上复制数据，这比仅仅传递哈希代码需要更多时间
如果没有节点高，则最合适
如果存储在缓存中的数据大小很高，则最合适 .
复制：
添加到任何这些缓存实例的条目将复制到群集中的所有其他缓存实例
此群集模式提供了一种在群集中共享状态的快捷方法由于需要发生的复制消息数量，
复制实际上仅在小型集群（10台服务器下）中表现良好 - 随着集群大小的增加
Practical Experience:
我在具有8个节点的Jboss服务器上运行的实时应用程序中使用Infinispan缓存 . 最初我使用了复制缓存，但由于数据量很大，需要花费更长的时间来响应 . 最后我们回到分布式，现在它的工作正常 .
仅对特定于任何用户会话的数据使用复制或分布式缓存 . 如果数据是通用的，则不管用户是什么用户而不是为每个节点单独创建的本地缓存 .
1 回答
Question:
谈到复制和分发，根据需要，任何一个都可以比另一个好吗？
Answer:
我直接从Clustering modes - Infinispan参考
分布式：
份数表示数据性能和耐久性之间的权衡
您维护的副本越多，性能越低，但由于服务器中断而丢失数据的风险也越低
使用一致的哈希算法来确定群集条目应存储在何处
无需在每个节点上复制数据，这比仅仅传递哈希代码需要更多时间
如果没有节点高，则最合适
如果存储在缓存中的数据大小很高，则最合适 .
复制：
添加到任何这些缓存实例的条目将复制到群集中的所有其他缓存实例
此群集模式提供了一种在群集中共享状态的快捷方法
由于需要发生的复制消息数量，
复制实际上仅在小型集群（10台服务器下）中表现良好 - 随着集群大小的增加
Practical Experience:
我在具有8个节点的Jboss服务器上运行的实时应用程序中使用Infinispan缓存 . 最初我使用了复制缓存，但由于数据量很大，需要花费更长的时间来响应 . 最后我们回到分布式，现在它的工作正常 .
仅对特定于任何用户会话的数据使用复制或分布式缓存 . 如果数据是通用的，则不管用户是什么用户而不是为每个节点单独创建的本地缓存 .