クレジット:pikisuperstarによって作成されたテクノロジーベクター— www.freepik.com

開発者として、私たちは何かを構築しようとしている狀況に自分自身を見つけることがよくありますが、私たちが望む方法で開発するための十分な時間がありません。また、「市場投入までの時間」が製品の成功に重要な役割を果たす場合があるため、タイムラインを常に遅らせることはできません。どうしようか?私たちは手抜きをし、計算されたリスクを取り、あなたの中の純粋主義者を手放します(ベストプラクティス、ユニットテストカバレッジ、そして何とか何とか)。ほとんどの人にとっても、それはひどく似ていると思います。

今日の話は、私たちが構築されたかについてであるハイスケールフォールトトレラント分散3人のチームで、約1週間の時間に、リーダーボード/スコアリングシステムを。

このブログでは、主にこれらの學習のバケツがあります

  1. 技術:このようなシステムを実際にどのように構築しますか。分散システムの設計、スケーラビリティ、復元力、可用性などのトピックについて説明します。
  2. 時間との戦い:短期間でどのように成果を上げるか、どのようなトレードオフを行うか、どのように意思決定を迅速化するか。
  3. 開発ライフサイクル:製品開発ライフサイクル、つまり優れたソフトウェアを構築するためにどのようなことが行われるかについても詳しく説明します。

第1章:要件

それはすべて、製品チームがT20ワールドカップシーズンであり、短期的な予測のためにユーザー向けのクイズシステムを構築したいと言ったときに始まりました。

ユースケースは、オーバーユーザーの開始時に、20/30秒のシナリオを予測するように求められるというものでした。そして、オーバーモデレーターの最後に、予測されたすべてのシナリオの中で実際に何が起こったのかを提出します。そして、スコアリングは、誰が正しく答えたか、そして答えるのにどれくらいの時間がかかったかに基づいて機能します。

そのため、要件を取得した直後に、労力の見積もりを行いましたが、それは明らかに予算に合わなかったため、v0でスキップできる機能を削減しました。締め切りが厳しい場合は、中途半端な機能を提供するよりも少ない機能を提供したい場合があるため、これは重要です。

これは主にバックエンドに焦點を當てたブログになります。申し訳ありませんが、これらの美しいUIがどのように作成されたかを説明することはできません。

第2章:デザイン

次は明らかに、高レベル設計として一般に知られているシステムを設計することでした。これは私にとって最も挑戦的な部分であり、最も楽しい部分でした。大規模な低レベルの設計は行わず、実裝中にすべてのモデリング呼び出しをその場で行いました。

ステップ1:スケール推定

何かを始める前に、どのような種類のトラフィックが私たちを襲うかについて大まかな見積もりをしました。私たちのシステムの規模を考えると、おそらく5萬人がクイズに參加すると推定されました。そのため、10人のユーザー向けにビルドすることを目標としました。しかし、ほとんどの人はおそらく最初の10秒で30秒のウィンドウで答えるでしょう。これにより、およそ20kの目標qpsが得られます。

私の大まかなルールは、新しいシステムでは、常に予想されるユーザーの2倍の數のシステムを設計することです。そのため、最終的にユーザー數が増えた場合でも、システムの拡張に失敗することはありません。また、ユーザーは一般的に時間の経過とともに成長するため、システムを絶えず変更し続ける必要はありません。しかし、それは、実際に必要なインフラストラクチャの2倍の場所にインフラストラクチャを配置することを意味するものではありません。ほとんどの場合、システムで自動スケーリングを有効にしているため、トラフィックが急増すると、システムは自動的にスケーリングします。

(キャッシュ上のストレージについても他の見積もりを行いましたが、記事を短くするためにそれらをスキップしました)

ステップ2:大規模なAPIを特定する

スケール後の見積もりでは、ハイスケールAPIとは何か、およびそれらのスケーラブルな設計を選択的に実行できるように処理が高くなる可能性がある場所をすばやく特定しました。私たちが気にしなかった、または多くの時間を費やしなかった殘りの小規模API。

