Redisよ安らかに眠れ: Garantia Dataが引き起こしたオープンソースの歴史上最大の強盗とは オープンソースRedisの歴史について、事実をはっきりさせましょう。 TL;DR 2024年3月20日Redis社は、これまでオープンソースとして開発してきたRedis 7.4ソースコードのライセンスを、Redis Source Available License (RSALv2)とServer Side Public License (SSPLv1)のデュアルライセンスに変更すると発表しました。この変更によりRedis社の許可なくRedisを用いたマネージドサービスなどを提供することができなくなります。 2009年1人の情熱的なエンジニアAntirezが作り出したRedisですが、2013年のGarantia Data社の介入により様々なドラマが勃発し2020年にAntirezはIP
「サーバーで付近の情報を通知するサービスのつくり方」 という、Geohashを使って近傍検索を実現する記事をみつけました。 最近Redisに関する記事を書いた関係で、 この記事をみて「GeohashはRedisと一緒に使うともっと便利だよ！」と思わず宣伝したくなったのですが、 MySQL5.7でInnoDBに空間インデックス(Spatial Index)のサポートが入ったので 「MySQLでももっと簡単にできるのでは？」と思い、 RedisやMySQLを含めたいろんなDBで近傍検索を実現する方法を調べてみました。 以前、スマートフォンのセンサを活用して花火の打ち上げ場所を推定するアプリを作った関係で、 地球上での距離計算の実装も気になったので、それについても調査してみました。 関連知識 GeoHash Geohash（ジオハッシュ） は緯度・経度を短い文字列に変換する方法です。 距離が近い
この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい
この記事は Perl5 Advent Calendar 2015 の7日目の記事です。昨日は、 @karupanerura さんの XSことはじめ でした。 今回は、RedisをPerlで扱う上での便利CPANモジュールを紹介します。大体 @shogo82148 無双になります。 Redis::Fast RedisクライアントはRedis::Fast一択です。Redis.pmが公式推奨のモジュールですが、これはPure Perl実装なのでパフォーマンスがそれほど良くありません。 Redis::FastはRedis.pm互換のインターフェースを持ったXSモジュールであり、内部的にはRedis公式のCクライアントであるhiredisのバインディングになっているので、安定していて使いやすいといえるでしょう。 my $redis = Redis::Fast->new; $redis->incr('
Redis で利用可能なコマンドを、公式ドキュメントからメモ。 CommandReference - redis - Project Hosting on Google Code 注記 ドキュメントの完全な和訳を目指している訳ではなく、メモを取りつつコマンドの概要をつかむ事が目的 原則として、コマンドのサンプルは、先頭から順に行ったものとする サーバに格納されているデータは、各コマンドのセクション間で引き継ぐものとする 引き継いでいない場合は、サンプル中でデータを準備するところから行っている コマンドリファレンスの引数の記法(意味)は、説明文中に補足がない場合は以下の通り <key> = キー <bytes> = 送信するデータのバイト数 <data> = 送信するデータ(String) <srckey> = 操作元のキー <dstkey> = 操作先のキー <member> = 操作対象
基本自由に決められますが、何かしら方針が欲しいですよね。 調べてみるとオフィシャルのページに書いてありました。 Try to stick with a schema. For instance "object-type:id:field" can be a nice idea, like in "user:1000:password". I like to use dots for multi-words fields, like in "comment:1234:reply.to". なので、user_id=1のusernameがkamepacaだったら、 user_id:1:username = kamepaca でいいと思います。Perl的には下みたいに入れておけば良いでしょう。 use Redis; use JSON; my $redis = Redis->new(server =
起動モード設定¶ daemonize(yes/no)¶ デフォルトではRedisは通常のプログラムとして動作します。必要に応じて 'yes' を設定してください。デーモンとして動作する場合は、Redisはpidを /var/run/redis.pid に書き込みます。
こんにちは、宇津井です。 弊社ではゲソてんというゲームプラットフォームを運営しております。ゲソてんではサービスリリース当初から主にキャッシュ的な役割でRedisを導入していました。つい先日の事ですが訳あってRedis 2.6からサポートされたRedis Sentinelを採用しました。今回は、採用に至った経緯をご紹介します。 簡単なシステム構成 パフォーマンスは良いし、Memcachedには無い便利な機能を提供するRedisですが約一年間運用していくつかの問題が出てきました。 Redisサーバーが突然高負荷に陥るするとWebサーバーも高負荷に陥るRedisのReplicationは張ってるけどアプリケーション側でRedis Slaveへフェイルオーバーしない（MySQLを直接参照する）Redis落ちると恐らくMySQLサーバーが耐えられない（落ちた事無いけど）という事で対策を行ってきました
https://www.youtube.com/watch?v=rP9EKvWt0zo 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのYao Yuが、大規模サービスのキャッシュにおいてRedisを活用する取組みについて紹介しています。 1) Redisを採用している理由 キャッシュだけで、ストレージとしては利用していない。 主なところでは、Twitterのタイムラインで利用している。ホーム画面であれ、ユーザ画面であれ、タイムラインはTweetのインデックスなので、key/valueストア型のRedisを利用するケースとして最適。 以前はmemcachedを使っていたが、問題になったのは、タイムラインでおきるread/writeは、（ユーザが閲覧している範囲に追加反映するということなの
Twilio というサービスで決済サービスの障害があったらしいが、恐しいことにこのサービス、 決済情報をRedisで管理していたらしい、というのをRedis作者、antirez氏のblogで知った。 Twilio incident and Redis - Antirez weblog この件に関しては、Twilio自体も 調査報告 を出している。簡単にまとめるとこういう感じだ: TwilioではRedisを single-master, multi-slave なレプリケーション環境で使用している ネットワーク障害で一時的に master-slave 間の接続が切れたことにより、master-slave間のデータの再同期が発生 この再同期がすべてのslaveに対して同時に発生したため、masterの負荷が高くなり、結果決済サービスの障害が発生 この負荷を解決するためmasterを再起動する
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
追記2013/03/11 2.6対応と差分表示対応いただきました！ @hirose31++ @fujiwara++ とある日 探してみたけどたしかにそれっぽいの無さそうだし 自分も欲しいし書くしか無い！！！！ というわけで書きました。 https://github.com/toritori0318/p5-App-RedisTop 使い方 help引けば大体わかると思いますが、いくつか説明します。 その１ 127.0.0.1:6379 のRedis情報を表示します。デフォルトだと３秒更新です。 redis-top その２ 複数インスタンスを同時に表示することも可能です。 redis-top -i 127.0.0.1:6379,127.0.0.1:6380,127.0.0.1:6381,127.0.0.1:6382 いくつか頑張ってみた点 依存を気にした cpanとか使わなくても、１ファイルを
皆様におかれましては、WEB+DB PRESSの最新号のRedis特集は既にご覧頂いたかと存じます。 弊社では1年ほど前から広告配信に関する様々な部分でRedisを使っています。まだ2.4系なので、2.6の新機能とか新鮮でした。 本番環境でRedisを運用する上で、強く訴えたい注意点は「RDBが壊れることがある」ということです。 「RDBがあるからインスタンスが落ちても平気だぜ」とか思ってると、RDBが壊れてリストア失敗→データ消失ということになりかねません。ファイルにdumpされるからと安心していると痛い目に遭うかも知れません。 （2013/02/27追記）今のところ壊れたのはハード障害が怪しい場面のみです。「RDB壊れるとかRedis使えねー」とかそういう話ではまったくありません。誤解無きよう。壊れる時はRedisじゃなくても壊れます。自分のユースケースではTokyo Cabinet/
具体的には Redis の subscriber なんですが、pub/sub の pub 側が publish し続けている状態で subscriber を再起動すると、落ちてから起動までの間に来たメッセージを取りこぼす可能性があります。 pub 側を一時停止すればいいのですが、fluent-plugin-redis_publish で fluentd から publish しているので、これを止めるのはあまりやりたくない。 複数の subscriber が同時起動して処理に問題が出ないように作られていることが前提ですが、新しい subscriber を起動したら古いのを殺すようにすればいいよね？ → それ Server::Starter でできるよ、という流れ。 $ start_server -- perl -e '$SIG{TERM}=sub{ warn "[$$] SIGTERM";
最近 Test::RedisServer とかもろもろつくっててばれてるかもしれませんが、だいぶ Redis 期にありまして、最近の趣味は？っていう問いにはだいたいRedisのソースを読むことですってなくらいなのですが、 memcached とかシンプルな KVS と比べるとだいぶ機能が豊富なので使い方を迷ったりとかそういう事例もあり、周りにもう少し使える人を増やさなければ僕の書いたコードが属人化しててつらい感じになるなーっていうわけで、 布教活動をおこなっておりまして、その一環として ISUCON2 に参加してきましたのでその報告です。 livedoor Techブログ : #isucon2 リアルタイムフォトレポート 更新終了 前回の優勝チームに混ぜてもらった感じでだいぶついてる感じもしますが、見事連覇を果たせ、懇親会でも redis redis と連呼してきたのでだいぶ興味持った方も
社内のだれからも+1みたいなリアクションされなくて切ないのですが 我が社の社内IRCにはunazu_kunというbotが生息しております。 みたいな感じで、モヒカンたちがうごめく殺伐としたIRCチャンネルに どうでもいいことでも頷いてくれる癒し系のbotなのですが、 たまに心の潤いを求めて話しかける人はいるものの あんまり役に立つ感じではなかったので、指定した時間になったら メッセージをそのまま教えてくれるリマインダー機能付けてみた話です。 botはPerlで動いてて、AnyEvent::IRC::ClientとかAnyEvent::DateTime::Cronとか使っていて 今回実装したのは、時間をkeyにして（例えば 10:00 => "1000"、9:9 => "0909"） valueを対象メッセージにする感じにしました。 my $r = Redis->new(server =>
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
