Magentoでセッションキャッシュとバックエンドキャッシュの両方に単一のRedisインスタンスを使用するのは悪い考えですか？

Question

Magento（v1.9以下）では、セッションとバックエンドの両方のキャッシュに単一のRedisインスタンスを使用できますか？余分な設定は必要ですか？

Answer 1

セッションとバックエンドの両方のキャッシュに同じインスタンスを使用するのは、唯一の潜在的な問題がスペースを使い果たしているためです（ElastiCacheを使用してAWSを使用している場合は問題ありません）。

異なるポート番号も必要ありません。異なる "データベース番号"を指定するだけです。以下は設定例です：

<cache> 
    <backend>Cm_Cache_Backend_Redis</backend> 
    <backend_options> 
     <server>$REDIS_CACHE</server> 
     <port>6379</port> 
     <persistent></persistent> 
     <database>1</database> <!-- DIFFERENT DB NUMBER --> 
     <password></password> 
     <force_standalone>0</force_standalone> 
     <connect_retries>1</connect_retries> 
     <read_timeout>10</read_timeout> 
     <automatic_cleaning_factor>0</automatic_cleaning_factor> 
     <compress_data>1</compress_data> 
     <compress_tags>1</compress_tags> 
     <compress_threshold>20480</compress_threshold> 
     <compression_lib>gzip</compression_lib> 
     <use_lua>0</use_lua> 
    </backend_options> 
    </cache> 
    <session_save>db</session_save> 
    <redis_session> 
    <host>$REDIS_CACHE</host> 
    <port>6379</port> 
    <password></password> 
    <timeout>2.5</timeout> 
    <persistent></persistent> 
    <db>2</db> <!-- DIFFERENT DB NUMBER --> 
    <compression_threshold>2048</compression_threshold> 
    <compression_lib>gzip</compression_lib> 
    <log_level>1</log_level> 
    <max_concurrency>6</max_concurrency> 
    <break_after_frontend>5</break_after_frontend> 
    <fail_after>10</fail_after> 
    <break_after_adminhtml>30</break_after_adminhtml> 
    <first_lifetime>600</first_lifetime> 
    <bot_first_lifetime>60</bot_first_lifetime> 
    <bot_lifetime>7200</bot_lifetime> 
    <disable_locking>0</disable_locking> 
    <min_lifetime>60</min_lifetime> 
    <max_lifetime>2592000</max_lifetime> 
    </redis_session> 

Answer 2

1つのインスタンスを使用することはできますが、引き続きそれぞれのインスタンスに別々のデータストアを使用します。 6379と6380が、同じRedisサーバー上にあります。

Magento側から別のインスタンスを作成するよりも、余分な設定は必要ありません。

Answer 3

私は別のインスタンスをお勧めします。 同じデシベルを持つ単一のインスタンス上の利点、あるいは異なるDBS

1. スペースと構成制御：あなたはあなたのキャッシュがあまりにも多くのRedisのスペースを取っているため、ユーザーをログアウトしたいとは思わないでしょう。いくつかのページキャッシュを格納するredisオブジェクトは、セッションデータキーが追い出される可能性があります。

2. キー名のスペーシングコントロール：キーは懸念事項に基づいて分離され、フラッシュなどの機能を使用してすべてのキャッシュをクリアしたり、大きな変更を加えてユーザーをログアウトすることができます。パターンでキーを削除する必要はありません。