つまり、これらは私たちが特定した大規模なAPIです

  1. ユーザーのスコアとランクを取得する
  2. リーダーボードを取得する
  3. リーダーボードを計算します(主にAPIではなくデータ処理)
  4. ユーザーの回答を投稿する

ステップ3:設計上の考慮事項

要件を見た直後、2つのことが私には非常に明白でした。

  1. 私たちは、必要としている非同期および分散処理の最も明白な理由のためにスコアとリーダーボード計算のために。100萬人以上のユーザーの単一ノードでスコア計算を同期的に実行することを計畫している場合は、幸運を祈ります??。アイデアは単純です。大きなタスクを小さなタスクに分割し、それらを異なるノードで実行し、自分のペースでこれを実行できるようにします。また、このプロセスをフォールトトレラントにする必要があります。
  2. キャッシュは、ユーザーとリーダーボードのランクを読み取るための私たちの友達になります。主に2つの理由から、スケーリングの速度容易さ。キャッシュは、単純な読み取り操作ではDBよりもはるかに高速であり、一般に、PostgresよりもRedis / Memcached / Hazelcastクラスターのスケーリングが簡単です。

ステップ4:システムを設計する

今回は設計上の決定を下している間、私は自分が知っている技術を選択し、このユースケースに最適な技術を見つけることに挑戦したくありませんでした。たとえば、私はRedisに精通していたので、キャッシュの場合は當然の選択でした。また、リーダーボードを聞くと、自動的にRedisでソートされたセットに変換されます。そして、非同期処理に関しては、Kafkaは依然として私の一番の選択です。適切な時間が與えられれば、私はおそらくもう少し探索をするでしょうが、今回は時間がなかったので、最高の技術を見つけるために荒野に迷い込むつもりはありませんでした!!!!

NS。ユーザー回答APIを投稿する

したがって、このAPIを使用すると、ユーザーはクイズの回答を送信できます。ここでの主な課題は、これにより多數の同時書き込み操作が生成され、データベースの負荷が大幅に増加することでした。だから私たちは2つのことをしなければなりませんでした

  1. DBの負荷を減らす
  2. DBが圧倒されないように、ある種のバックプレッシャーを生成するか、DBオペレーターが自分のペースで作業できるようにします。

書き込み負荷を減らすための私のgotoソリューションは、バッチ処理を行うことです。したがって、10回の書き込み操作を実行する必要がある場合は、それらをバッチ処理して1つのクエリを取得してから、1回のDB書き込み操作を実行します。

そして、バックプレッシャーはほとんどメッセージキューを叫びます

したがって、両方を組み合わせて、私たちが思いついた解決策はこれです…

びっくりしないで、何が起こっているのか説明させてください

  1. ユーザー応答は応答受信者によって受信され、202HTTPステータスコードが返されます。これは、私があなたの要求を受け取り、それを処理するつもりだと言っているようなものですが、あなたは先に進んで、あなたがしていたことをします。これは非同期処理の最初のステップであり、呼び出し元をブロックません
  2. 応答レシーバーは、ユーザー応答をメッセージキューに入れます。メッセージキューは、スケーラビリティ/可用性/冗長性の目的で再び分割されます。Kafkaをすでに知っている場合は、パーティショニングを非常に簡単に理解できます。そうでない場合は、キュー內のメッセージを、技術的には異なるノードに存在できる複數の小さな分離されたキューに分散する方法と考えてください。DBシャーディングを知っている場合、それは同じことですが、ほとんどがメッセージキュー用です。カフカについて詳しくは、こちらをご覧ください。
  3. 現在、これらの生の応答はバッチャーによって受信されます。次に、10個のメッセージのバッチを作成し、それらを次の処理段階にプッシュします。
  4. DBライターはバッチを取得し、DBに挿入クエリを実行します。背圧は主にDBライターによって導入され、メッセージコンシューマーはプルベースであったため、獨自のペースでメッセージを取得します。したがって、DBの過負荷を防ぎます。また、100個のDBクエリを実行する代わりにバッチで動作しているため、10個のDBクエリのみを実行しました。

