今天忽然想到一个问题
对于高并发条件下，后台对数据的更新和实例化是怎么进行的？
1、直接插入数据库，然后更新缓存？
这样这个更新操作将会有IO阻塞风险吧、
2、直接更新缓存，然后使用消息队列更新数据库？
只能延缓IO阻塞，并不能避免
3、直接更新缓存，定时批量更新数据库
这样IO的问题是解决了，但是数据在缓存里感觉很慌。
也没实践过真正的高并发系统，这种情况怎么解决？
----------补充----------
总结一下
就是已知直接插入和更新数据库将面临IO阻塞的风险，那么将数据最终实例化到数据库的过程是怎么样的。
天蓬老师2017-04-18 10:25:14
中間プール、キャッシュ、Redis、それが意味するところです。
プールがブロックされている場合、これは、どんなに大きくても、チェリーの小さな口を持つ痩せた男性のようなものです。ボウルは、小さな桜の口を持つ痩せた男を10人見つけるか、口を開けた大きな太った男を見つけます
更新:
リーリー
高洛峰2017-04-18 10:25:14
最初にキャッシュに書き込み、次にディスクに永続化します。作成者は、キャッシュ サーバーがハングアップしてデータが失われることを心配していますか?
一般的な運用環境では、アプリケーション サーバー、データベース サーバー、キャッシュ サーバーのいずれであっても、スタンドアロン サーバーではありませんし、少なくとも、一方のサーバーに障害が発生すると、もう一方のサーバーがマスター/スレーブ構造になります。負荷が正常な場合、この場合、同時に 2 台のマシンがダウンすることはもちろん、1 台のマシンがダウンする可能性もそれほど高くありません。Redis はクラスターとして使用できるため、導入は正常であるため、この問題が発生する可能性は非常に低いです。
投稿者は行ってもっと詳しく知ることができますCAP理论，根据你的描述你想要达到的效果和CAP 説明は似ていますが、完全に完璧な解決策はありません。
巴扎黑2017-04-18 10:25:14
お誘いありがとうございますが、私にはこの問題に対処した経験がないので、理論的にしか話せません
まず、キャッシュの追加は避けられませんが、キャッシュディレクトリは処理できないものを一時的に保存し、待ち時間を長くするためのものです。たとえば、突然 10 分間の同時実行率が高くなった場合、対処する必要がある問題が蓄積されますが、10 分間のコンテンツは 30 分で処理できます。もちろん、ここには前提があります。つまり、10 分間の同時実行性が高くても、対処する必要のある問題はそれほど多くないということです。
そこで問題は、その後の流入速度が依然として非常に速く、まったく処理できない場合はどうなるかということです。最近バックプレッシャーという言葉を学びました。バックプレッシャーに対処する最も直接的な方法は、コンテンツの一部を破棄することです。もちろん、データは絶対に捨てたくないので、処理効率の観点からしか方法を考えることができないので、拡張、クラスタリング、オフロードなどの同時処理技術を多用しましょう
上記は口語的な言葉を使用した個人的な理解であり、十分に専門的ではないため、参考としてのみ
ringa_lee2017-04-18 10:25:14
これは大きな問題であり、さまざまなシナリオで高い同時実行性を実現するさまざまな解決策があります。
例えば、Weibo は同時性が高く、金融システムも同時性が高く、前者は情報が失われても問題ありませんが、後者は情報の永続性が厳格に要求されます。
また、これは高同時読み取りですか、それとも高同時書き込みですか?
それは、一定期間内の高い同時実行性ですか、それとも持続的な高い同時実行性ですか?
前提条件が示されていない場合、どうやって答えることができますか?
PHPz2017-04-18 10:25:14
これは実に良い質問です。
読み取り操作の場合は、問題はありません。現在の主流のデータベースのほとんどは、データベースで高度な操作をすでに実行できるため、ほとんどの現在のデータベースでは、データは書き込み時に更新されます (コピーオンライト)。同時実行性は同時読み取りをサポートします。重要なのは、書き込み操作のデータの一貫性を確保し、データが更新されたときにキャッシュも更新されるようにする方法です。これはデータベースの ACID 理論によって保証されます。
書き込み操作の場合、現在のインターネット データベースの ACID は、従来の一貫性ではなく、データの最終的な一貫性を意味します。これにより、ユーザーのリクエストに迅速に応答できるようになります。この記事は CAP の紹介です、http://blog.csdn.net/starxu85... 参考までに
あなたの質問は、実際には「ダブルイレブン」フラッシュセールに対応しています。幸いなことに、一部のデータベースには、このシナリオ向けにパフォーマンスが最適化されています (フラッシュ セールス用に最適化された MySQL ベースの新しいオープンソース AliSQL など)。これらのリクエストは、データベースのキャッシュにメッセージをキューに入れてから、一度更新することで高い同時実行性を確保できます。もちろん、高低水位、スレッドプールなど、中間には他の理論的サポートもあります。
上記は私の謙虚な意見です。私はプロの DBA ではありません。理論上の誤りがある場合は、自由に追加してください。
伊谢尔伦2017-04-18 10:25:14
ポスターのこの問題はほとんどのアプリケーションで一般的であり、システムの同時実行性が高いかどうかとはあまり関係がありません。私も以前に同様の問題について考えたことがあります。
キャッシュについて簡単に説明します (2)
まず最初に、について話しましょう。私たちのプログラムは、ほとんどの場合、キャッシュに「弱い依存性」があるはずです。この「弱い依存性」をどう理解すればよいでしょうか? ほとんどの場合、プログラムのデータの正確性は、たとえば、「商品詳細ページの商品の価格」は実際にはキャッシュ内のデータですが、注文生成時の合計金額はデータベースで確認する必要があります。もちろん、私が話しているのはほとんどの場合ですが、データの正確性がそれほど厳密ではないケースもいくつかあります（たとえば、抽象化、残念賞の数を事前にキャッシュにロードでき、その後のビジネスニーズ）一般的なビジネスによれば、残念賞は、100 個以上の購入で 5 元の割引など、販売者にとって有益な追加特典であるため、キャッシュ内の賞品の数から直接計算できます。この時点でキャッシュが失敗したとしても、再度更新しても販売者にはほとんど影響がありません)
redisそのため、一般的な状況では、通常、データベースのデータが正しいことを確認した後、キャッシュを同期/無効化/非同期で更新します
