序文
昨夜は、2つまたは3つ、朝の7つ以上の火災は、目を覚ます目を覚ますと、オープンSQLかつ迅速に最後の夜に実行したコマンドの結果を確認するために立ち上がって、まだ薄暗いコンピュータを検索します。アリクラウドRDSをアップグレードするための最後の夜は、まだアップグレードプロセス中に異常な反応があるアリ雲、午前中に2時間近くの降格を待っているので、そのプロセスを強化しています。。。ビット退屈
プロジェクト
このプロジェクトは、WEB、WEB-マネージャー、WEB-API、APP（アンドロイド、IOS）に分割されています。
メインの開発言語は、ASP.NETです
MySQLデータベース
アーキテクチャは、DDDを使用してASP.NET + EF + ORMユニティ依存性注入の練習の一部を使用しています
AutoMapperを使用してORM
使用Redisのキャッシュ
log4netのレコードログファイルは、単に、MongoDBのロギングを使用して開始した後にキャンセルいくつかの時間を費やしました。
WEBの最終用途angularjs
ユーザ状態access_tokenはによって送信されたAPPと相互作用することによってAPIレイヤJSONデータ、
現在、データベース層は、ストレージ（Repositor）モードを達成するために基づいています
検索するLINQの+ラムダの方法を採用するのが最も熱心ライン上の最初の項目では、練習の過程で要求に再編異常ビジネスと迅速な対応を見つけ、Context.DataBase.SqlQueryで実行されるネイティブSQLへのクエリの複雑さ、
他の技術が導入されていません
APPの大量への現在のアクセスそのため、最大同時1300 +
主圧力APIは、50の以上のインターフェイス現在Windwosサーバー2012展開日平均100W +要求、API比較的大きいです
スタンドアローンのデータベースをMySQLのRDSに雲アリの5.6バージョン、10箱12G、接続2000の番号を使用して、6000 IOPS
現在、最大の単一のテーブルには、8000W +データです。物理ファイル300G、APIlogは毎日、APIおよびビジネスシステムがDBLOGに加えて、完全に独立した100W +であっLog4g.netファイル生成されたログを記録します。
アリは現在、クラウド・ロードで使用され、マスタースレーブアリクラウドは、2つの負荷アプリケーションを購入したCDN 10Mの帯域幅およびリソースファイルの8ボックス16G、です。
WEBは、APIのみを上から、メイン端末とWEB管理の背景の上に展開します。
データベースのボトルネックケース
最近のユーザーはエラーの多くは、SQLの実装にコマンドをリードする、時々アップ臨界点の100％に、CPUの高前夜の先頭から10以上の+、1300 +最大同時データベースを超え、リンクは拒否しました。アリ雲のアラームメッセージが巻き起こっていたアプリケーションは、MySQLデータベースが通常のデータベースバック後の約5分後、回復することは困難で停止してから、IISのアプリケーションを開いていないので、私はすぐに、IISアプリケーションを停止しました。卵の痛みはアリ雲のヘルスチェックもその異常な負荷を示唆して、少しはそのショーの異常な健康状態を困惑、要求がまだ配布していき、非常に困惑しています。私はすぐに、アプリケーションプールのリサイクルをIIS停止し、IISアプリケーションプールを再起動するよう指示を送信するために、ここで再起動し、IISアプリケーションオフ停止に最高の時間で、その後、IISのアプリケーションプールを再起動します、ケースはそれ以外シェレメチェボです起動難しさ。適切に荷重表示上のヘルスチェックは、数分後。
、アリ雲は、様々なモニタリング指標を読んだ後、ショーは、私はそれが不快だと思った、一時間の突然のサージに流動し始めたが、トラックは、いくつかの接続要求を見つけ正常にされていますが、守備のアシスタントディスプレイ360は、いくつかの攻撃を持っています攻撃の数があまりありませんが、いくつかの種類の内容とパラメータに関する主な攻撃：それは、データベース間でいくつかの要求を引くには十分ではない、それはおそらく、リクエストの数十、いくつかの簡単なXSS攻撃はでここに掲載しました
URL / 'は、％22 /％3E％3C /スクリプト％3E％3Cscript％3Ealert（）％の3C /スクリプト％3E
URL /'は、％22 +のonmouseover =警告（）+ D = 'は、％22
URL / matrix_callback.php
URL / index.phpのオプション= com_fields＆＃038;？ビュー=フィールド＆＃038;レイアウト=モーダル＆＃038;リスト％5Bfullordering％5D = UPDATEXML（0x3a、CONCAT（1、MD5（233））、1）
その後数回は、アクティブおよび非アクティブな接続の数が通常よりもはるかに高いことが接続されている、100％に達し、CPU、データベースの危機であることが判明。私たちは完成の0.03秒以内にSQLクエリクラスの要件を開発するために必要とされるとき、現在の超8000W、300Wを超えるデータのテーブルを持つ最大のデータベースはまた、より多くのダースよりも、通常は、データベースクエリの崩壊を引き起こしました。しかし、これは、我々はリターンの0.5秒以内に設定し、いくつかの大きなテーブルのクエリを必要とします。今日は間違いなく0.5秒以上をチェックされ、
私は今も少しシステムが正常に動作し、彼らはそれらの遅いSQLの最適化の1を取った、遅いSQLアリクラウドコンソールでログを確認し、すぐにSQLコードを書き換えることではないバージョンを、作ることができない、唯一のインデックスから最適化することができ、 。何度も繰り返し、実行20 2秒以上程度ありますが、最も遅いが10秒に達し遅いSQLの一つ一つがそう、解決の最大行数は、より10Wラインよりも達し、ちょっと以下の兄弟が緩んSQL記述する必要がありますそれ以外の場合は、超10W +の数は、行を解析、しかし兄弟掘ったピットは、私が泣い埋める行く必要はありません。だから、テーブルスペースの採用はかつて最適化されています前に、何度も何度も一つの方法のいずれかでインデックスを調整することについて説明します。
昨夜は高い同時実行、データベースに行って、警察を呼ぶが、幸い私はアラームをオフにクラッシュ与えませんでした。そこに顧客とのコミュニケーション、データベース拡張することを決めました。今16 14000 iops16000接続に拡張カセット64G。
2からのマスターである今、いくつかのアプリケーションを追加します。
これは、いくつかの時間のために維持すべきです
あなたが別の読み取りと書き込みに進める必要がある次に、大規模なテーブルとデータベースのための分割は、コードを最適化していきます。最善を尽くしてみてください。
そしてかもしれケースをマーケティングに基づいているため、分散型アーキテクチャの進化の下に進んで、我々は戻って行くことはできませんが、あまりにも前に市場に来ることができません
週末は最悪延期比較的短い時間で書かれていました