これで問題の30%が解決しました。次の問題に進みましょう。

NS。スコアとリーダーボードの計算

今、部屋の中の象、主要な問題、リーダーボードの計算。このシステムを見ると、正解を事前に知っている従來のクイズシステムとは異なります。したがって、誰かが答えるとすぐにスコアとリーダーボードを実際に計算することはできません。モデレーターが正解を送信したら、すべてのユーザーのスコアとランクを計算する必要があります。つまり、大量の作業を一度に行うことができます。私たちのノードもDBサーバーも同期でそれを適切に処理できないことはかなり明白ですファッション。どうしようか?非同期処理のために、友人のメッセージキューに戻ります。スコアを非同期で計算できるのでかっこいいですが、リーダーボードはどうですか?それは常に利用可能である必要がありますか?そして、ランクはどうですか?すべてのユーザーのスコアが計算されるまで、そしてそうでない限り、実際にランクを付けることはできませんよね?そして、ランクを具體的に計算することは難しい問題になる可能性があります。

さて、誰がこれから私たちを救うのでしょうか?友達のことは心配しないでください。キャッシュについて話しているときにRedisについて簡単に觸れたことを覚えていますか?彼らはソートされたセットと呼ばれる美しいものを持っています(なんて素晴らしい作品です、RedisLabsに感謝します??)。ソートされたセットでは、スコア付きのキーを追加でき、Redisはそれに応じてO(log(N))で順序付けします。それは私たちのランキングの問題を分類します??。また、トップ5を取得したり、特定のキーのランクを取得したりするなど、範囲クエリを実行することもできます。これらはすべてO(log(N))で行われます。それがまさにここで必要なものです。

要素は、Redisオブジェクトをスコアにマッピングするハッシュテーブルに追加されます。同時に、要素がスキップリストに追加され、スコアがRedisオブジェクトにマッピングされます(したがって、オブジェクトはこの「ビュー」のスコアで並べ替えられます)—並べ替えられたセットの內部

Bammmmmmリーダーボードの問題も解決されました。

申し分なく申し分なく、それは簡単ではありません、私は私がすぐに実行可能な解決策を得ることができたことをただ嬉しく思いました。それでは、製図板に戻りましょう。

少し威圧的に見えますか?説明させてください

  1. モデレーターが正解を送信するとすぐに、スコア計算トリガーメッセージがプッシュされます。これは、処理パイプライン全體を開始することです。
  2. バッチャーはトリガーメッセージを受信し、正解した人數に応じてDBオフセットオブジェクトと制限オブジェクトのペアを生成します。たとえば、10人が正解し、バッチサイズが5の場合、2つのオブジェクト(バッチ)が生成されます。バッチ1 {オフセット:0、制限:5}、バッチ2 {オフセット:5、制限5}。なぜこれを行うのですか?バッチ処理を実行したり、ページ化されたDBクエリを実行したりできるようにするため、制限なしでDBを呼び出すことはありません。したがって、DBから100萬レコードを取得する必要があり、それを1回で実行すると、多くの場所で多くの問題が発生します。したがって、これをより小さな部分に分割し、より小さなが複數のクエリを実行します。これにより、返される行數は少なくなります。
  3. ユーザーバッチプロセッサはこれらのバッチメッセージを受信し、それに応じてDBクエリを実行します。 {offset:0、limit:5}メッセージを受信するプロセッサは、DBから最初の5つのユーザーIDを取得します(別のバッチ操作も実行しますが、ここで説明するのは少し難しいので、スキップします)。そしてこの後、バッチ処理に別れを告げ、ストリーム処理に切り替えます。バッチプロセッサは、次のプロセッサによって処理される5つのユーザーIDをキューに入れるためです。
  4. これで、ユーザースコア計算機は個々のユーザーIDを受け取り、スコアリングロジックを実行して個々のユーザースコアを計算します。次に、DBを1回更新して、ユーザースコアを変更します。次に、並べ替えられたセット內の特定のユーザーのスコアを更新し、Redisが內部でランクを割り當てまたは更新します。この段階で処理が完了すると、DB內のすべてのユーザーのスコアと、Redis內のすべてのユーザーのランク+スコアが表示されます。また、並べ替えられたセット內の全員のランクがあるため、範囲クエリを実行するだけで、非常に高速なリーダーボードを取得できます。

