Ключи кеша, пригодные для повторного использования Rails, не работают (по-прежнему содержит cache_version)

Question

У меня есть приложение Rails 5.2, которое настроено на использование новой широко разрекламированной функции утилизируемых ключей кэша .

Я могу подтвердить, что настройка включена в консоли:

Rails.application.config.active_record.cache_versioning
=> true

ActiveRecord::Base.cache_versioning
=> true

BlogPost.cache_versioning
=> true

С этим параметром blog_post.cache_key теперь возвращает стабильную строку, потому что cache_version фактически хранится в кэше.запись (как эта статья подробности):

blog_post.cache_key
=> "blog_posts/10317"

blog_post.cache_version
=> "20190417193345000000"

Но проблема в том, что даже если в консоли все работает, как ожидалось, я не могу видеть, как это работает, наблюдая за серверомлоги, потому что он продолжает генерировать cache_keys, которые содержат cache_version:

In my view:

<% cache(['blog_post_list_item_v2', blog_post, I18n.locale, browser.device.mobile?]) do %>
  ...
<% end %>

In the server logs:

Rendered blog/blog_posts/_blog_post_list_item.html.erb (2.5ms) [cache miss]
Read fragment views/blog/blog_posts/_blog_post_list_item:0bdff42a9193ea497e5ed4a9cc2f51e8/blog_post_list_item_v2/blog_posts/10317-20190417193345000000/pt-br/ (0.5ms)

Как видите, ключ кеша должен быть .../blog_posts/10317/, но на самом деле он содержит метку времени.

Answer 1

После отладки через код Rails я мог подтвердить, что key действительно был стабильным. То, что печатается в журнале сервера, включает версию только для целей отладки, но ключ, хранящийся в вашем кеше, на самом деле не содержит версию.

Версия хранится вместо этого в сериализованном объекте в кэше, который является экземпляром ActiveSupport::Cache::Entry и содержит attr_reader :version. Итак, если вы похожи на меня, вы бы предположили, что кеш (например, необработанный HTML) был сохранен непосредственно в memcached, но на самом деле он хранится в атрибуте value этого ActiveSupport::Cache::Entry (который также имеет version атрибут, если у вас включено cache_versioning), и весь этот объект сохраняется сериализованным в кэш.

Если вы хотите подтвердить это самостоятельно, вы можете проверить свой собственный журнал memcached в реальном времени. Если вы работаете на Mac, сначала остановите его (я предполагаю, что он был установлен вместе с homebrew) с помощью brew services stop memcached, запустите его на переднем плане с подробным режимом с memcached -vv и посмотрите на ключи, запрошенные rails. После того, как вы закончите изучение, brew services start memcached снова включит memcached в качестве демона.

Кроме того, если вы мигрируете по-старому (без утилизируемых ключей кеша), вы должны сначала стереть кеш с помощью Rails.cache.clear в консоли. Не забудьте сделать это и в производстве.

Если вы хотите больше узнать о том, как это работает, хорошее чтение - https://dzone.com/articles/cache-invalidation-complexity-rails-52-and-dalli-c, но отладка кода rails с помощью binding.pry была тем, что мне стало ясно.

Короче говоря, это очень блестящая реализация, на мой взгляд, и рециркуляция кеша просто делает его намного лучше (в статье цитируется DHH, говорящая: «Мы пошли от того, что смогли сохранить только 18 часов кеширования, я считаю, , 3 недели. Это был самый большой прирост производительности, который Basecamp 3 когда-либо видел. ')