最近の収穫の仕上げ作業、メモを行います

1は、Redisの、プロジェクトに、プロジェクトは大規模なアプリケーションに失敗したため、クロスサーバセッションの使用など、現在の状況について、綿密な研究は、シンプルにすることなく、簡単なアプリケーションを構築するには、あまりにも古い事業費とコードの変換を必要とします高いです。

2は、MQTTは、メッセージのサブスクリプションとパブリッシングメカニズムMQTTに基づいて、だけでなく、プロジェクトの実用化では、非常に興味深いアイデアです。

3、nginxのは、需要がHaProxyの生と死を行うことはできません使用して、同じポートを使用して、同じサーバー用WebSocketとhttpsを必要とし、そこにある、TCPプロトコル4を使用した場合、HTTPSを使用していない、てバックエンドに顧客の実際のIPアドレスを渡すことはできません自動識別し、HTTPSメカニズムnginxの、完璧な実現を使用します。

4は、再設計プレリリースファイルシステム監視は、SQLスクリプトは、バッチ実行マルチサーバは、マルチサーバロードバランシングのコードは、キーのリリースであり、6ヶ月の時間で、繰り返し検証は、基本的には、完璧な欠陥のないされている、何BUG、長い時間のために残っていません安定した動作。

5、LINQ、EF枠のさらなる理解、より深く理解します。

6、SQL、ストアドプロシージャは、より多くの倒錯シーンが、より複雑な、自分自身では不十分の補足と考えることができ、過去に比べてアプリケーションを書いて、

悪いがある7、異なる人々、システムの設計思想によって書かれたコードの知識、の利点があります。

既存のネットワークインフラシステムのための理由による8、過去6ヶ月間は、主に書かれたストアドプロシージャに基づいていますが、およそ半年システムが約50%を理解する非常に大規模で複雑なビジネスシステムは、そこにある。しかし、過去6ヶ月間は、しばしば直面したとき、多数のサブ最適化されたストアドプロシージャ、クエリとコードの最適化は、いくつかの経験を要約した後、少し説明を行い、ノート、

    :多くのオーバー読むために読み込みの数を見つけるために使用されるSQL Serverのトラックマネージャー、(通常はインデックスを取らないが、テーブルスキャンでメッセージを通して見ることができる)、またはX秒以上のストアドプロシージャの実行時間をデュ、見つけるために使用しますSQLクエリ解析のための解析、および補足インデックスを見つけます。

    B:既存のインデックスと互換性のあるケースを考える、既存のインデックスを最適化する新しいインデックスを優先する。

    C:シーンの複数列索引索引順次クエリは、それがスキャン数の減少を反映し、または読み出しが、実際に時々非常に大幅クエリの速度を向上させることができることはできないものの、降順インデックス列を昇順、指数を取るかどうかを決定する前と後に、

    D:クエリ方法は、無理を修正例えば、同様の手順で記憶され、時間がかかり、繰り返しクエリの結果、1に低減。

    E:一つのケースで使用コード無理サイクル、サイクルのNo. 30へクエリデータ番号1は、ストアドプロシージャを30回呼び出し、約60秒の実装;直接範囲1-30を照会するように変更、一度クエリ結果は、すべてのターゲットを取得し、その後、データは、プログラムコード内で処理され、パケットは、5秒に短縮されます。

    F:以前少し使用SQL:選択* #TEMPの中へと...;更新のtable_1セットX = 1つの出力Insert.IDの中へ#TEMP;ようにして、次の学習していきます。

    G:以前のプロジェクトではめったに、めったにマルチテーブル共同問い合わせのシーンを使用しない、ビジネス、デザインのテーブルは、基本的にすべての既存のシステム、このような構造に関連している。実際に共同問い合わせのクエリを削減、効果的に大幅に減らすことができますクエリ時間がかかるが、ビジネス設計は基本的なアーキテクチャもないように設計されて、あまりにも複雑であり、多くの場合、クロスデータベースを含む非常に多くのサブライブラリーは、クロスデータベーストランザクションを行うことが面倒です。

仕事はより科学的にしたい;異なる課題に直面しているだけでなく、空気中のこの問題を、プラス既存のシステムやサービスの複雑さ、徐々に整理、このシナリオでは、自分の人生経験を借りることができますことを期待して9、Redmineのプロジェクトのスケジュールを管理使用する学習を開始。常に難しく、もっと練習、より多くの反射の解決策を考えて、さまざまな困難に直面しています。

その他のその後の補充。

 

少しいつもの思考を仕上げ、そして物事を練習する機会を持つように願っています:

1、分散型ゲートウェイの独自のセットをしたい、と参照チェック、署名検証、サービス間のコールのサポート、コールの適用、外部サービスを呼び出すに、APIドキュメントが付属しています。分散バックエンドサービスコードのサポート、実行するプログラム自動ロードホット更新、下.NETコアに基づく優先開発ゲートウェイシステム。

2、トリムや再学習マイクロサービスアーキテクチャ。

ライブMQTTとの良好なのRedisと3、、、またはシステムをサブスクライブ、パブリッシュのWebSocketをもとに、独自のセットを開発、ほとんどのシナリオでは、あなたの代わりにTCPののWebSocketを使用することができます。

4は、既存のシステムの複雑な思考の枠組みは、条件が許せ下、徐々に無限にスケーラブルな分散システムでは、私はそこの機会であるか、またはその方向に行くために、右のインスピレーションを有することができると信じて様々なプログラムに変換します。主にコードの量、ストアドプロシージャの数、テーブルの数、および最後のテーブル設計不合理な、複雑なビジネスが、歴史問題、解決することは困難であるものの、または絶えず方法を考える必要があります。

その他、それを書くことを考えました。

おすすめ

転載: www.cnblogs.com/soleds/p/11391825.html