タオバオの技術発展レビュー（VI）：Java時代：技術の創造

タイル

TFSの開発により、Taobaoの画像機能がフル活用できるようになりました。 TFS と同様に、多くのテクノロジは製品の推進力によって開発されています。以下のテクノロジーについて説明する前に、私たちが長年にわたり共同で取り組んできたいくつかの製品についてお話しする必要があります。

まずはもっと悲劇的な「グループ購入」についてお話ししましょう。このグループ購入は、現在街中でよく見かけるGrouponのようなモデルではありません。Grouponが誕生する前の2006年、TaobaoのプロダクトマネージャーであるYideng氏が「グループ購入」という商品を提案しました。イーデンの当初のアイデアは、買い手がコミュニティ内でグループ購入を開始できるようにすることでした。「グループリーダー」が十分な人数を見つけた後、売り手と交渉します。これは、現在のモグジエの「フリーグループ」に似ています。しかし、さまざまな理由により、開発中に製品の機能が削減され、当初のアイデアから少し逸脱しました。現在は、売り手がグループ購入価格を設定できるようになり、購入者の数が指定数に達すると、グループ購入価格で取引が完了するようになりました。この機能は、タオバオの固定価格とダッチオークションを組み合わせた別の取引モデルのようですが、残念ながら長続きしませんでした。この取引方法の最大の弱点は、買い手が売り手のカードを見ることができることです。グループ購入数量に達しなくても、グループ購入価格を値下げします。当時、タオバオは集客のために共同購入エリアを開設しました。誠実な販売者が共同購入数量に達しなかった場合、彼らは切り捨てられ、損失を被りました。狡猾な販売者は単に元の価格を引き上げ、このエリアを宣伝に利用しました。その後 2 年間で、この製品は販促ツールになりました (現在街のいたるところで見られる共同購入は、実際には販促活動です)。この製品により、研究開発担当者は「製品」の概念を深く理解することができました。

さらに悲惨な話をしましょう-[マイタオバオ]。マイタオバオは、会員が自分の商品、取引、配送先、レビュー、苦情などを管理する場所です。この場所はログインしてからしか見られない場所なので、外の世界とはスタイルがまったく異なります。長い間最適化されておらず、見た目が醜く、ユーザーが操作するのに不便です。商品をたくさん持っている人は、それらを1つずつ棚に出し入れする必要があり、非常に面倒です（本を売っている人を思い浮かべてください）。この時、重要な人物、程志（現在のモグジエのCEO。彼は私に、もっとかっこいい言い方で彼を表現してほしいと頼みました）が現れました。彼は、GmailのAjaxインタラクション方式という、最も驚くべきフロントエンドインタラクション技術を実演してくれました。ドラッグ、右クリック、キーの組み合わせで選択することができ、操作が完了した後もページは更新されません。製品を管理するのは、まるで神様に助けられているようなもので、とてもクールです。私はこのプロジェクトのプロジェクト マネージャー、Yideng はプロダクト マネージャーで、Wan Jian とエンジニアのグループが加わって作業を開始しました。 3ヶ月間の努力の末、ほぼ完成に近づいたとき、突然老馬が私の後ろに現れました。**が私のTaobaoの新しいバージョンを作ったのを見て、彼は私にそれがクライアントソフトウェアであるかどうか尋ねました。私はそれがウェブページだと言いました。彼は怒って、それはクライアントソフトウェアと同じで、リンクの下に接続がなく、フォルダを使用して出品と出品解除を表していると言いました。私はそれを操作する方法を知らず、売り手も確かにそれをどのように使用するかを知りませんでした。