ユーザーのスコアとランクを取得するために、Redisクエリを実行するだけで、DBに到達できないため、問題のほとんどは解決されました。また、これにより応答時間が速くなります

これで、主要な設計フェーズは終了です。DB、APIデザイン、その他ここではスキップしているものもありました。

第4章:実裝

設計の完了により問題の70%が解決し、これを解決できることがわかっていたので、すぐに開発に取り掛かることができました。

理想的な世界では、新しいサービスを作成し、Goなどの新しい言語を試して、より優れた高速の並列処理などを行います。しかし、タイムラインを考えると、それは正しいことではありませんでした。コアのNodeJSサービスに固執し、すべてをそこに配置しました。マイクロサービスの純粋主義者は、この聲明を見た後にそれを失う可能性がありますが、時間との戦いでは、プリンシパルが後部座席に座らなければならないことがあります。多くのトレードオフの中で、これは私たちが受けた主要な呼びかけの1つでした。

これとは別に、ユニットテストと統合テストも削減する必要がありましたが、その罪悪感は依然として私たちを悩ませています。ただし、リリース後に徐々にテストを埋め戻しています。

上に投稿された詳細な設計を見た後、あなたはあなた自身を実裝することができるはずだと思うので、今回はコードを深く掘り下げるつもりはありません??

第5章:展開と監視

いくつかのバグ修正とQAサインオフの後、準備が整いました。仕事は正しく行われましたか?いいえ、私の友人はまだこの作品の重い監視を設定する必要がありました。非常に短い時間で開発されたので、少なくとも少し自信がありませんでした。デフォルトでは、LightStepを介してこのサービスでトレースが有効になっています。そのため、トレースとは別に、トラフィック、エラーレート、レイテンシダッシュボード、すべてのAPIのアラートの専用モニタリングを設定しました。そして、稼働後の私と私のチームメートは、電話に出て、RAMとCPUの使用狀況からエラーログまで、少なくとも1時間システムの出入りを監視しました。したがって、常に可観測性に等しい重みを與えます監視もします。生産システムに小さな問題があり、監視のおかげで早期に発見することができました。

第6章:回顧展

システムは機能しますが、一息ついた後、回顧展を行い、見逃したことを特定して対処することが重要です。たくさんのことを見逃し、多くのコーナーを切り、大きな改善の余地があったと確信しています。たとえば、ここにいくつか…

私たちがもっとうまくできること

  1. ドライバー、ORM、およびサポートインフラストラクチャがすでに存在するため、これには既存のPostgresDBを使用しました。しかし、私はおそらくデータベースソリューションについて少し調べたいと思います。
  2. NodeJSは素晴らしいですが、これにはGoの方が適していると思います。私たちはこれを探求することができたでしょう。
  3. DBのみでスコアを計算するクエリを作成しようとしましたが、慘めに失敗しました。私はおそらくそれを書くことができ、スコア計算のためのバッチ処理も行うことができ、DB操作をさらに減らすことができました。
  4. 大規模な負荷テストとパフォーマンステストを実行できませんでした。これは必須です。
  5. DBスコアの更新とRedisのソートされたセットの更新のために2つの異なるステージを作成することもできます。これは、よりクリーンな実裝になります。

