アリの姉妹REVIEW：キャッシュは、多くの場合、解決のパフォーマンスのボトルネックに使用し、高性能な並行システムを構築するために不可欠な手段の一つである基本的な知識のプログラマですが、また、必要なテストサイトにインタビュー。
システムのパフォーマンスを懸念していない可能性が高いのプロダクトマネージャー、が、しかし、プログラマは、同時ユーザーの量と需要の実現にホストされているシステムの量を考える必要があります。キャッシュは主にパフォーマンスのボトルネックの問題を解決するために使用され、一度はシステムクラッシュにつながる誤用。今日、我々は体系的4Wによってキャッシュ関連する理論的な知識をまとめます。
ユーザーとインターネットトラフィックの急増、アプリケーションアーキテクチャの絶えず調整したりしても、この事業の急速な発展に適応するために再構築する必要性が急速に反復して。急速に成長しているデータの量、より複雑なビジネスロジック、サービスのリンクを増やすので、問題の範囲には、長すぎるRTにつながる場合には、徐々に、より良いユーザーエクスペリエンスを満たすためにサービスのパフォーマンスのニーズを向上させます。一般的スケールアップのために使用される2つの方法のシステムアーキテクチャを最適化し、スケールアウト、スケールアウトを水平スケーリング、無国籍に設計されたアプリケーションサービスとして知られており、簡単にハードウェアへのアクセスを増加させることによって、分解圧力のレベルを展開することができます。単一のサービスリフトアップスケールは、リンク性能を吸引し、そしてQPSスループットシステムを強化します。より良い性能の追求では、ビジネスシナリオのほとんどは、通常のキャッシュの導入によって解決、多くの場合、より少ない読み書きされます。
1. What--キャッシュとは何ですか？
既存のデータのコピーのために存在しなければならない、いわゆるキャッシュの定義からわかるように、また、データ（読み出しデータ）を解決するためにシーンへの迅速なアクセスのためにキャッシュ使って見ることができます。既存のインターネットアプリケーションでは、キャッシュの使用は非機能要件に出席するために迅速に対応するサービスが、また、プロダクトマネージャーを高めることができる重要な技術であり、それはビジネスシーンへの技術ソリューションの設計に必要である、の前向きな評価を持っています、この非機能要件という技術的なアーキテクチャのキャッシングソリューションの必要性を導入することを決めました。
例えば、CPUのキャッシュのようなコンピュータの分野の多くのケースでは、キャッシュの実際の存在は、データがCPUとメモリ不均衡問題の動作速度を読み取る解決するものであり、CPUの動作速度がはるかに速く読み出すと、メモリの書き込み速度、CPUの待機データを減少させるため時間を読む、CPUにL1 / L2 / L3マルチレベルキャッシュの導入。
別の例では、実際に我々は、プログラミングであるデータメモリアドレスに話をしますが、我々は仮想アドレスではなく、実際の物理アドレス、コンピュータのメモリ管理ユニット（MMU）とページテーブルと接触している、Linuxのファイルキャッシュですこれは、仮想アドレスを物理アドレスに配置します。あなたがアプリケーションのキャッシュの多くを持っている場合は、コンピュータハードウェアの分野では、実際には、キャッシュ上のソフトウェアアーキテクチャの設計は、思想とコンピュータのハードウェアキャッシュの成熟した設計の多くの伝統から借りれます。
なぜ2. Why--必要がキャッシュを使用するには？
ソフトウェアサービスは、ユーザーの信頼を得ることができ、それが使用することを決定します最初のユーザーを発行することを決めた、またはされたターゲットユーザの痛みのポイントを解決できる製品のユーザーの価値をもたらす「成長ハッカーは」にもたらすことができる製品に言及しましたユーザー「なるほど瞬間」、および使用することを決めただけでなく、高周波、ユーザーが使用し続けますと、ユーザーエクスペリエンスをユーザーの粘りを強化するためのソフトウェア製品の主要な要因であると考えられています。
2.1ユーザーエクスペリエンスとは何ですか
ユーザーエクスペリエンスは、ドナルド・ノーマンの説教によって普及、1990年代に拡張するために、プロのニーズを定義し、促進することです。ユーザーエクスペリエンスは、人間とコンピュータの相互作用の分野に真剣に、そして伝統的なユーザビリティ指標（すなわち効率性、有効性と基本的な満足度）を1回と3パーされています。
公式の定義とISO 9241-210標準的なユーザー体験：人々が使用したり、製品、認知印象と応答システムやサービスを使用することを期待されています。特に、使用前と使用後のユーザー、感情、好み、認知印象、心理的反応や感情表現の使用、および非常に多くの主観的な感情は、すべてが含まれ、ユーザーのためのソフトウェア製品であるユーザー体験の主観的知覚に見ることができますソフトウェア製品は、ほとんどのユーザーは、それ自体が非常に困難なことである優れたユーザーエクスペリエンスを得ることができます許可に異なる製品、異なる懸念の主観的な感情上のユーザの視点が発生します。
業界のほとんどは、ユーザーエクスペリエンスは、3つのカテゴリに分類されています（製品環境で同様の製品のユーザー環境だけでなく、製品）ユーザステータス、ソフトウェア製品と環境性能、利用者の状態や環境この2つの要因のに必要克服するために、他の学生とプロのインタラクションデザインと研究の分野では、ソフトウェア開発者は、システムのパフォーマンスの問題に対処する必要があります。ユーザーのために、最も基本的なニーズは、ソフトウェア・サービスの利用である、ソフトウェア製品は、一般的に貧弱なユーザーエクスペリエンスにつながる継続的なロード（ターン菊）の過程で言及された、タイムリーなサービスを提供します適時性は、システム・パフォーマンス・コンテンツの最小要件です。
システムのパフォーマンスの問題は、ポイントに出席するためにプロダクトマネージャーですが、また、非機能要件は、場所を考えるためにいくつかの努力をして、開発者が必要です。システムの性能を評価するための指標は何をするか、ユーザーエクスペリエンスを強化する前提の場合には、我々はパフォーマンスメトリックに焦点を当てる必要があります、多くのですか？
2.2一般的なパフォーマンス指標
応答時間、遅延、スループット、同時ユーザーおよびリソース使用率の数：ソフトウェアアーキテクチャの設計におけるいくつかの一般的な指標は注意が必要です。
1）システム応答時間：応答時間が異なる長さのリンク、例えばこれられるようにデータの異なる量の異なる応答時間に同一の機能および結果の異なる機能に応じて、ユーザシステムに対して要求を行うための時間です。システムの応答時間を測定する場合したがって、平均応答時間は、通常、すべてのソフトウェア製品の機能と最大応答時間を懸念しています。
2）遅延時間：システムの応答時間を議論する場合、よりきめ細かいパーティションを分けることができます。
クライアントのコンテンツデータ「現在時刻」を受信するにレンダリング。
ネットワーク伝送時間とアプリケーションの遅延時間：サーバへのユーザ要求を受信するサーバ、およびサーバの両方のプロセスが関与してクライアントにデータを返します。サーバはそれが取る全体のサービスのリンクを実行した時間ですが、また、パフォーマンスの最適化は、この時間を短縮することが重要であるアプリケーションの遅延時間。
3）スループット：スループット要求の数を意味する非同時アプリケーションのために、単位時間当たりに処理することができ、スループットおよび応答時間は、サービス遅延が長く低いシステムスループットであり、要求に反比例します。
同時ユーザー数4）：システムが同時にスループットに比べてシステム機能の通常の使用を運ぶことができる同時ユーザー数は、ユーザーの数を指し、この指標は、より一般的であるが、非ソフトウェア分野における人々のために理解しやすいです。
5）リソース使用率：リソース使用率は、いくつかの時間のために占有するリソースを反映しています。
2.3キャッシュのメリット
より良い最適化の追求の経験では、目的は常にどんどん近づいて最適解システムの経験、上記のこれらのインデックスのパフォーマンスを改善する必要があります。最後利点の種類、我々は構造を設計するために多くの労力を費やす必要がありますでのキャッシュがよく、現在のビジネスシナリオのキャッシュ、それに適していますか？
1）大幅にユーザーエクスペリエンスソフトウェアを強化
软件产品主要围绕两个核心问题，一是解决目标用户的痛点问题，二是提升产品黏性。在提供软件服务时，抽象的来看是解决数据在整个链路上的流转问题，如何让数据流转更加高效、更加顺畅是在实现时着重关注的地方，事实上，无论是浏览器、负载均衡、应用服务器还是数据库等等各个环节都会应用到缓存，当数据离用户“更近”，比如数据副本在客户端上，也就意味着请求能够很快的进行响应，相应的给用户进行数据呈现的耗时就更短。现如今用户爸爸们“日理万机”，如果一个软件产品不能在很短时间就获取用户的注意力，很大可能性就意味着失败。因此，使用缓存能够让用户从主观上获取更优的用户体验。
2）提升吞吐量
试想，如果在服务链路上，请求能够在缓存中获取服务数据的话，也就意味着很多数据并不需要从源应用服务器进行获取，降低了源服务器网络传输的频率，在一定IDC带宽下，系统能够降低网络传输时间以及应用延迟时间，从而支撑更多的系统访问以提升系统整体吞吐量以及并发用户数，硬件的使用效率也会明显提升。
从实际场景下，在系统性能优化时大概率会优先选择使用缓存进行系统优化，也是一种被证明有效的手段，缓存也被认为是一种“空间换时间”的艺术。
3. Where——缓存存在链路中的哪些地方？
3.1 缓存分类
从一个请求到最终获取响应，会经过很多环节，缓存可以几乎存在整个链路的每个节点。缓存按照不同的维度可以有如下分类：
1）缓存所处链路节点的位置：
客户端缓存
网络缓存
服务端缓存
2）缓存架构部署方式：
单机缓存
缓存集群
分布式缓存
3）缓存的内存区域
本地缓存/进程内缓存
进程间缓存
远程缓存
按照缓存在服务链路上的位置来划分，可以系统性的梳理下缓存的不同应用。
3.2 客户端缓存
客户端缓存是离用户“最近”的一种存储介质，经常和网络测和服务端缓存一起配合使用，常见的客户端缓存有如下几种：
1）页面缓存：页面缓存是指将静态页面获取页面中的部分元素缓存到本地，以便下次请求不需要重复资源文件，h5很好的支持的离线缓存的功能，具体实现可通过页面指定manifest文件，当浏览器访问一个带有manifest属性的文件时，会先从应用缓存中获取加载页面的资源文件，并通过检查机制处理缓存更新的问题。
2）浏览器缓存：浏览器缓存通常会专门开辟内存空间以存储资源副本，当用户后退或者返回上一步操作时可以通过浏览器缓存快速的获取数据，在HTTP 1.1中通过引入e-tag标签并结合expire、cache-control两个特性能够很好的支持浏览器缓存，关于浏览器缓存更为细节的知识可以查看该文章。
3）APP缓存：APP可以将内容缓存到内存或者本地数据库中，例如在一些开源的图片库中都具备缓存的技术特性，当图片等资源文件从远程服务器获取后会进行缓存，以便下一次不再进行重复请求，并可以减少用户的流量费用。
客户端缓存是前端性能优化的一个重要方向，毕竟客户端是距离“用户”最近的地方，是一个可以充分挖掘优化潜力的地方。
3.3 网络缓存
网络缓存位于客户端以及服务端中间，通过通过代理的方式解决数据请求的响应，降低数据请求的回源率。通常具有如下几种形式的网路缓存：
1）web代理缓存：常见的代理形式分为分为：正向代理、反向代理以及透明代理。web代理缓存通常是指正向代理，会将资源文件和热点数据放在代理服务器上，当新的请求到来时，如果在代理服务器上能获取数据，则不需要重复请求到应用服务器上；
2）边缘缓存：和正向代理一样，反向代理同样可以用于缓存，例如nginx就提供了缓存的功能。进一步，如果这些反向代理服务器能够做到和用户请求来自同一个网络，那么获取资源的速度进一步提升，这类的反向代理服务器可以称之为边缘缓存。常见的边缘缓存就是CDN（Content Delivery Network），可以将图片等静态资源文件放到CDN上。
3.4 服务端缓存
服务端缓存是后端开发中进行性能优化的发力点，常见的后端性能优化也是通过引入缓存来进行解决，常见的有数据库的查询缓存、缓存框架以及引入应用级缓存。
3.4.1 数据库查询缓存
例如，MySQL的缓存机制是通过将SELECT语句以及相应的ResultSet进行缓存，当后续接受到SELECT请求后，如果MySQL已经开启了Query Cache功能，会将SELECT语句以字符串的方式进行hash，然后去从缓存中进行查询，如果查询出数据，则直接进行返回，省去了后续的优化器以及存储引擎IO的操作，能够极大的提升响应时效。如何优化Query Cache需要从如下几个指标上进行考虑：
query_cache_size：设置能够缓存ResultSet的内存区域大小
query_cache_type：表示使用缓存的场景。0表示任何场景下都不使用Query Cache，1表示显式指定不使用Query Cache的查询都可以使用，2（DEMAND）表示只有明确指示使用Query Cache才会生效；
Qcache hits：表示多少次查询命中Query Cache
Qcache inserts：表示多少次没有命中Query Cache而插入数据
Qcahce lowmem prunes：表示多少条Query引入空间不足而被清除
Qcache free memory：表示剩余内存大小
Qcache free blocks：该值很大表示内存碎片很多，需要及时清理
在进行Qcache优化时，可以对以上指标综合进行分析，比如了解Qcache的缓存命中率 = Qcache hits/ Qcache hits + Qcache inserts，来判断当前Qcache的效率。也可以结合Qcahce lowmem prunes、Qcache free memory以及Qcache free blocks来判断当前Qcache的内存使用效率。
另外，如果使用Innodb存储引擎的话，也需要着重关注innodb_buffer_pool_size参数，该参数决定了innodb的索引以及数据是否有足够大的空间放入到缓存中。table_cache决定了能够缓存表的最大数量，也是需要关注的一个参数。
3.4.2 缓存框架
在功能开发时，会常用提供缓存特性的缓存框架或者实现缓存功能的类库来高效的完成开发，常见的缓存框架有Ehcache、Guava等，这些缓存框架配置简单，能够简单灵活的使用。这些开源的缓存框架不仅支持单机的本地缓存还能配置集群的方式达到灵活伸缩。
3.4.3 应用级缓存
当缓存框架不能满足需求的时候，就需要引入应用级缓存，比如Redis、MongoDB等NoSQL数据库，应用级缓存具备高可用性以及伸缩性的分布式架构能够支撑业务需求，当然，做好一款应用级缓存产品其中的挑战也是巨大。
4. When——什么时候需要使用缓存？
缓存不是架构设计的必选项，也不是业务开发中的必要功能点，只有在业务出现性能瓶颈，进行优化性能的时候才需要考虑使用缓存来提升系统性能。也不是所有的业务场景都适合使用缓存，读多写少且数据时效要求越低的场景越适合使用缓存，缓存并不是所有性能问题的灵丹妙药，如果滥用缓存反而会成为毒药，并且会引入维护缓存的操作成本，使得系统复杂度更高不利于维护。
另外把缓存当做存储来使用是一件极其致命的做法，这种错误的认识，将缓存引入系统的那一刻起就意味着已经让系统走上了危险的局面，对缓存的使用边界要有深刻的理解，才能尽可能保证做出引入缓存才是一个正确的决定。
キャッシュ構造の設計を行う際に、考慮すべき多くのポイントがあります。
1）トラフィックとアプリケーションの規模のオーダー：低同時低フローアプリケーションでは、キャッシュの導入とは、パフォーマンスが大幅に向上しませんが、アプリケーションの複雑さ、そして高い運用・保守コストをもたらすでしょう。NOR分散ファイル・システム・キャッシュの代わりに、より適切なを使用して、このような画像や動画ファイルなどのキャッシュされたデータを、使用する必要があります。したがって、キャッシュの導入前に、あなたはビジネスシナリオの高並流の大きなキャッシュの導入は比較的業績が高くなり、トラフィックの電流の流れを評価する必要があります。
2）キャッシュ・アプリケーションを選択します。キャッシュなどのRedis、memcachedのとTAIR、などのアプリケーションと同様に、各アプリケーションの分散キャッシュメモリ効率の長所と短所の余地がたくさんあり、運用・保守コスト、さらには知識構造チームの開発者が必要とされています優れた技術選択のためには、理解します。
キャッシュの導入前に、あなたは評価値のサイズ、キャッシュメモリ、ピークQPS、有効期限、キャッシュヒット率、読み取りと書き込みの更新ポリシー、ポリシーをルーティング一貫性のキー値の分布、有効期限ポリシー、およびデータに焦点を当てる必要があります：3）適切にキャッシュする要因の影響を評価プログラム、および多くの要因が認識されるように上のよう。
4）高可用性キャッシュ・アーキテクチャ：分散システムであり、高可用性のための分散キャッシュ、三の高い指標の追求などのキャッシュ・クラスタ・デザイン、マスタ - スレーブ同期方式の設計、機能するだけキャッシュ信頼性が十分ビジネスに価値をもたらすビジネスシステム、;
5）モニタリングプラットフォームを向上：本番環境へのキャッシュは、以前の問題を特定するために、明示的なキャッシングシステムの動作を観察することのできる監視システムを持っている必要があります場合は、しばらくホットデータの予想外の不足、必要性の見通しホットデータキャッシュの問題を解決するためのホット予期せぬ発見システム。
6）キャッシュ最近の原則：最寄りの場所のユーザーの核となるアイデアにキャッシュされたデータは、間違いなく大幅にマルチレベルキャッシュ設計で応答速度を高めるません。
オリジナルリリースタイム：2019年11月25日
投稿者：アリの技術
Yunqiコミュニティパートナーからの記事、「アリ・テクノロジー」情報については、「アリの技術を。」に関することができます