老馬はまさに神のような人物で、彼の言ったことは現実になりました。タオバオ史上初の**事件が勃発しました。マイタオバオの新バージョンを試した後、多くのセラーが怒り、使い方が分からないと言いました。 Yideng は Chengzhi と、このページを Web ページに近づける方法について話し合いました。変更を加えてから半月経っても、怒りは収まりませんでした。私は、二人がどうしようもなく主張するのを見て、上司とどうするかを話し合いました。その後、私たちは非常に苛立たしい方法で自分たちに逃げ道を与えました。フォーラムに行き、My Taobao の新バージョンを使用するかどうか全員に投票してもらいました。投票の結果、半数以上の人が反対でした。こうして、12 人が 3 か月間取り組んできたシステムは廃止されました。これは私をとてもイライラさせましたが、最も辛かったのはこれではありませんでした。私たちがオフラインになった後、別のグループの販売者が不満を抱き、「なぜこんなに良い機能がなくなったのか？」と尋ねました。ああ~~~なぜもっと早く前に出てこなかったのですか？この製品は私たちに新しい技術（Ajax、YUIフロントエンドフレームワーク）への試みをもたらし、また新しい技術によって引き起こされたユーザーの操作習慣の変化ももたらしたので、私たちは非常に慎重にならなければなりません。私たちがまだ学んでいないもう一つの教訓は、** に対処する際に途方に暮れていたことです。その後、[招财进宝] と Taobao Mall で** 事件が発生したとき、悲劇が繰り返されていることに気づきました。

【富と財をもたらす】といえば、これが最も悲劇的な製品です。 2006 年のメーデーまでに、画期的なプロジェクトが開始されました (私は不運にも 2 回連続でメーデーを逃してしまいました。最初のメーデーは 2005 年に Alipay システムに取り組んでいたときでした)。財神は最高のプロジェクトラインナップを使うと言って、私が選ばれました。これにより、私は最高の従業員に分類されることができると感じ、製品「私のタオバオ」でひどく傷ついた私の心は再び癒されました。これはコモディティ P4P システムであり、支払いはトランザクションに基づいています。多くの売り手はすでに裕福だと思いますが、Taobao には商品がたくさんあるため、売り手を見つけるのは難しく、売り手は商品を最前線に出すために喜んでお金をかけます。弊社では、販売者が広告スペースを購入し、特定のアルゴリズムに従って商品をランク付けすることを許可しています（Baidu の入札ランキングに似ていますが、支払った金額だけでなく、信用、取引量、お気に入りの数なども考慮されます。このアルゴリズムは非常に複雑です）。これはなんと素晴らしい収益モデルでしょう！

システムは順調に進みましたが、リリースされると、より大きな問題が浮上しました。購入者は「3年間は料金を請求しないと約束したのではないですか？広告を請求するのは料金ではないのですか？」と疑問を呈しました。その後、競合他社が火に油を注ぎました。PR会社や業界のさまざまな大物が飛び交い、私たちの同業者でさえ、会員に対応するために「ワンクリック引っ越し」機能を作成しました。一時、世論は騒然となり、あらゆる批判が彼に向けられた。この状況を終わらせるために、私たちは再びフォーラムでユーザーに投票してもらい、商品をオフラインにするかどうかを決めてもらいました。[My Taobao]と同じように、悲劇に終わりました。 【My Taobao】と同様に、オフラインになった後、その甘さを味わった販売者グループは、なぜこのような優れた機能がなくなったのかと疑問を抱いていました。（この部分の需要が同様の製品形式で満たされたのは、Yahoo Chinaが合併してTaobao Expressを開発してからでした）

プロジェクトは失敗しましたが、このプロジェクトでは、ユーザー行動追跡や Ajax などを使用して、テクノロジーの探求がより深く行われました。技術的な詳細の 1 つは非常に古典的です。Taobao の商品詳細ページの毎日のトラフィックは 10 億を超えており、コンテンツはキャッシュに保存されています。抽選を行うときは、販売者に商品の閲覧回数を表示する必要があります (下の図を参照)。この数値はリアルタイムで更新する必要があり、キャッシュを使用する場合は、通常、非同期で更新されます。そのため、このようなフィールドが製品テーブルに追加され、PV が追加されるたびにこのフィールドを更新する必要があります。リリースから 1 時間後にデータベースがクラッシュし、大量の更新をサポートできなくなりました。データベースが追いつけない場合はどうすればよいでしょうか? 一般的なキャッシュ戦略では、リアルタイム更新はサポートされていません。このとき、Duolong 師匠はアイデアを思いつき、Apache にモジュールを作成しました。データは、基盤となる Web コンテナーを通過せずに (Apache のみを介して) 集中キャッシュ領域に書き込まれます。その後、このキャッシュ領域のデータは、データベースに非同期的に更新されます。これは先ほども述べたことですが、商品詳細ページ全体がキャッシュ内にあり、キャッシュを最大限に活用しています。

