核心.cache中的多线程缓存雪崩

Question

我们最近在一个Web环境中部署了core.cache，并发现存在多线程访问的缓存雪崩问题。事后来看很明显，但文档中关于雪崩的提及让我以为这已被处理。

在Slack的帮助下，我在这里重现了该问题

(let [thread-count 20
      cache-atom (-> {}
                   (cache/ttl-cache-factory :ttl 120000)
                   (cache/lu-cache-factory :threshold 100)
                   (atom))
      latch (java.util.concurrent.CountDownLatch. thread-count)
      invocations-counter (atom 0)]
 (doseq [i (range thread-count)]
   (println "starting thread" i)
   (.start (Thread. (fn []
                     (cache-wrapped/lookup-or-miss cache-atom "my-key"
                                                   (fn [k]
                                                     (swap! invocations-counter inc)
                                                     (Thread/sleep 3000)
                                                     "some value"))
                     (.countDown latch)))))

 (.await latch)
 (deref invocations-counter))

我预计调用计数器会是1，但实际上是20（每个线程一次）。

Comments

根据使用core.memoize的建议，这同样可以按预期工作

    (let [thread-count 20
          invocations-counter (atom 0)
          expensive-function (fn [k]
                          (swap! invocations-counter inc)
                          (Thread/sleep 3000)
                          (str "value-" k))
          cache (-> {}
                    (cache/ttl-cache-factory :ttl 120000)
                    (cache/lu-cache-factory :threshold 100))
          memoized-function (memoize/memoizer expensive-function cache)
          latch (java.util.concurrent.CountDownLatch. thread-count)]
     (doseq [i (range thread-count)]
       (println "starting thread" i)
       (.start (Thread. (fn []
                         (memoized-function "my-key")
                         (.countDown latch)))))

     (.await latch)
     (assert (= 1 (deref invocations-counter))))

Answer 1

登录为 https://clojure.atlassian.net/browse/CCACHE-65

Comments

感谢，Alex！

Answer 2

看起来确实存在一个并发错误。在57行和67行，延迟的deref值通过swap!插入到缓存中。这个延迟只能执行一次，但是当许多线程同时出现相同的缓存缺失时，许多线程将会
解除引用一个值。因此，值被插入到缓存之前将会进行许多次执行。

https://github.com/clojure/core.cache/blob/master/src/main/clojure/clojure/core/cache/wrapped.clj#L57
https://github.com/clojure/core.cache/blob/master/src/main/clojure/clojure/core/cache/wrapped.clj#L67

要修复这个问题，封装的名称空间将需要在缓存中存储延迟并在检索时解除引用这些延迟。

当前版本的解决方案是自行进行这种封装

;; clj -Sdeps '{:deps {org.clojure/core.cache {:mvn/version "1.0.225"}}}'

(require '[clojure.core.cache :as cache]
         '[clojure.core.cache.wrapped :as cache-wrapped])

(let [thread-count 20
      cache-atom (-> {}
                   (cache/ttl-cache-factory :ttl 120000)
                   (cache/lu-cache-factory :threshold 100)
                   (atom))
      latch (java.util.concurrent.CountDownLatch. thread-count)
      invocations-counter (atom 0)]
 (doseq [i (range thread-count)]
   (println "starting thread" i)
   (.start (Thread. (fn []
                     ;; Deref the outcome
                     @(cache-wrapped/lookup-or-miss cache-atom "my-key"
                                                   (fn [k]
                                                     ;; Put the action in a delay
                                                     (delay
                                                       (swap! invocations-counter inc)
                                                       (Thread/sleep 3000)
                                                       "some value")))
                     (.countDown latch)))))

 (.await latch)
 (deref invocations-counter))

Comments

我认为在不破坏现有代码的情况下很难修复这个问题，因为API的每个路径都必须包装/解包这些新的延迟，包括需要包装提供的基本值中的每个值，这可能已经是一个组合的缓存数据结构。