Redis チートシート
[History] [Last Modified] (2015/09/13 18:06:40)
ここは
趣味のプログラミングを楽しむための情報共有サービス。記事の一部は有料設定にして公開できます。 詳しくはこちらをクリック📝
Recent posts
Popular pages

概要

Redis (REmote DIctionary Server) は KVS のひとつです。以下のような特徴があります。

  • string だけでなく様々なデータ型 (lists of strings, sets of strings, sorted sets of strings, string to string hash tables) をサポート
  • すべてメモリ上に保存するため高速
  • 既定の設定では数秒毎にディスクに書き出すため永続性がある
  • (多段) レプリケーションが可能
  • レプリケーションツリーのルートに Publish されたデータをスレーブで Subscribe する Publish-subscribe pattern
  • シングルプロセス/シングルスレッドでのみ動作

インストール

今回は動作検証用に以下のようにインストールします。バージョンが古いため実運用では最新のものをインストールしましょう。

$ sudo yum install epel-release
$ sudo yum install redis
$ sudo service redis start
$ sudo chkconfig redis on

コマンド

公式ドキュメントより抜粋。

$ redis-cli -p 6379
(or $ redis-cli -p 6379 `コマンド`)

データベース内のキーサイズ、一覧、サーバの情報

dbsize
keys *
info

データベースの切り替え (ログイン時 DB は 0)

select 0

文字列

set abc:xyz "ABC / XYZ"
get abc:xyz
del abc:xyz
expire abc:xyz 120
ttl abc:xyz

文字列 (数値)

incr mynum  ←setされていなければ "1" にインクリメント

リスト

rpush mylist aaa
lpop mylist
lpush mylist aaa
rpop mylist
llen mylist
lrange mylist 0 -1

集合

sadd myset key
srem myset key
sismember myset key
smembers myset
sunion myset myset2

集合 (スコアでソート)

zadd myzset 999 key999
zrange myzset 0 -1

ハッシュ

hset myhash key val
hdel myhash key
hmset myhash key1 val1 key2 val2
hincrby myhash num 10
hget myhash key
hgetall myhash

レプリケーション

例えば以下の設定で動作検証が可能です。

$ sudo cp /etc/redis.conf /etc/redis2.conf
$ sudo vi /etc/redis2.conf (↓のように編集)
$ sudo redis-server /etc/redis2.conf

/etc/redis2.conf

pidfile /var/run/redis/redis.pid
↓
pidfile /var/run/redis/redis2.pid

port 6379
↓
port 6380

# unixsocket /tmp/redis.sock
↓
unixsocket /tmp/redis2.sock

logfile /var/log/redis/redis.log
↓
logfile /var/log/redis/redis2.log

# slaveof <masterip> <masterport>
↓
slaveof 127.0.0.1 6379

vm-swap-file /tmp/redis.swap
↓
vm-swap-file /tmp/redis2.swap

マスターで SET してスレーブで GET

$ redis-cli -p 6379
$ redis-cli -p 6380

フェイルオーバー

マスターがダウンした際に自動でスレーブをマスターに昇格させるためには Redis Sentinel を利用します。v2.8 以降に付属しています。

構成

例: アクティブスタンバイの二台構成

192.168.50.1:6379 マスター
192.168.50.1:26379 sentinel
192.168.50.2:6379 スレーブ
192.168.50.2:26379 sentinel
192.168.50.2:26380 sentinel

想定される動作

  • マスタープロセスがダウン → sentinel プロセス三つが協調してスレーブをマスターに昇格
  • マスターホスト全体がダウン → sentinel プロセス二つが協調してスレーブをマスターに昇格
  • スレーブプロセスがダウン → 大きな変化なし
  • スレーブホスト全体がダウン → 大きな変化なし
  • マスターとスレーブの通信が遮断 → マスターの sentinel プロセスに大きな変化なし。スレーブの sentinel プロセスがスレーブをマスターに昇格 (スプリットブレイン)

本構成のメリット

  • 二台でシンプルなアクティブスタンバイ構成が実現
  • スレーブが落ちてもマスターはサービスを継続可能
  • マスターが落ちるとフェイルオーバーが可能

本構成のデメリット

  • マスターとスレーブの通信が遮断されるとスプリットブレインが発生する
    • この理由により公式ドキュメントでは推奨されていない
    • down-after-milliseconds を長めに設定することで発生頻度を抑えることは可能
  • 自動でフェイルバックできない (1/3 では過半数を超えないため)

クライアント設定

例: redis-rails クライアントの Sentinel 設定

config/environments/development.rb

# Use a different cache store.
# config.cache_store = :mem_cache_store
sentinels = [{host: '192.168.50.1', port: 26379},
             {host: '192.168.50.2', port: 26379},
             {host: '192.168.50.2', port: 26380}]

config.cache_store = :redis_store, {
  url: 'redis://mymaster',
  sentinels: sentinels,
  role: :master,
  db: 0,
  namespace: 'myapp_development_rails_store',
  expires_in: 90.minutes
}

config/initializers/session_store.rb

Rails.application.config.session_store ActionDispatch::Session::CacheStore, key: '_myapp_session', :expire_after => 2.weeks

例: redis-rb クライアントも使用する場合 (特に redis-namespace を併用する場合)

config/initializers/redis.rb

sentinels = [{host: '192.168.50.1', port: 26379},
             {host: '192.168.50.2', port: 26379},
             {host: '192.168.50.2', port: 26380}]

$redis = Redis::Namespace.new('myapp_development_redis_store', redis: Redis.new(
    url: 'redis://mymaster',
    sentinels: sentinels,
    role: :master,
    db: 0))

サーバ設定

192.168.50.1:/etc/sentinel-0.conf

port 26379
dir /tmp
sentinel monitor mymaster 192.168.50.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

192.168.50.2:/etc/sentinel-1.conf

port 26379
dir /tmp
sentinel monitor mymaster 192.168.50.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

192.168.50.2:/etc/sentinel-2.conf

port 26380
dir /tmp
sentinel monitor mymaster 192.168.50.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

192.168.50.2:/etc/redis.conf (一部抜粋)

slaveof 192.168.50.1 6379

Sentinel 起動コマンド

192.168.50.1$ sudo /usr/local/bin/redis-sentinel /etc/sentinel-0.conf
192.168.50.2$ sudo /usr/local/bin/redis-sentinel /etc/sentinel-1.conf
192.168.50.2$ sudo /usr/local/bin/redis-sentinel /etc/sentinel-2.conf

Sentinel 運用コマンド

redis-cli -p 26379

マスターの状態

sentinel master mymaster

スレーブの状態

sentinel slaves mymaster

Sentinel の状態 (自分自身を除く)

sentinel sentinels mymaster

現在のマスターへの接続情報

sentinel get-master-addr-by-name mymaster

フェイルオーバーが可能な状態か検証

sentinel ckquorum mymaster

手動でスレーブの一つをマスターに昇格

sentinel failover mymaster

発見済みの他の sentinels と slaves を忘れさせる

sentinel reset *
Related pages
    概要 Git を用いたプロジェクト開発を複数人で行う場合、サーバーでレポジトリ管理を行えると便利です。何らかの事情で GitHub や Bitbucket を利用できない場合は、サーバーを構築して GitLab をインストールします。ここでは特に CentOS 6 の場合についてインストール手順をまとめます。 コマンドを実行するサーバーの用意