彼らは主に、直列化プロトコルです。マシンやプロセス間でデータを転送したり、ディスクなどに格納したりする必要がある場合は、シリアル化する必要があります。
XML/JSONの/ etcはOKを動作しますが、彼らは彼らが望ましくないものに一定のオーバーヘッドを持っている - 限定された機能に加えて、彼らは比較的大きく、かつ、いずれかの方向に処理する計算コストが高いです。サイズは圧縮によって改善することができますが、それはさらに処理コストを増やします。彼らは人間が読めるという利点がありますが、ほとんどのデータは人間によって読み取られません。
今、人々は手動それほど冗長ある退屈な、バグだらけ、次善、据え置き型の形式を書い年齢を過ごすことができ、または、彼らは十分に文書化され、十分にテストされた汎用シリアル化形式を使用することができますfarをあまりにも長い間友好的であることを心配して過ごした人々(例えば、バージョンに耐性がある)によって設計された、クロスプラットフォーム、安価なプロセス。理想的には、プラットフォームに依存しない記述レイヤ(「wsdl」または「mex」と考える)を許可すると、他の開発者に「どのようなデータが表示されるか」を簡単に言えるようになります新しいシリアライザ/デシリアライザを一から作成することなく、データを無駄なく消費させることができます。 。いるProtobufと倹約の出番です
ほとんどの場合ボリュームワイズ、私は実際に両端が同じ会社で同じ技術であることを期待する:単純に、彼らはデータを取得する必要がありますAからBへの最小限の煩わしさとオーバーヘッドで、またはそれらを保存して後で読み戻す必要があります(たとえば、redis blobの内部でprotobufを2次キャッシュとして使用するなど)。
プリミティブデータ型のセットを効率的にバイナリエンコーディングするための「型付き」メッセージフォーマットです(メッセージジェネレータを使用する際には、明示的なカスタムエンコーダを必要としません)。交換または記憶(シリアライゼーション)メカニズムとして有用です。フォーマットは明確に定義されているため、言語間で共有することができます(実装が存在する場合)。同じ言語を使用するリモートプロセスによって共有されるか、1つのプロセス内でシリアライズに使用されます。そして、はい、彼らは効果的に同じ市場(Avroと他の人たちと同じ)のために戦っています。 –
私はこれらがリンクされるべきだと思う:[最大の違いは、プロトコルバッファの対Thriftのですか?](0120-18753) – blong