キャッシュとセッション
データベースが嫌がる負荷を引き取る
セッション、レート制限、フィーチャーフラグ、すべてのリクエストが読むホットな行。たいていのアプリケーションでこれらは Postgres の中にあり、叩かれ続けているのもそこです。データベースがそれらを苦手だからではありません。そもそも問い合わせではなかったからです。キーは、もう分かっています。
なぜ向いているのか
どれも同じ形をしています。すでに手元にあるキー、小さな値、そして寿命。kevy は参照を O(1) で行い、cron を使わずキー自身を期限切れにし、1 台のマシンで毎秒数百万回それをこなします。
見落とされがちなのが期限切れです。データベースの上に作ったキャッシュには掃除役が要り、バグはその掃除役に棲みつきます。ここではエンジンが、誰かに読まれるかどうかに関係なく、時間の来たキーを落とします。
手順
# a session that cleans itself up
SET session:7f3a '{"user":"ada","role":"admin"}' EX 3600
GET session:7f3a
TTL session:7f3a -> 3599
# a rate limit: one counter per client, expiring on a window
INCR rate:203.0.113.7 -> 1
EXPIRE rate:203.0.113.7 60
INCR rate:203.0.113.7 -> 2 (the window survives)
# feature flags: read constantly, written rarely, joined never
HSET flags new-checkout on dark-mode on beta-search off
HGET flags new-checkout -> "on"
HGETALL flags
# a cached row, invalidated by the writer rather than by a timer
SET user:881 "$json" EX 300
DEL user:881 # after you write to Postgres
何を差し出すことになるか
キャッシュは真実の 2 つ目のコピーであり、間違うことがあります。kevy はそれを解決しません——それを解決できるものは、ありません。タイマーではなく、書き込みで無効化してください。TTL は計画そのものではなく、最後の保険として置いておくものです。また、複数キーの MSET や DEL が原子的なのは、ひとつのシャードの中だけです。2 つのキーが必ず一緒に変わらなければならないなら、{hashtag} で同じ場所に寄せてください。