別れのメモ

その短い時間でできる限りのことをしました。実裝でさえ、元の設計からわずかに逸脫しました。しかし、それは大丈夫です。トレードオフは常に存在します。コア機能は約1週間で完了しましたが、それを投稿するために必要な小さなパッチがありました。

今日、システム設計とソフトウェア開発について1つか2つ學ぶことができたと思います??

クレジット

私の素晴らしいチームメイトに大聲で叫ぶAkashさんのRajとAashirwadカシャップ、我々はすべてちょうど約一週間でこれを構築するために一緒に働きました。

読んでくれてありがとう!

私はAritraDasであり、開発者であり、複雑な分散システムの構築を本當に楽しんでいます。技術に関連するものについてはLinkedinまたはTwitter私に連絡してください

幸せな學習…

提案された投稿

Pythonを使用してパーソナルAIアシスタントを構築する方法

パートI:Pythonを使用してJARVISを設定するためのガイド。

Pythonを使用してパーソナルAIアシスタントを構築する方法

JAを覚えていますか

関連記事

未知の既知、ベイズ推定、および構造化ガウス過程

ドメイン科學者が思っているよりも多くのMLを知っている理由

未知の既知、ベイズ推定、および構造化ガウス過程

MaximZiatdinov12&SergeiV.Kalinin11CenterforNanophase MaterialsSciencesand2ComputationalSciencesandEngineering Division、Oak Ridge National Laboratory、Oak Ridge、TN 37831、United States約20年前、かつての防衛大臣であったドナルドラムズフェルドは有名です。インテリジェンスの狀況に言及して、次のように述べています。私たちが知っていることがあります。

気候緊急事態は紀元前に達しました

気候緊急事態は紀元前に達しました

Digital Organizer 350.org、Jennifer Deol著ちょうど3か月前、カナダ史上最悪の気象イベント、ヒートドーム、そしてこれまでに記録された3番目に悪い山火事シーズンが、1日でリットンのコミュニティを焼き盡くしました。

Pythonでの行列演算

Pythonでの行列演算

始める前に、ここで各用語が何を使用しているかを説明する以前の記事をお勧めしたいと思います。以前に読みたい場合は、リンクを殘しておきます。https://中。

すべてのフリーランサーが新しいクライアントに尋ねなければならない質問

プロジェクトの取り込みは、プロセスの単なるステップではなく、サービスの一部です。

すべてのフリーランサーが新しいクライアントに尋ねなければならない質問

昨年、私は大手金融サービス會社の100人以上の設計チームの採用プロセスの開発を支援しました。私に言わせてください—それはかなりのプロセスでした!悲しいかな、それはまた別の話です。

MORE COOL STUFF

デュークブルーデビルズバスケットボールコーチのマイク?シャシェフスキーは結婚していますか?

デュークブルーデビルズバスケットボールコーチのマイク?シャシェフスキーは結婚していますか?

今シーズンの終わりにデュークバスケットボールからマイク?シャシェフスキーが引退することで、彼は妻や家族とより多くの時間を過ごすことができます。

ニコラス?ブラウンは「サクセション」からどれくらい背が高いですか?

ニコラス?ブラウンは「サクセション」からどれくらい背が高いですか?

「サクセション」のファンは、グレッグ、別名ニコラス?ブラウンの異常に高い高さに気づかずにはいられません。彼は本當にキャストメンバーの上にそびえ立っていますか?

2021年のホリデーシーズンに向けた「パイオニアウーマン」リードラモンド感謝祭のおかず

2021年のホリデーシーズンに向けた「パイオニアウーマン」リードラモンド感謝祭のおかず

パイオニアウーマンリードラモンドは、感謝祭の準備をするためにここにいます。ここに彼女の最高のおかずのいくつかがあります。

「90日フィアンセ」:「シングルライフ」で離婚した妻ナタリーが浮気するマイク?ヨンクイストの関係狀況に関する最新情報

