Redis 本番障害から学んだコードレビューの勘所
Redis不適切利用による問題は本番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100本くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... （この話は事実ではなくファンタジーです。） 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以
真剣にRedisを使ってみようという気持ちになったのでRedisについて知っていることを書く - なんかかきたい
年末ですね。更新がおろそかになっていたので、たまにはちゃんとした話をしたいなと思い、前々から書こうと思っていたRedisの話を書いてみました。 検証に使用したRedisは3.2ですので、新しくバージョンが変わると以下の話は変わってくるかもしれませんが今のところそのようなことはしばらくなさそうです。 以下長々とRedisを本当に使えるように設定したり調べたり検証したりした内容を書いていきます。 いまさらですが Redisは構造データを持てるオンメモリデータベースサーバで、RDBとは違いますがHashやListなどのデータ構造を記録することができる高速なストレージサーバです。 オンメモリDBでHashを持つことができるので、KVSのように扱われることもあるのですが、memcachedと比較すると機能は多く、レプリケーションやAtomicなデータ処理なども可能です。 導入の前に Redisに限っ
ソシャゲ開発経験から学んだゲームに Redis を使う際の Tips
近年の KVS では割と Redis が覇権を取っていることもあり(当社比), 社内の多くのプロジェクトで Redis を使用するようになりました. ということでノウハウ的なのも溜まってきたのでまとめたいと思います. (大量のユーザーデータを扱うソシャゲにしか当てはまらない部分もあるかと思います) 単純にパフォーマンスを RDB < Redis と思い込んでとりあえずでキャッシュしない 「Redis は速い」と言われますが, インデックスをちゃんと貼った RDB のクエリも そこまで遅いわけではありません. 結局通信コストの方が遥かに大きいので内部の 取得時間差はトータルで考えると多くの場合誤差です. 特に RDB の主キーのみで取得できるようなデータを Redis にキャッシュすることに メリットはありません. キャッシュするコードを書くコストの方が高くつきます. キャッシュするのは R
コマンドリファレンス — redis 2.0.3 documentation
古いキー oldname を新しいキー newname にリネームする。もし新しいキーがすでに存在する場合、上書きする。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
