Terracota Ehcache 锁定客户端

Question

我将 Terracotta Enterprise Ehcache 与 Java 应用程序一起使用，但在一天中的某些时候，Terracotta 开始花费太多时间来响应 put/get 请求，有时会锁定客户端的线程并启动异常。

我的基础架构由一个包含 5 个 JBoss 服务器 6.2.0 的集群和另一个包含 4 个存储大量数据的 Terracotta Enterprise Ehcache 3.7.5 的集群组成。

该应用程序每天对 Terracotta Ehcache 进行大约 1000 万次访问。

• 最初我使用标准，但是当问题开始时，我将所有内容更改为仅使用 id 搜索。

• 我尝试更改 DGC 间隔，使其更频繁地运行，甚至每天只运行一次，但并没有好转。

• 我从持久化模式permanent-store开始并尝试更改为temporary-swap-only，但问题仍然存在。

• 尝试将 Terracotta 集群更改为与 2 台主动机器和 2 台被动设备或 4 台主动设备一起使用。

• 试图将我的缓存配置为真假。

• 我所有的缓存都是不间断的，我尝试将 timeoutBehavior 用作异常或 noop。

基本上我的任何努力似乎都没有产生任何重大变化，兵马俑继续进入无法再响应请求的状态。

目前唯一似乎“解决”问题的方法是重新启动所有客户端。

有没有人有类似的使用 Terracotta 的场景，具有这种吞吐量？关于现在去哪里找的任何想法？

Answer 1

是的，我在 terracota 集群设置中遇到了类似的线程争用问题。从属请求 get/put 过去常常需要时间，并且线程转储显示锁定是主要原因。我不记得细节了，因为那是 4-6 个月前的事了。那时我有两个选择：

• 创建一个自己的缓存服务器，这将是一个自定义战争，并将在下面运行 ehcache，并将我自己的 put、get、delete 等操作公开为 REST 端点。
• 使用 ehcache 提供的缓存复制。

我首先尝试使用 RMI 进行复制，然后使用 JGroups。基于 RMI 的方法运行良好并且非常稳定，因此我决定转向基于 RMI 的复制，而 ehcache 提供了 OOTB。我的设置是使用 ehcache 作为基于休眠的 JPA 和 RMI absed 解决方案的缓存提供程序，该解决方案运行良好且有效。它足够智能，可以查看集群中的其他服务器何时关闭以及何时启动。复制是异步且透明的。由于第二种方法效果很好，我没有尝试第一种。