リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
Peercastでどんな配信してるか可視化してくれるサイト作った。 - キモブロ
http://peercast.kymt.me/ Peercastって、Peercastをインストールしないと見れないのでどんな配信やってんだよって思うこと多いし、実際そのせいでPeercastリスナーの大部分が失われてる気がする。これは機会損失だ。そこで各配信の映像情報をキャプチャして一覧してくれるサイト作ってみた。 仕組み 4つのスレッドで最大4つの配信にPeercastのプロトコルでアクセスし、先頭8秒後の1フレームを取得する。こうしたのは最初の8秒ぐらいはバッファのせいで映像情報が乱れていることが多かったから。 実装 Rubyのparallelライブラリがすごく便利だった。こんな感じにするだけで並列実行できる。 require 'parallel' Parallel.each([1,2,3,4,5], :in_threads => 2){ |number| # no operati
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
