このような高可用性は、私は要りません!
先日、友人の会社で、大きなトラブルがありました.障害の原因も説明しやすい.ActiveMQの高可用性レベル(M-Sアーキテクチャ、デュアルライトACK)を使用したため、ピーク時には本番側のメッセージが渋滞し、多くのリクエストが着地できず、データが錯乱した.
背景
彼によると、彼らのアプリケーションは、電気通信アプリケーションよりもレベルが高い(牛皮は必ず吹く)ので、メッセージシステムはメッセージを失うことができないことを要求している.彼はやったが、サービスは使えない.
このCaseはどこから来たのでしょうか.ある役員会議で、ある指導者はその中の小さな問題に興奮したということです.彼は環境テストのデータをテストして、直接なくなって、生産環境は再現されていません.矛先は最終的にメッセージシステムを指して、直接断電した後にどうすればいいのかということです.
リーダーが威張って、特別なことをしなければならない.アーキテクチャグループがいたずらをするように夜更かしして改善案を討論した.KafkaからRocketMQまで、落盤DBからStoreHA案まで、楽しくない.最終的な討論結果は、極めて高い利用可能な方式を採用することである.リーダーの条件が満たされ、メッセージシステムも高い利用可能性があるが、業務全体はそうではない.最終的なMQスループットは、DBさえもあるに及ばない.
典型的な銃棒需要による最適化故障.珍しくないに違いない.
考える
高可用性は偽命題であり、CAPなどよく知られている理論サポートがあるが、技術決定者を含む多くの人がこの誤解に陥っている.アーキテクチャはグローバル制御者として、このような誤りが現れることができて、純粋に低級である.以下、私自身が高可用性に対する考えである.
高可用性はコンポーネント高可用性ではなく、ビジネス高可用性です.
メッセージ・キューとしては、メッセージ・キューの生存とメッセージの信頼性を保証するという意味ではなく、作業が完了します.また、本番側と消費側のトポロジーと高可用性も考慮する必要があります.たとえば、本番側の異常閉鎖、バッファの処理、低スループット環境でのメッセージの過剰処理、消費側のメッセージの蓄積、およびデッド・メッセージ処理などです.
もしあなたが事前に業務に対して容量分析を行っていなければ、相応の拡張手段もなく、問題が発生しやすい一環を監視していなければ、鍋はあなたのもので、走ることはできません.
業務はまず使えるが,それから信頼できる
業務はすべて走ることができなくて、あなたのサービス側のコンポーネントはどんなに信頼性があっても、廃棄物です.秒殺システムを持って、あなたはそれが先に信頼性のある着地を要求することはなくて、かえっていくつかの信頼性のあるキャッシュシステムで緩衝することができて、このいわゆる利用可能です.業務の正常な流れを保証してこそ、信頼性を話すことができます.
主なプロセスは遮断できず、信頼性が低下
これがよく言われるような溶断です.例えば、レジシステムでは、バックグラウンドで本当にいろいろな記帳ロジックを処理してから成功に戻るのを待つことはありません.その主な目的は入金です.まずお金を使ってからにしましょう.メッセージの送信に失敗したからといって、支払いを要求しても失敗してはいけません.このとき、メッセージはバイパスアプリケーションとして存在し、設定しなければなりません.合理的なタイムアウトは、溶断に至る.
例えば、事務に置かれている時間のかかる操作は、命がけの遊び方です.
遊んではいけないなら流れを制限しなさい,無理に支えてはいけない.
ストリーム制限とは、ユーザーが最外層でブロックされ、要求が入らないようにすることである.ユーザーは失敗した要求を見ることができるが、危害的な要求(論理的に交錯して実行されるデータの乱れ)は生じない.耐えられないなら認めたほうがいい.要求はバックグラウンドに導かれ、ある基礎コンポーネントを殺し、さらに深刻である.
データをなくしてはいけません.私はまだ戻ってきます.
分布式システムの話が最も多いのは最終的な一致性であるが、誰も知らない.最終的な一致性には人工的な一環、甚だしきに至っては顧客サービスの介入が含まれている.一般的に、異常データを発生する確率はまだ比較的に小さく、人工的に処理することができる.また、他の最適化手段がある.
1、フォーマットされた詳しいログ、ログによって回復できる
2、べき乗などの業務、at least onceの意味を保証することを要求する
3、スキャン、再試行などの手段により、異常データ処理を行う
高可用性を口にしないでください.それはとてもsbです.
高い話をするのはすごいですか.そうではありません.
分散システムは複雑な全体であり、要約しないでください.あるコンポーネントを完成したのは本当のシステムを完成したのと同じではありません.リーダーはそうは思いません.あなたはできません.
End
いくつかの反例はいつも有益な思考を引き起こすことができます.身の回りの需要を分析して、どれが銃の棒の需要で、どれが受話器の需要で、すべて言わないことができて、自分の専門の認知を堅持します!もしあなたがどのように言うことを知らないならば、この文章を彼に渡して、彼に結果を見せることができます.
背景
彼によると、彼らのアプリケーションは、電気通信アプリケーションよりもレベルが高い(牛皮は必ず吹く)ので、メッセージシステムはメッセージを失うことができないことを要求している.彼はやったが、サービスは使えない.
このCaseはどこから来たのでしょうか.ある役員会議で、ある指導者はその中の小さな問題に興奮したということです.彼は環境テストのデータをテストして、直接なくなって、生産環境は再現されていません.矛先は最終的にメッセージシステムを指して、直接断電した後にどうすればいいのかということです.
リーダーが威張って、特別なことをしなければならない.アーキテクチャグループがいたずらをするように夜更かしして改善案を討論した.KafkaからRocketMQまで、落盤DBからStoreHA案まで、楽しくない.最終的な討論結果は、極めて高い利用可能な方式を採用することである.リーダーの条件が満たされ、メッセージシステムも高い利用可能性があるが、業務全体はそうではない.最終的なMQスループットは、DBさえもあるに及ばない.
典型的な銃棒需要による最適化故障.珍しくないに違いない.
考える
高可用性は偽命題であり、CAPなどよく知られている理論サポートがあるが、技術決定者を含む多くの人がこの誤解に陥っている.アーキテクチャはグローバル制御者として、このような誤りが現れることができて、純粋に低級である.以下、私自身が高可用性に対する考えである.
高可用性はコンポーネント高可用性ではなく、ビジネス高可用性です.
メッセージ・キューとしては、メッセージ・キューの生存とメッセージの信頼性を保証するという意味ではなく、作業が完了します.また、本番側と消費側のトポロジーと高可用性も考慮する必要があります.たとえば、本番側の異常閉鎖、バッファの処理、低スループット環境でのメッセージの過剰処理、消費側のメッセージの蓄積、およびデッド・メッセージ処理などです.
もしあなたが事前に業務に対して容量分析を行っていなければ、相応の拡張手段もなく、問題が発生しやすい一環を監視していなければ、鍋はあなたのもので、走ることはできません.
業務はまず使えるが,それから信頼できる
業務はすべて走ることができなくて、あなたのサービス側のコンポーネントはどんなに信頼性があっても、廃棄物です.秒殺システムを持って、あなたはそれが先に信頼性のある着地を要求することはなくて、かえっていくつかの信頼性のあるキャッシュシステムで緩衝することができて、このいわゆる利用可能です.業務の正常な流れを保証してこそ、信頼性を話すことができます.
主なプロセスは遮断できず、信頼性が低下
これがよく言われるような溶断です.例えば、レジシステムでは、バックグラウンドで本当にいろいろな記帳ロジックを処理してから成功に戻るのを待つことはありません.その主な目的は入金です.まずお金を使ってからにしましょう.メッセージの送信に失敗したからといって、支払いを要求しても失敗してはいけません.このとき、メッセージはバイパスアプリケーションとして存在し、設定しなければなりません.合理的なタイムアウトは、溶断に至る.
例えば、事務に置かれている時間のかかる操作は、命がけの遊び方です.
遊んではいけないなら流れを制限しなさい,無理に支えてはいけない.
ストリーム制限とは、ユーザーが最外層でブロックされ、要求が入らないようにすることである.ユーザーは失敗した要求を見ることができるが、危害的な要求(論理的に交錯して実行されるデータの乱れ)は生じない.耐えられないなら認めたほうがいい.要求はバックグラウンドに導かれ、ある基礎コンポーネントを殺し、さらに深刻である.
データをなくしてはいけません.私はまだ戻ってきます.
分布式システムの話が最も多いのは最終的な一致性であるが、誰も知らない.最終的な一致性には人工的な一環、甚だしきに至っては顧客サービスの介入が含まれている.一般的に、異常データを発生する確率はまだ比較的に小さく、人工的に処理することができる.また、他の最適化手段がある.
1、フォーマットされた詳しいログ、ログによって回復できる
2、べき乗などの業務、at least onceの意味を保証することを要求する
3、スキャン、再試行などの手段により、異常データ処理を行う
高可用性を口にしないでください.それはとてもsbです.
高い話をするのはすごいですか.そうではありません.
の品性と認知能力を分析し、さまざまな技術手段の結果を分析することができます.誰の権利が大きいのか、誰の観点が正しいのかではありません.多くの指導者が素晴らしいことを振って、頭の中で2/3を忘れてしまったので、本質的な問題ではありません.分散システムは複雑な全体であり、要約しないでください.あるコンポーネントを完成したのは本当のシステムを完成したのと同じではありません.リーダーはそうは思いません.あなたはできません.
End
いくつかの反例はいつも有益な思考を引き起こすことができます.身の回りの需要を分析して、どれが銃の棒の需要で、どれが受話器の需要で、すべて言わないことができて、自分の専門の認知を堅持します!もしあなたがどのように言うことを知らないならば、この文章を彼に渡して、彼に結果を見せることができます.