这旨在指导您完成关键的体系结构决策，这将使社交应用程序成为真正的下一代社交产品。提议的更改解决了以下属性：
a）可用性
b）可靠性
c）可扩展性
d）扩展的性能和灵活性（非修改）
目标
a）确保用户的内容易于发现并且始终可用。
b）确保推送的内容不仅在语义上相关，而且从用户的设备角度来看也相关。
c）确保生成，推送和分析实时更新。
d）着眼于尽可能节省用户资源。
e）不管服务器负载如何，用户的体验都应保持不变。
f）确保整体应用程序安全
总而言之，我们要应对一个惊人的挑战，我们必须应对庞大的海量，不断扩大的用户生成内容，不断增加的用户数量以及源源不断的新商品，同时还要确保出色的性能。考虑到上述挑战，我们必须研究某些会影响整个系统设计的关键架构元素。以下是一些关键的决策和分析。
数据存储
数据存储和数据建模是要做出的关键决定之一。社交产品有望处理多种类型的数据，因此在为每种类型选择模型和存储之前，我们必须全面分析和理解数据，这一点至关重要。
第一步是确定哪些是最频繁查询的数据，哪些不是那么频繁需要的数据（用于分析的存档数据）。对于期望以较高频率查询的数据，需要将其放置在始终可用的位置，以便更快地读写和水平扩展。现在，尽管我们的用例并未强制使用基于RDBMS的系统，但我们在所有用例中都使用MySQL。随着数据的增长，我们的读写将成为应用程序性能的瓶颈。我们应该准备好每秒处理数十亿次查询。
让我们对数据进行分类：
a）主数据或静态形式的数据，例如用户个人资料
b）语义数据
c）用户生成的内容
d）会话数据
对于我们而言，要找到对所有这些类型的数据都具有高性能的数据存储确实是很难的。因此，我们将需要为每个数据库选择特定的数据存储。
静态数据：对于静态数据，最好选择基于文档的存储，其中键和值都是可查询的。我们可以在这里选择建立良好的基于文档的存储，例如MongoDB。选择MongoDB的最大优点是它在文档级别提供ACID属性。
它可以轻松地在多个分布式数据中心内和跨多个数据中心进行扩展。这将使我们能够使用副本集轻松维护冗余，从而解决我们的可用性问题。
分片是另一个要考虑的大因素，这对于确保规模和速度至关重要。幸运的是，MongoDB支持透明地分片。
关联数据或关系数据（核心数据）：我们的数据的大部分将在自然界中连接，例如，A是B的朋友，C是A和B的朋友。此类数据是高度语义化的数据，最适合建模作为图形。我们应该将这些数据存储在像Neo4j这样的图形数据库中。优势显而易见；这将使我们能够存储节点的所有连接以及节点本身，从而节省了计算连接数据之间关系的额外步骤。图形数据模型还将在这里帮助我们捕获关系的属性。当尝试探索连接的数据时，属性丰富的关系绝对至关重要。GraphDB支持ACID规则和自动索引。
同样，我们在可用性和可伸缩性方面的要求是相同的。我们可以有成百上千的并发事务全部同时写入数据库以及成千上万的读取。它应该扩展为每秒处理多个PB数据集中的十亿次读取。
我们需要一个允许动态缩放读写的系统。要考虑的另一个因素是分片，这对于扩展我们的系统至关重要。
Neo4j已经设计成可以水平扩展，并具有复制功能以保证可用性。但截至目前，它不支持分片。选择一个时，我们可能需要更多分析。其他选项是FlockDB，AllegroGraph和InfiniteGraph。
二进制数据（UGC）：我们还必须处理与用户相关的大量二进制数据。考虑到二进制数据的大小，要处理它并不容易。像上面讨论的那样，我们的系统是一个需求可以在几秒钟之内运行的很高的系统（峰值），规模和可用性是决定存储位置时要考虑的最关键因素。我们不能在这里依靠文件系统来存储我们的二进制数据。我们必须考虑可用性和可伸缩性。文件系统的缓存可能受CPU限制，因此使其冗余将需要大量的簿记工作。相反，我们应该依靠已经可用的系统。例如，AmazonS3，这是非常受欢迎的对象存储，具有保证的可用性，并且具有弹性。
我们也可以考虑使用GoogleCloudStorage或RackspaceCloudFiles等。但是就报价而言，S3显然是赢家。
S3已经支持数据分区。它根据高请求率和分区中的键数，通过将数据连续拆分为多个分区，从而水平扩展S3。但是重要的是要意识到仅存储内容是不够的，与这些内容相关联的元数据需要可搜索，并且搜索必须足够扩展和足够快。我们还可以在这里尝试一些新事物，例如从图像自动识别尺寸，基于上下文自动标记等，然后使用它们来驱动图像的键*。这是一个潜在的IP领域。我们将在索引部分下研究索引需求。但是现在，让我们仅注意，我们将使用标识符存储内容，该标识符可以在其他地方建立索引。亚马逊的S3似乎最适合这种情况。
会话数据
重要的是要认识并理解为什么我们需要考虑会话数据。会话数据将帮助我们维护用户的状态。而且此状态应以与服务器无关的方式持续，以使我们的部署规模扩大。这将有助于我们使设计保持足够的灵活性，从而确保会话不会停留在特定的节点或服务器上。
我们必须以一种可以重新生成用户实际会话的方式来保存会话信息，如果用户会话终止，我们仍然可以帮助用户从他离开的地方开始。
这在我们的市场中尤其重要，因为那里的连接不是很可靠，通常会丢包。这些数据需要在我们的所有节点上都可用，因此需要可用性和可伸缩性。首先，我们可以很好地将其保存在我们的MongoDB中。稍后，我们可以考虑将其转移到像REDIS这样的纯键值存储中。
注意：所有建议作业和脱机作业应仅在非服务节点上运行。
索引编制
索引对于我们的系统至关重要。用户可以搜索任何内容，这是我们的主要用例之一。为了提高搜索性能，我们必须非常重视索引编制。这里有两件事要考虑。首先是创建索引本身，其次是创建索引系统。
为了使有意义的可搜索系统，我们必须设计一个实时索引，该索引被倒置并在生成的内容窗口上工作。首先，我们可以编写一个非常简单的系统，在内容摄取期间，该系统可以负责根据内容生成反向索引。后来，随着内容摄取负载的增加，我们可以简单地用实时数据处理引擎（例如ApacheStorm）代替它，这是一个分布式，容错且高度可扩展的系统。它可以接管索引逻辑的生成。
索引系统：Lucene因其受欢迎程度和速度而成为显而易见的选择。其性能无与伦比。我们应该选择SolrCloud。它已经支持透明分片，复制，并且具有读写侧容错功能。
排队和推送通知
每次在我们的应用中触发事件时，我们都将被要求以通知的形式将该事件散发给他/她的