redisのmaster-slave構成で考えるべきことの話 - diary
結論 Redisは2.6を使おう master-slave構成を取る場合はclient-output-buffer-limitをちゃんと意識するべき 概要 redisはエッジトリガ型のnon-blocking I/Oを用いてシングルスレッドでソケットの読み書きをぶん回す構造で書かれています。 よってclientやslaveへ対してのreplyを行う際も、ソケット自体の送信バッファが溢れた際(EAGAINが帰った際)には一度イベントループに処理を戻し、またソケットが書き込み可能になってイベントループが自分を呼んでくれた時に続きをwriteします。 まあnon-blocking I/Oなんだから当たり前なんですが、送信処理を再入可能にするためにredisはアプリケーションレベルで出力バッファを持っています。 これは送信が終わり次第適宜解放されるものの、write自体が間に合わなくなると詰まって
redis2.8のttlが複雑怪奇だという話 - diary
結論 Redis 2.8(unstable)はttlの挙動が変わっているので気をつけろ 概要 http://trapezoid.hatenablog.com/entry/2013/02/10/035020 これの続きです。この記事の中で触れた、ttlコマンドの挙動に関してunstableから微妙な変更が加わっていました。どうやら2.8で入るっぽいです いままで(stable) ttlが自然数として表現できる場合には自然数を返し、なければ-1を返す そもそもexpireを設定していない場合も、-1を返す これから(unstable) ttlが自然数として表現できる場合には自然数を返す expireが存在するが、既にexpireすべき時間を迎えており、masterからのキー削除命令を待っているキーの場合には0を返す そもそもexpireを設定していない場合は、-1を返す そもそも指定したキーが
master-slave構成のredisでttl(expire)を持つキーを使う方法 - diary
いろいろあってめんどい。 ttlを指定したキーの実削除は、キーの参照があった際又は100ms毎に行われるttlを持つ全キーからのランダムルックアップによる検査により行われる 故に、短いttlを持つキーが多数存在する場合には、(実際に参照しない限り)実削除が間に合わなくなる(意図した時間に揮発しない)事がある これだけならまあ参照すればいいんですが master-slave構成時、slaveから見たキーの削除はmaster側からの削除命令が無ければ行わず、ttl < 0となったキーに関してもこれは同様に扱われる 故に、揮発されるべきキーがslaveから参照されても、実削除は行われず、(master側の定期実削除が間に合っていない場合)slaveはそのまま揮発されているべきキーの値を返してしまう 対応策は masterに対してgetを投げる master-slaveとは何だったのか… redi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
