背景
ストリームフィード：情報フローとして理解することができ、溶液は、情報配信問題の情報生産者と消費者との間の情報です。
私たちの共通フィード流れのシナリオは次のとおりです。
1つの手洗い、店の心配消費者のホーム・製品情報、ニュースや他のユーザーに提供するマイクロアモイ
、友人が情報へのタイムリーなアクセスを共有する友人の2マイクロチャンネル円
3マイクロブログには、ファンは、星を懸念取得します大きなV情報
4つの見出し、ユーザーがシステムをお勧めニュース、レビュー、ゴシップにアクセス
上記のシナリオを含むフィード流れアーキテクチャ設計、について、多くの業界の専門家は、対応する思考、デザインと実践を提供します。私はチームはアリ手アモイ、マイクロアモイフィードストリーム記憶層関連サービス、パブリッククラウドにおける当社のHBase / Lindormデータストレージ製品も魂がサポートしている、興味深い見出し、恩恵に関与している芸術の起源のビッグデータ方向ですいくつかの人気の見出しや他の新しいメディア、ソーシャル・ネットワーキング製品。機能的なデータストレージ製品、パフォーマンス、可用性、および着陸フィードストリームアーキテクチャのための本当の希望の我々の理解の中には、いくつかの助けを持つことができるだけでなく、データの製品とどのようにフィードフィードストリームの流れさらなる反復を助けるための将来を議論します。
この記事では、2つの値を提供したいと考えています：
1つのフィードストリーム現在主流のアーキテクチャとフロアプラン
どのようにスタートアップ企業アーキテクチャの進化パスフィードの流れを選択2
ビジネス分析
フィードバリューストリームの参加者
- 情報の生産者
情報が豊富なサポートされる形式（テキスト、画像、ビデオ）、公表流暢（生産情報の可用性を）願って、加入者はタイムリーな情報（適時）を受信、加入者は、（送信の信頼性を）情報を漏洩しません
- 消費者情報
私たちは、貴重な情報を得ることを期待して、メッセージ（配信の信頼性）の友人、偶像を逃さないように期待して、関心（適時）のタイムリーな情報を受け取ることを期待（情報過多を解決するために）
- プラットフォーム
私たちは、より多くの生産者と消費者（PV、UV）、ユーザーより長い滞留時間、広告を誘致したいと考えて、高い商品変換
情報転送フィード
一つは、関係に基づいてメッセージングされ、友人、懸念、サブスクリプションなどの確立を追加することで関係は、双方向でも一方向かもしれかもしれません。一つは、ユーザにプッシュメッセージとして協調フィルタリングアルゴリズムを使用して、システムのユーザ肖像、肖像メッセージカテゴリまたはラベルによれば、推薦アルゴリズムに基づいています。見出し、賛成のビブラートベースの勧告に基づいて関係の賛成でWeiboマイクロチャネルおよびバイアスさ。
技術的な難しさは、流れをフィード
インターネットシーンはいつものは、公共データの二組を見てみましょう、技術的なボトルネックを反映するために、特定のサイズが必要になります。
例えば、シングルコア、早い2017 160万人が毎日のアクティブユーザー、ほぼ3.3億毎月のアクティブユーザーは、毎日千億の総データ容量をデータの何百万、数百を追加し、モバイルソーシャルネットワーキング時代のヘビー級のソーシャル共有プラットフォームとして、シーナマイクロブロギング、最大1万ドルのQPSアクセスバックエンド・データ・サービス
、毎日の見出しのアクティブユーザー7800W、毎月のアクティブユーザー1.75億2016年12月の終わりの時点で、シングルユーザーの平均の長さ76分、ユーザーの行動ピーク150ワット+ MSG / sの、トレーニングデータを毎日300T +（圧縮）、機械スケール万人レベル
上記または履歴2人の巨人のメトリックは、百万までの数百GBやQPSの規模は約93TB千億のメッセージの日々増加のデータ量をメッセージの1キロバイトを想定し、そのためスループットを読み書きする高い必要性を持って、拡張性の良いです分散ストレージシステム。ユーザーが応答した数百ミリ秒のニュースを閲覧することを期待、ニュース見た希望は、システムのリアルタイム要件は、第二のレベルまたは少なくとも約1分で非常に高く、マルチレベル・キャッシュ・アーキテクチャが必要です。このシステムは、高可用性、優れた耐障害性を持っている必要があります。最後に、このシステムは最高あまりにも高価ではありません。
したがって、我々は、高スループット、拡張性の高い、低遅延、高可用性、低コストフィードストリーミング・アーキテクチャを必要とします
主流のアーキテクチャ
図1は、消費者に生産者からのメッセージを渡すプロセスを完了するために、単純なフロー抽象フィードです。
図の簡単な抽象化1つのフィード流れ
メッセージとの関係
まず、ユーザは、APP側は、各ユーザーは、必ずしもあなたがメッセージ全体を渡した場合、リソースの無駄があるので、メッセージは、第一世代のうちに生成され、ブラウザを開くことはありませんが、このリストは、必ずしもすべての新しいメッセージが含まれていませんフィードIDリストで取得します2つの本体部分及び指数、前記指数は、メッセージIDおよびメタデータを含んでいます。第二に、常にアプリケーションの関係は、関係ベースの配信が不可欠であり、したがって、ストアとクエリサービスとの間の関係がなければなりません。
図2フィードストリーム記憶されたメッセージとの関係
消息本身应该算是一种半结构化数据（包含文字，图片，短视频，音频，元数据等）。其读写吞吐量要求高，读写比例需要看具体场景。总的存储空间大，需要很好的扩展性来支撑业务增长。消息可能会有多次更新，比如内容修改，浏览数，点赞数，转发数（成熟的系统会独立一个counter模块来服务这些元数据）以及标记删除。消息一般不会永久保存，可能要在1年或者3年后删除。
综上，个人推荐使用HBase存储
- HBase支持结构化和半结构化数据；
- 具有非常好的写入性能，特别对于Feed流场景可以利用批量写接口单机（32核64GB）达到几十万的写入效率；
- HBase具备非常平滑的水平扩展能力，自动进行Sharding和Balance；
- HBase内置的BlockCache加上SSD盘可以提供ms级的高并发读；
- HBase的TTL特性可以自动的淘汰过期数据；
- 利用数据复制搭建一个冷热分离系统，新消息存储在拥有SSD磁盘和大规格缓存的热库，旧数据存储在冷库。
- 运用编码压缩有效的控制存储成本，见HBase优化之路-合理的使用编码压缩
图3 使用HBase存储Feed流消息
对于关系服务，其写入操作是建立关系和删除关系，读取操作是获取关系列表，逻辑上仅需要一个KV系统。如果数据量较少可以使用RDS，如果数据量较大推荐使用HBase。如果对关系的QPS压力大可以考虑用Redis做缓存。
图4 用户关系存储
消息传递
讲到Feed流一定会有关于推模式和拉模式的讨论，推模式是把消息复制N次发送到N个用户的收信箱，用户想看消息时从自己的收信箱直接获取。拉模式相反，生产者的消息写入自己的发信箱，用户想看消息时从关注的M个发信箱中收集消息。
图5 消息传递的推模式和拉模式
推模式实现相对简单，时效性也比较好。拉模式要想获得好的性能需要多级的缓存架构。推模式重写，拉模式重读，Feed流场景下写的聚合效果要优于读，写可以大批量聚合。N越大，写入造成的数据冗余就越大。M越大，读消耗的资源越大。
随着业务的增长，推模式资源浪费会越发严重。原因在于两点：第一存在着大量的僵尸账号，以及大比例的非活跃用户几天或者半个月才登陆一次；第二信息过载，信息太多，重复信息太多，垃圾信息太多，用户感觉有用的信息少，消息的阅读比例低。这种情况下推模式相当一部分在做无用功，白白浪费系统资源。
是推？是拉？还是混合？没有最好的架构，只有适合的场景~
基于关系的传递
图6是纯推模式的架构，该架构有3个关键的部分
- 异步化。生产者提交消息首先写入一个队列，成功则表示发布成功，Dispatcher模块会异步的处理消息。这一点非常关键，首先生产者的消息发布体验非常好，不需要等待消息同步到粉丝的收信箱，发布延迟低成功率高；其次Dispatcher可以控制队列的处理速度，可以有效的控制大V账号造成的脉冲压力。
- 多级队列。Dispatcher可以根据消费者的状态，信息的分类等划分不同的处理方式，分配不同的资源。比如对于大V账号的消息，当前活跃用户选择直接发送，保障消息的时效性，非活跃用户放入队列延迟发送。比如转发多的消息可以优先处理等。队列里的消息可以采用批量聚合写的方式提高吞吐。
- 收信箱。假如有两亿用户，每个用户保留最新2000条推送消息。即便存储的是索引也是千亿的规模。收信箱一般的表结构为用户ID+消息序列 + 消息ID + 消息元数据，消息序列是一个递增的ID，需要存储一个偏移量表示上次读到的消息序列ID。用户读取最新消息 select * from inbox where 消息序列 > offset。
图6 基于关系传递的纯推模式
推荐使用HBase实现收信箱
- HBase单机批量写能力在几十万并且可以水平扩展。
- HBase的高效前缀扫描非常适合读取最新的消息。
- HBase的TTL功能可以对数据定义生命周期，高效的淘汰过期数据。
- HBase的Filter过滤器和二级索引可以有效的实现Inbox的搜索能力。
消费者收信箱hbase表设计如下，其中序列号要保证递增，一般用时间戳即可，特别高频情况下可以用一个RDS来制造序列号
| Rowkey | 消息元数据列 | 状态列 | 其它列 |
|---|---|---|---|
| MD5(用户ID)+用户ID+序列号 | 消息ID、作者、发布时间、关键字等 | 已读、未读 |
图7是推拉结合的模式
- 增加发信箱，大V的发布进入其独立的发信箱。非大V的发布直接发送到用户的收信箱。其好处是解决大量的僵尸账号和非活跃账号的问题。用户只有在请求新消息的时候（比如登陆、下拉消息框）才会去消耗系统资源。
- 发信箱的多级缓存架构。一个大V可能有百万粉丝，一条热点消息的传播窗口也会非常短，即短时间内会对发信箱中的同一条消息大量重复读取，对系统挑战很大。终态下我们可能会选择两级缓存，收信箱数据还是要持久化的，否则升级或者宕机时数据就丢失了，所以第一层是一个分布式数据存储，这个存储推荐使用HBase，原因和Inbox类似。第二层使用redis缓存加速，但是大V过大可能造成热点问题还需要第三层本地缓存。缓存层的优化主要包括两个方向：第一提高缓存命中率，常用的方式是对数据进行编码压缩，第二保障缓存的可用性，这里涉及到对缓存的冗余。
图7 基于关系传递的推拉混合模式
基于推荐的传递
图8是基于推荐的模型，可以看出它是在推拉结合的模式上融合了推荐系统。
- 引入画像系统，保存用户画像、消息画像（简单情况下消息画像可以放在消息元数据中）。画像用于推荐系统算法的输入。
- 引入了临时收信箱，在信息过载的场景中，非大V的消息也是总量很大，其中不免充斥着垃圾、冗余消息，所以直接进入用户收信箱不太合适。
- 收信箱和发信箱都需要有良好的搜索能力，这是推荐系统高效运行的关键。Outbox有缓存层，索引可以做到缓存里面；Inbox一般情况下二级索引可以满足大部分需求，但如果用户希望有全文索引或者任意维度的检索能力，还需要引入搜索系统如Solr/ES
图8 基于推荐的Feed流架构
用户画像使用HBase存储
- 画像一般是稀疏表，画像总维度可能在200+甚至更多，但单个用户的维度可能在几十，并且维度可能随业务不断变化。那么HBase的Schema free和稀疏表的能力非常适合这个场景，易用且节省大量存储空间。
- 对画像的访问一般是单行读，hbase本身单行Get的性能就非常好。阿里云HBase在这个方向上做了非常多的优化，包括CCSMAP、SharedBucketCache、MemstoreBloomFilter、Index Encoding等，可以达到平均RT=1-2ms，单库99.9% <100ms。阿里内部利用双集群Dual Service可以做到 99.9% < 30ms，这一能力我们也在努力推到公有云。hbase的读吞吐随机器数量水平扩展。
临时收信箱使用云HBase
- HBase的读写高吞吐、低延迟能力，这里不再重复。
- HBase提供Filter和全局二级索引，满足不同量级的搜索需求。
- 阿里云HBase融合HBase与Solr能力，提供低成本的全文索引、多维索引能力。
初创公司的迭代路径
在业务发展的初期，用户量和资源都没有那么多，团队的人力投入也是有限的，不可能一上来就搞一个特别复杂的架构，“够用”就行了，重要的是
- 可以快速的交付
- 系统要稳定
- 未来可以从容的迭代，避免推倒重来
本人水平有限，根据自身的经验向大家推荐一种迭代路径以供参考，如有不同意见欢迎交流
起步架构如图9，使用云Kafka+云HBase。如果对Inbox有检索需求，建议使用HBase的scan+filter即可。
- 消息分为主体和索引
- 采用纯推的模式
- 采用异步化
图9 起步架构
数据量逐渐增大后，对推模式进一步迭代，主要需求是
- 控制大V造成的写入脉冲高峰
- 控制存储成本
- 提升读写性能
- 提升一定的Inbox搜索能力
进一步的迭代架构如图10
- 消息分为主体和索引
- 采用纯推的模式
- 采用异步化
- 采用多级队列解决大V问题
- 采用冷热分离降低存储成本
- 此时Inbox中的消息也很多，对搜索的需求增强，仅仅Scan+Filter不够，可能需要二级索引
图10 纯推模式的演进
业务迅猛发展，消息和用户增长迅速，僵尸账号、非活跃账号较多，信息过载严重
- 消息分为主体和索引
- 采用推拉结合模式
- 采用异步化
- 引入推荐系统
- 采用冷热分离降低存储成本
- Outbox采用多级缓存提高读取性能
- Inbox增加二级索引提升搜索能力
使用云Kafka+云HBase+云Redis
图11 基于推荐的推拉混合架构
总结
Feed信息流是互联网场景中非常普遍的场景，遍布于电商、社交、新媒体等APP，因此研究Feed流是非常有价值的一件事情。本文总结了Feed流的业务场景和主流架构，分析了不同场景、体量下技术的难点与瓶颈。对Dispatcher、Inbox、Outout几个组件进行了详细的演进介绍，提供了基于云环境的落地方案。本人水平有限，希望可以抛砖引玉，欢迎大家一起探讨。Feed流的架构演进还在持续，不同业务场景下还有哪些缺陷和痛点？数据产品如何从功能和性能上演进来支撑Feed流的持续发展？在这些问题的驱动下，云HBase未来将会大力投入到Feed流场景的持续优化和赋能！
原文链接
本文为云栖社区原创内容，未经允许不得转载。