（この写真は広告ではありません）

それでは次に、キャッシュ技術についてお話ししましょう。

Taobao は、非常に早い段階からキャッシュ テクノロジを使い始めました。2004 年には、ESI (Edge Side Includes) と呼ばれるキャッシュを使用していました。 ESI の使用を決定する前に、Duolong は多くの Java キャッシュを試しましたが、どれも重すぎました。その後、Oracle Webcache を使用しましたが、これも頻繁にクラッシュしました。Oracle Webcache も ESI をサポートしていたため、Duolong は ESI という優れたものを発見しました。 ESI は、Web ページの一部 (ここではページ フラグメントを指します) をバッファリング/キャッシュするためのテクノロジとサービスを提供するデータ バッファリング/キャッシュ サーバーです。仕様はOracleとAkamai Technologiesによって設定され、Akamaiは対応する情報伝送サービスを提供します。従来、データ キャッシュ サーバーと情報送信サービスは「ページ」単位で作成され、データ キャッシュ サーバーにコピーされ、静的ページの処理に非常に効果的でした。しかし、動的なコンテンツに直面すると、高い効率を達成することは困難です。 ESI では、XML ベースのマークアップ言語を使用してキャッシュするページ部分を指定し、部分的にキャッシュされた Web ページが作成されます。その結果、ページは動的に変化する部分と静的で変化しない部分に分割され、静的な部分だけが実際にサーバーに送信されます。 Taobao 上のデータのほとんどは動的に生成されますが、ページのヘッダーとフッター、商品詳細ページの販売者情報など、ページ内には静的フラグメントも多く存在し (下図の右側を参照)、これらは最初に ESI キャッシュから読み取られます。

ESI は、ページ上の静的フラグメントをキャッシュする問題を解決します。賢明な読者は、バックエンドのデータをキャッシュできるかどうかをすぐに考えるでしょう。明らかに、それは可能であり、必要です。たとえば、大規模な販売業者の製品やストアは 1 日に数百万ページビューがあるかもしれませんが、小規模な販売業者の場合は数ページしか表示されません。大規模な販売業者のユーザー情報を毎回データベースから取得するのは明らかに費用対効果が高くありません。この情報をメモリに保存し、毎回メモリから取得すると、パフォーマンスが大幅に向上します。このようなアプリケーション シナリオでは、memcached のようなキー速度キャッシュが役立ちます。残念なことに、Taobao が memcached を緊急に必要としていたときには、まだ登場していませんでした (2003 年 6 月に登場しましたが、近年になって人気が出てきたため、当時は発見されていませんでした)。弊社のアーキテクトであるDuolongが再び行動を起こしました。彼はTBstoreというキャッシュシステムを書きました。これはBerkeleyDBをベースにした分散キャッシュシステムです。リリース後、Alibabaグループ内で広く使用され、特にTaobaoで使用されています。TBstoreは、ESI（前述のESI）、チェックコード（検証コード）、説明（前述の商品の詳細）、ストーリー（ムードストーリー、商品情報の中で商品詳細に次ぐ長さの大きなフィールド）、ユーザー情報などのコンテンツを適用します。

