[A decade of major cache incidents at Twitter](https://danluu.com/cache-incidents/) Twitterのキャッシュにまつわるここ10年の主要なインシデント - これまでのすべてのインシデントで、少なくともキャッシュのことが書かれています。実際、長い間、キャッシュはしばらくの間、サイトをダウンさせる1番の原因だったでしょう。 - 最初の半年間は、キャッシュサーバーを再起動するたびに、今の基準で言えばSEV-0でした。調子のいい日は、私が1つのキャッシュを再起動すると、（サイトへの外部からのリクエストの）成功率（SR）が95%になるかもしれません． - [[memcached]]を使用している。 - より一般的には、キャッシュは非常に単純であるため、分散システムの一般的な故障モードの比較的きれいな実例を示す良いソースとなる。 - 概念的には、キャッシュサーバは高スループット、低レイテンシのRPCサーバと、メモリやディスク、キーバリューインデックスなどのデータを管理するライブラリの組み合わせ。 - ャッシュはほぼ純粋な RPC ワークロードの近似と考えることができる - スケールとパフォーマンスが懸念される場合、キャッシュは頻繁にシャード・クラスタを使用し、分散システムの制約と落とし穴にさらされる - ただし、パフォーマンスが重視されるため、強く一貫した分散データベースのような他の作業負荷よりも同期の問題にはあまり重点を置いていない） - また、分散システムの性質上、キャッシュのユーザはこれらの故障モードにさらされ、ある種の分散システム故障のカスケード影響による故障の影響を受けやすく、また、それに巻き込まれる可能性もある。 - 以下のインシデントを見ると、そのほとんどが実際にはキャッシュのロジックのエラーによるものではなく、何らかの異常により、十分に緩和されないまま正のフィードバックループが暴走してしまうものであることがわかる。 - ですから、以下のインシデントを読むときは、キャッシュを呼び出すスタックの中でキャッシュより上位のもの、およびキャッシュが相互作用するスタックの中でキャッシュより下位のものと、キャッシュがどのように相互作用するかを念頭に置いて読むとよいかもしれない。 - 2011-08 (SEV-0) ... - 2018-06 (SEV-1)