「90日フィアンセ」:「シングルライフ」で離婚した妻ナタリーが浮気するマイク?ヨンクイストの関係狀況に関する最新情報

ナタリーは「90日:シングルライフ」ですが、マイク?ヨンクイストは何をしていますか?マイクの現在の関係狀況について私たちが知っていることは次のとおりです。

ミニクロスワードをお試しください

ミニクロスワードをお試しください

毎週更新される私たちのミニクロスワードは、私たちのお気に入りのハウスタッフワークスの読みと頭のいい手がかりを組み合わせています!

どれが最も効果的ですか:洗濯ポッド、粉末または液體洗剤?

どれが最も効果的ですか:洗濯ポッド、粉末または液體洗剤?

適切な洗剤を選ぶことを心配することなく、洗濯をすることは十分に悪いことです。では、どちらが最適ですか?それとも重要ですか?

ケンタッキーの青い人々の実話

ケンタッキーの青い人々の実話

ケンタッキー州の田舎に住むFugatesとCombsの家族は、遺伝的寶くじを失いました。どちらも、結婚するにつれて肌が青く見える、まれな劣性形質を共有していました。これの原因は何でしたか?そして、家族はどうなりましたか?

カリフォルニアコンドルの「バージンバース」は種を救うことができますか?

カリフォルニアコンドルの「バージンバース」は種を救うことができますか?

カリフォルニアコンドルを絶滅から救うためのプログラムで、2羽の父親のいないオスのヒナが飼育されています。そのような「処女」の誕生はどのように可能ですか?

スターウォーズスペースシューターをお持ち帰りください

スターウォーズスペースシューターをお持ち帰りください

こんにちは。あなたはディズニーの幹部で、買収と一時解雇の間に數分のダウンタイムを過ごしていますか?たぶんあなたはEAで働いていて、バトルフロントIIである災害の後であなたのブランドのスターウォーズの努力を救う方法を考え出そうとしています。

2018トヨタランドクルーザーについて何を知りたいですか?

2018トヨタランドクルーザーについて何を知りたいですか?

(畫像:アンドリューP.コリンズ)2018トヨタランドクルーザーは、トヨタのラインナップの中で最も高価な車両です。

あなたの最も悲慘な家族の夏休み

あなたの最も悲慘な家族の夏休み

學校は今年で締めくくられました。これは、アメリカ中の家族がまもなく車に詰め込み、夏休みのために公道を走ることを意味します。これらの旅行の目的は通常、思い出を結びつけて形成することですが、それらは頻繁に(そして非常に簡単に)失敗します。そのため、今日のおしっこ飛ばしコンテストはあなたの最も悲慘な家族の夏休みに捧げられます。

ガエル?モンフィス、フランスがデビスカップのためにスナッブしたが、代わりにあいまいなスポーツで周りをファック

ガエル?モンフィス、フランスがデビスカップのためにスナッブしたが、代わりにあいまいなスポーツで周りをファック

フランスで最も生きているテニスプレーヤーであるBrendonThorne / Getty Gael Monfilsは、不思議なことに、このスポーツで最も重要な國際トーナメントであるデビスカップの第1ラウンドに選ばれませんでした。彼は、彼のスタープレーヤーが國際的なプレーよりも彼の個人的なキャリアを優先していると感じたチームコーチのヤニックノア、全國テニスの伝説、そしてニックスの狙撃兵ジョアキムの父と彼の長く煮込んだ牛肉を非難することができます。

CardiBとOffsetのDaughterKultureがInstagramで美しい新しいブレードを披露

CardiBとOffsetのDaughterKultureがInstagramで美しい新しいブレードを披露

Cardi BとOffsetの3歳の娘、Kultureは、Instagramで彼女の新しい編みこみのヘアスタイルを披露しました。

セレーナ?ゴメスがニックスの試合でキスカムのためにカーラ?デルヴィーニュに頬をつつく

