@methane です。 ISUCON 7 本戦で最大のスコアアップできたポイントが、 status と呼ばれる重い計算の結果となるJSONのキャッシュでした。 近年のISUCONによくある、「更新が成功したら以降のレスポンスにはその更新が反映される必要がある」（以降は「即時反映」と呼びます）タイプの問題だったのですが、今回のように更新頻度の高くかつ即時反映が求められるデータをキャッシュする方法について、より一般的に解説しておきたいと思います。 即時反映が不要な場合 まずは基本として、即時反映が不要な場合のキャッシュ方法からおさらいします。この場合、一番良く使われるのは参照時に計算した結果を Memcached などにキャッシュし、時間で expire する方法です。 このタイプのキャッシュには、参照元が分散している場合（Webサーバーが複数台あるなど）に Thundering Herd
人間生きていると高確率で連打機能を提供するシステムを構築する必要が出てくることがあります． 例えばあるコンテンツについてボタンを連打することで「良いね」を表明するようなシステムです． 連打は楽しい！！ しかし実装する方としては純粋に楽しんでばかりはいられません． こうしたシステムは素朴に実装したとしてもある程度のトラフィックまでは耐えられるかもしれませんが，ある規模を超えると安定して機能提供する事は難しくなってくるかもしれません． ここでは，サーバサイドの話題を中心として，快適な連打機能を提供するシステムをどうすれば提供できるかを考えていきます (あくまで一例です)． 想定としては， あるコンテンツについてボタンが付いていて，そのボタンは連打が出来る あるコンテンツについてボタンが何回押されたかを取得できる というシステムを仮定します． なんとなく結論が分かる雑な図 本題 サーバを分離する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