TBstore の分散アルゴリズムの実装: 保存されたキーに基づいて、キーに対してハッシュ アルゴリズムを実行してハッシュ値を取得し、ハッシュ値とキャッシュ サーバーの合計データの係数を取得します。次に、モジュロ値に基づいて、この値のインデックスを持つサーバー リスト内のキャッシュ サーバーを検索します。これは javaclient api のカプセル化によって実装されており、アプリケーションはこれを気にする必要はありません。これは memecached の実装とまったく同じです。

TBstore には利点があり、それは弱点でもあります。そのストレージは Berkeley DB に基づいています。データ量がメモリを超えると、BerkeleyDB はデータをディスクに書き込むため、永続的なストレージとして使用できます。ただし、データがディスクに書き込まれると、キャッシュとしてのパフォーマンスは大幅に低下します。

当時、別のプロジェクトがタオバオのキャッシュ技術の向上を促進しました。 2007年に、Taobaoのユーザー情報をUIC（ユーザー情報センター）と呼ばれる中央システムに分離しました。Taobaoのすべての機能はユーザー情報に依存しているため、このモジュールを分離する必要がありました。そうしないと、将来的にシステムを拡張できなくなります。 UIC が取り出された後、アプリケーション システムは UIC にアクセスし、UIC はデータベースにアクセスしてユーザー情報を取得します。大まかに計算すると、毎日数十億のユーザー情報が取得されます。データベースを直接クエリすると、データベースがクラッシュするのは明らかです。ここではキャッシュを使用する必要があります。そこで Duolong は UIC 専用のキャッシュ システムを作成し、それを tdbm と名付けました。 tdbm は BerkeleyDB の永続化機能を放棄し、すべてのデータをメモリに保存します。 2009 年までに、Duolong は memcached のメモリ構造を参考にし、tdbm のクラスタ分散方式を改良し、メモリ使用率とスループットを大幅に向上させ、tdbm2.0 システムを立ち上げました。

tdbm と TBstore のデータ インターフェースと用途は非常に似ているため、開発チームはこの 2 つを統合し、Taobao 独自の KV キャッシュ システムである tair を立ち上げました。 Tair には、キャッシュと永続性の 2 つのストレージ機能が含まれています。分散システムである Tair は、中央制御ノードと一連のサービス ノードで構成されます。中央制御ノードを構成サーバー、サービス ノードをデータ サーバーと呼びます。構成サーバーは、すべてのデータ サーバーを管理し、データ サーバーのステータス情報を維持する役割を担います。データサーバーは外部にさまざまなデータ サービスを提供しており、そのステータスをハートビートの形式で構成サーバーに報告します。 Configserver は制御ポイントであり、単一のポイントです。現在、信頼性を確保するために 1 つのマスターと 1 つのバックアップが使用されています。すべてのデータ サーバーは同等です。 Tair のアーキテクチャ図は次のとおりです。

現在、Tair はほぼすべての Taobao システムのキャッシュ情報をサポートしています。 Tair はオープンソースであり、code.taobao.org から入手できます。

TFS と Tair を作成した後、システム全体のアーキテクチャは次のように表示できます。

このとき、検索エンジンの iSearch もアップグレードされました。以前の検索エンジンはデータを複数のマシンに分割していましたが、各データのコピーは 1 つしかありませんでした。現在では、データの各コピーは複数のコピーになり、システム全体が単列展開からマトリックス展開に変わりました。より大きなトラフィックをサポートし、高い可用性を実現できます。

原文: http://blog.sina.com.cn/s/blog_633219970101062y.html

タオバオの技術発展レビュー（I）：「独身の日」のカーニバル

タオバオの技術発展の振り返り（第2部）：個人ウェブサイトの時代

タオバオの技術開発レビュー（第3部）：Oracle/Alipay/Wangwang

タオバオの技術発展レビュー（IV）：Java時代の復活

タオバオの技術発展レビュー（V）Java時代：堅固な岩のように

原題：タオバオの技術発展の回顧（VI）：Java時代：技術の創造

キーワード: 淘宝網、インターネット技術、技術開発、開発、Java、時代、創造、技術、タイ、ウェブマスター、ウェブサイト、ウェブサイトの宣伝、金儲け