Webアプリケーションにおける Job Queue システムの構成例と Worker を作る際に気をつけること - blog.nomadscafe.jp
Webアプリケーション内で処理を直列に実行せずにJob Queueに回して非同期に実行することが多くなって来て久しいと思いますが、そのおすすめ構成と気をつけることについてつらつらと。 1) 既存のデータベースをキューとして使う構成例 １つ目はMySQLなどのデータベースをキューとして用いる例。既にアプリケーションで利用しているデータベースにキュー用のテーブルを作成して利用します。データベースを利用したキュー管理の仕組みとしてJonk、Qudo、TheSchwartzなどがPerlでは有名どころです。 依存するミドルウェアが増えないので最もシンプルな構成になると思います。 上記の図ではWorkerはアプリケーション内で実行することで冗長性を確保しますが、キューを格納するデータベースはSPOFになります。しかし、、データベースに障害があった場合キューだけでなくすべてのサービスが停止すると思われ
pjax こそが pushState + Ajax の本命 - punitan (a.k.a. punytan) のメモ
pjaxの前にpushStateとは AjaxとjQueryの説明は不要として、pushStateとはなんぞや。 pushStateを使ってブラウザの履歴に対する操作をし、HTMLの一部のみを書き換える動作でもブラウザの戻る／進む機能を実現できる方法のひとつ。Ajaxなページを再現し、かつURLを見慣れた方法で自然にpermalinkを表現できる。 有名なところではGitHubで使われてるアレ。 hash fragment (/#!/) ブラウザの履歴を機能させるため、URL の fragment (#) を使ってAjaxなページを実現する方法。一時期もてはやされた感があるが、さらなる「#!」URL批判 - karasuyamatenguの日記 など合理的な反論があり、これから導入するのはためらわれるところ。 有名なところではTwitterで使われているあの厄介者。 pjaxとは pjax
Hashbang(#!)なURLの恐怖
諸方面からお叱りの言葉しかいただけない#!なURLは様々な問題をはらんでいますが、来るべき未来(もうすぐですよ！)におけるメンテナンス性という問題についてAdactioで取り上げられていました。#!の表面的な凶悪さに思考停止していて、こういった本質的な問題についてはまったく考えていなかった気がします。 その問題というのは、#!なURLからHistory APIなどを利用してクリーンなURLに乗り換えよう(戻そう)としても、古い#!なURLを有効なままにするためにはサーバー側の何か(単純なリダイレクトやmod_rewriteなど)ではどうしようもないので、クライアント側での(JavaScriptを利用した)リダイレクトを提供する機能を提供し続けなければならないというメンテナンス性の悪さです。 この#!なURLのメンテナンス性の悪さという問題は、URLの#以降はクライアント側の扱いなので、クラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://boundio.jp/