You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ロック機能のポイントはSETNXです。 指定したキーがなかった場合は値をセットして1を返し、 既に存在する場合は何もせず0が返ってきます。 つまり、1はロック成功、0は他からロック済みと判断することができます。 それでは実装に進みましょう。 まずロックのインタフェースを用意します。 public interface Lock { public void lock() throws TimeoutException; public void unlock(); } 最低限のロックとアンロックを用意しました。 続いて中身を実装します。 public class RedisLock implements Lock { private static final String LOCK_KEY_PREFIX = "lock:"; private static final int LOCK_EXPIR
人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 mrubyでKey-Value Storeにアクセスできるクライアントをこれまでいくつか作ってきたので、VedisやHashの性能が見たいというのと、その他ちょっとした興味でそれぞれのKVSのSET/GETを投げてみて速度の比較をしてみました。 といっても、それぞれの良さを考慮したベンチマークではなくソフトの良し悪しを測るものではないので、この条件だとこういう結果になるという参考程度に見て頂ければと思います。 比較対象は、mrubyのHash、Redis、Vedis(In-Memory)、Vedis(On-Disk)、Memcachedです。それぞれ、Fedora19のyumでインストールした後にserviceコマンドで起動させただけの状態で
Redis をキャッシュストレージとして利用する場合、 maxmemory によって利用可能なメモリの最大値を指定できる。 maxmemory の値を超えるデータの追加が発生した場合の振る舞いを maxmemory-policy によって指定できる。デフォルトの maxmemory-policy は volatile-lru で、 LRU アルゴリズムに従って古いキーの値が優先的に破棄される。 maxmemory-policy は数種類から選べるが、そのうち noeviction を選んだ場合、古いキーの値は破棄されず、新規追加はエラーとなる allkeys-lru または allkeys-random を選んだ場合、 expire の有無に関わらず、全てのキーの中から破棄対象が選ばれる その他を選んだ場合、 expire がセットされているキーのみが破棄対象となる という違いがある。実装
オンメモリ KVS の Redis では、使用メモリに上限を設定し、閾値を超えた場合のポリシー(maxmemory-policy)を複数の中から設定できるようになっている。 パラメータとポリシーを整理したのが以下 使用メモリの上限値 redis.conf の次のパラメータで設定する。 maxmemory maxmemory-policy メモリ使用量が閾値を超えている状況でキー追加する場合の振る舞いを定義する。以下の 6 つの maxmemory-policy から選択できる。 volatile-lru : remove the key with an expire set using an LRU algorithm allkeys-lru : remove any key accordingly to the LRU algorithm volatile-random : remove
起動モード設定¶ daemonize(yes/no)¶ デフォルトではRedisは通常のプログラムとして動作します。必要に応じて 'yes' を設定してください。デーモンとして動作する場合は、Redisはpidを /var/run/redis.pid に書き込みます。
Redisのメモリ使用量がmaxを超えた場合の挙動について検証してみた。 環境: version: 2.4.16 Redisではタイムアウト時間を設定したキーは時間を超えると自動で削除され、タイムアウト時間を設定しないと永続的に保存される。 また、メモリの空き領域がなくなった場合、期限のあるものから削除されていく(デフォルトの設定の場合)。 注意すべき点は、期限が設定されていないキーは削除対象にならないということである。 実際にその挙動を検証してみた。 まず、検証しやすいようにメモリの使用可能な量を以下の値に設定しておく(redis.conf) #新たにキーを保存した際にmaxmemoryエラーにならないぎりぎりの値 maxmemory 910KB maxmemory-policy は 以下を設定 #LRUアルゴリズムを使用して期限切れになったセットのキーを削除 maxmemory-pol
Twilio just released a post mortem about an incident that caused issues with the billing system: http://www.twilio.com/blog/2013/07/billing-incident-post-mortem.html The problem was about a Redis server, since Twilio is using Redis to store the in-flight account balances, in a master-slaves setup, with multiple slaves in different data centers for obvious availability and data safety concerns. Thi
Redis in Action 作者:Carlson, Josiah L.Manning PublicationsAmazon Redis 広告配信やっています@yutakikuchi_です。 Redisの内部処理が1スレッドで受けているようなので、マルチプロセスからRedisに書き込み処理を大量に流した時にどうなるのかを検証してみました。言語はCを、Libraryはhiredisを使います。redis/hiredis hiredisを使って単一プロセスで実行した場合と、Apache Moduleにhiredisを組み込んでマルチプロセスの実行状態で検証します。検証機はCentOS6.4です。 hiredis Redisのinstall、version確認、起動 RedisのVersionは2.4.10です。 $ sudo yum install redis -y $ redis-serv
はじめまして。バックエンドエンジニアの吉田です。 2013年5月末の入社以降、大量のEC2インスタンスのVPC移行を担当した後、今はiQONの商品DBを支えるクローラーの改善に取り組んでいます。今回はその改善の1つとして開発したRedis::DistMutexという分散ロック機構のruby実装を紹介をしようと思います。 Redis::DistMutex 開発の経緯や細かい設計の話は後述するとして、まずはつくったgemの紹介をします。 Redis::DistMutex Redisベースの分散ロック機構 rubyのライブラリにあるMutex互換 スレッド間だけでなく、プロセス間・ホスト間でも共有できるMutex 時限つきロックの作成が可能(redisのsetnxとexpireを活用) namespaceを指定できるので、特定の処理ごとにロックの作成が可能 redis2.6以上のみサポート(1秒
どうも初めまして2012年度入社の社内ニート予備軍editnukiです。 普段は引きこもって WebSocketで監視もリアルタイムに を書いた社内ニートさんの下でコミュニティサービスのインフラをやっております。 運用面以外ではrpmパッケージ作ったりしています。 さて、本題ですがコミュニティサービスでもredisを利用したいという声が最近多くなりいくつかのサービスではredisを導入しているのですがマスターとなるredisが死ぬと更新系が一切できなくなるため、マスターが死んだ時はアプリの向き先をスレーブに変更しなければなりません。 今までのredisの構成としては下図の様な構成でした。 redisの2.6系がリリースされた時に「sentinel」というフェイルオーバーの機能が追加されました。 詳細は公式ドキュメントをご参照ください。 フェイルオーバーしたとしてもアプリ側にマスターが切り替
ゴクロの大平です。ごくろうさまです。 Redisは高速で、かつデータの永続化や、複数のデータ型によるストア(list,set,sorted set等)も対応しており、機能的が豊富ということから愛用者の多いKVS実装の一つだと思います。 特に私のようなアプリケーションエンジニアの人間にとってはデータ型のバリエーションの豊富さが便利さを感じる部分で、たとえばlistを用いてタイムライン的な情報や履歴情報の管理、sorted setを用いてランキング情報の管理、などのようにアプリケーションの需要の多くにRedisが対応することができます。 これらの情報を登録する際のフローとしては自作のアプリケーションから直接、というケースが多いと思いますが、せっかくFluentdのような便利なlog collector実装があるので、FluentdとRedisを組み合わせる事でカジュアルに情報の蓄積を行いたい
I recently rewrote my personal site using flask and peewee, breaking a good amount of stuff in the process. I was trying to track down the errors by tailing log files, but that didn't help alert me to new errors that someone visiting the site might stir up. I thought about setting up error emails a-la django, which is a tried and true method...but then I happened on a different approach. I won't s
RQ (Redis Queue) is a simple Python library for queueing jobs and processing them in the background with workers. It is backed by Redis and it is designed to have a low barrier to entry. It can be integrated in your web stack easily. RQ requires Redis >= 3.0.0. Getting Started First, run a Redis server. You can use an existing one. To put jobs on queues, you don’t have to do anything special, just
Flask is a lightweight WSGI web application framework. It is designed to make getting started quick and easy, with the ability to scale up to complex applications. It began as a simple wrapper around Werkzeug and Jinja and has become one of the most popular Python web application frameworks. Flask offers suggestions, but doesn't enforce any dependencies or project layout. It is up to the developer
pyresって pyres は Redis をバックエンドに使った、ジョブキューサービスを 提供するPythonモジュールです。 ワーカに実行させたいジョブをあらかじめ登録しておき、 実行したい時にエンキューして使います。 同じような用途のモジュールには Celery なんかがあります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く