セレーナ?ゴメスがニックスの試合でキスカムのためにカーラ?デルヴィーニュに頬をつつく

「彼女はとても楽しくて、とても冒険的だ」とセレーナ?ゴメスは以前、仲間のカーラ?デルヴィーニュについて語った。

マドンナはジムでボトルからジンを飲む:「今日のトレーニング」

マドンナはジムでボトルからジンを飲む:「今日のトレーニング」

歌手は木曜日に彼女のフィットネスルーチンを変更することにしました

ジェイミー?ドーナンはヘンリー?カヴィルにスーパーマンの役割を失い、スーパーヒーローの役割のためにマーベルに近づいたと言います

ジェイミー?ドーナンはヘンリー?カヴィルにスーパーマンの役割を失い、スーパーヒーローの役割のためにマーベルに近づいたと言います

ジェイミー?ドーナンは、スーパーマンの役割についてオーディションを受けたが、ヘンリー?カヴィルに敗れたことを明らかにした。そして彼はMCUへの參加についてマーベルに話しました。

Languages

野花在线观看免费观看大全-野花视频在线观看免费观看8
国足最新出线概率0.08% 北京冬奥火炬宣传片获金花环奖 速度与激情9 得知母亲出事男子在地铁痛哭 国足战澳大利亚大名单:4归化在列 周冠宇成为中国首位F1车手 安娜贝尔 尚气与十环传奇 胡锡进谈中美元首会晤 红色通缉令 尚气与十环传奇 印度首都准备封城 房价上涨城市创七年新低 拐点来了? 24岁救人牺牲消防员获批为烈士 扫黑风暴 我要我们在一起 意大利错失直接晋级世界杯资格 中美元首会谈重点内容 中国共产党第三个历史决议全文发布 灵媒 意大利错失直接晋级世界杯资格 俄方回应卫星碎片危及国际空间站 中美元首是否达成新共识?中方回应 男子写80页PPT拯救爱情却离婚 动保组织向上饶信州区申请信息公开 许家印为恒大注入超70亿续命资金 动保组织向上饶信州区申请信息公开 千与千寻 意大利错失直接晋级世界杯资格 两个女人 浦发银行回应近3亿存款莫名被质押 罗永浩吐槽苹果文案没文化 大连现超级传播者26人在同一传播链 扫黑风暴 安娜贝尔 中美元首会谈重点内容 长津湖 图兰朵 24岁救人牺牲消防员获批为烈士 房价上涨城市创七年新低 拐点来了? 五个扑水的少年 大连一密接者擅自点外卖聚餐被调查 男子写80页PPT拯救爱情却离婚 #耿直真香哥黑化卖惨# 动保组织向上饶信州区申请信息公开 扫黑风暴 失控玩家 扫黑风暴 许家印为恒大注入超70亿续命资金 外交部回应拜登重申不支持台独 加拿大一枝黄花到底是什么? 中国医生 男子体检血中抽出2升油浆 红色通缉令 大连现超级传播者26人在同一传播链 国际人士热议中共十九届六中全会 俄方回应卫星碎片危及国际空间站 怒火·重案 得知母亲出事男子在地铁痛哭 嘉南传 中美元首是否达成新共识?中方回应 浦发银行回应近3亿存款莫名被质押 斗破苍穹 蜘蛛侠:英雄归来 扫黑风暴 林丹世界排名被正式移除 男子体检血中抽出2升油浆 大连现超级传播者26人在同一传播链 扫黑风暴 林丹世界排名被正式移除 国足战澳大利亚大名单:4归化在列
神农架林区| 韶山市| 松江区| 抚宁县| 柘城县| 永和县| 德庆县| 惠水县| 彰武县| 云梦县| 邯郸县| 虎林市| 铜陵市| 汝阳县| 康定县| 北流市| 宁都县| 商水县| 安丘市| 库车县| 桂林市| 江永县| 漳平市| 长兴县|