2014年Twitter发布了Answers，至今移动社区产生了惊人的使用量，让Twitter感到兴奋不已。现在Answers每天处理50亿次会话，并且这个数量在持续增加。上亿设备每秒向Answers端点发送数以百万计的请求。在你已经阅读到此处的这段时间里，Answers后台收到并处理了一千万次分析事件。

其中的挑战是如何利用这些信息向移动开发者提供可靠的、实时的、有实际价值的洞见（视角）去了解他们的移动应用。

在高层，Twitter依靠 组件解耦、异步通信、在应对灾难性故障时优雅地服务降级等原则来帮助架构决策。Twitter使用Lambda架构将数据完整性和实时数据更新结合起来。

在实践过程中，Twitter需要设计一个能够接收并保存事件、执行离线和实时计算且能将上述两种计算结果整合成相关信息的系统。这些行为全部都要以百万次每秒的规模执行。

让Twitter从第一个挑战开始：接受并处理这些事件。

事件接收

在设计设备-服务器通信的时候，Twitter的目标是：减少对电池和网络使用的影响；确保数据的可靠性；接近实时地获取数据。为了减少对设备的影响，Twitter批量地发送分析数据并且在发送前对数据进行压缩。为了保证这些宝贵的数据始终能够到达Twitter的服务器，在传输失败随机退避后以及达到设备存储达到上限时，设备会进行重传。为了确保数据能够尽快到达服务器，Twitter设置来多个触发器来使设备尝试发送：当程序运行于前台的时候，事件触发器每分钟触发一次；一个消息数量触发器和程序转入后台触发器。

这样的通信协议导致设备每秒发送来数以万计压缩过的有效载荷。每一个载荷都包含数十条事件。为了能够可靠的、易于线性伸缩的方式去处理载荷，接收事件的服务必须极度简单。

这个服务使用GO语言编写，这个服务使用了亚马逊弹性负载均衡器（ELB），并将每一个消息负荷放入一个持久化的Kafka队列。

存储

Kafka是一个持久存储器，因为它把收到的消息写入磁盘并且每个消息都有多份冗余。因此一旦Twitter知道信息到了Kafka队列，Twitter就可以通过延迟处理、再处理来容忍下游延迟和下游失败。然而，Kafka不是Twitter历史数据的永久真理之源——按照上文提到的速度，仅仅是几天的数据，Twitter也需要数以百计的box来存储。因此Twitter把Kafka集群配置为将消息只保留几个小时（这些时间足够Twitter处理不期而至的重大故障）并且将数据尽快地存入永久存储——亚马逊简易存储服务（Amazon S3）。

Twitter广泛地使用Storm来进行实时数据处理，第一个相关的Topology就是从Kafka读取信息并存储到Amazon S3上。

批量计算

一旦这些数据存到了S3上，Twitter可以使用亚马逊弹性MapReduce（Amazon EMR）来计算Twitter的数据能够计算的任何东西。这既包括要展示在客户的仪表盘上的数据，也包括Twitter为了开发新功能而开发的实验性的任务。

Twitter使用Cascading框架编写、Amazon EMR执行MapReduce程序。 Amazon EMR将Twitter存储到S3上的数据作为输入，处理完毕后，再将结果存入S3。Twitter通过运行在Storm上的调度topology来探测程序执行完毕，并将结果灌入Cassandra集群，这样结果就能用于亚秒级查询API。

实时计算

迄今，Twitter描述的是一个能够执行分析计算的持久的容错的框架。然而，存在一个显眼的问题——这个框架不是实时的。一些计算每小时计算一次，有的计算需要一整天的数据作为输入。计算时间从几分钟到几小时不等，把S3上的输出导入到服务层也需要这么多时间。因此，在最好情况下，Twitter的数据也总是拖后几个小时，显然不能满足实时和可操作的目标。

为了达成实时的目标，数据涌入后进行存档的同时，Twitter对数据进行流式计算。

就像Twitter的存储Topology读取数据一样，一个独立的Storm Topology实时地从Kafka Topic中读取数据然后进行实时计算，计算的逻辑和MapReduce任务一样。这些实时计算的结果放在另一个独立的Cassandra集群里以供实时查询。

为了弥补Twitter在时间以及在资源方面可能的不足，Twitter没有在批量处理层中而是在实时计算层中使用了一些概率算法，如布隆过滤器、HyperLogLog（也有一些自己开发的算法）。相对于那些蛮力替代品，这些算法在空间和时间复杂度上有数量级的优势，同时只有可忽略的精确度损失。

合并

现在Twitter拥有两个独立生产出的数据集（批处理和实时处理），Twitter怎么将二者合并才能得到一个一致的结果？

Twitter在API的逻辑中，根据特定的情况分别使用两个数据集然后合并它们。

因为批量计算是可重现的，且相对于实时计算来说更容错，Twitter的API总是倾向于使用批量产生的数据。例如，API接到了一个三十天的时间序列的日活跃用户数量数据请求，它首先会到批量数据Cassandra集群里查询全范围的数据。如果这是一个历史数据检索，所有的数据都已经得到。然而，查询的请求更可能会包含当天，批量产生的数据填充了大部分结果，只有近一两天的数据会被实时数据填充。

错误处理

让Twitter来温习几个失效的场景，看一下这样的架构在处理错误的时候， 是如何避免宕机或者损失数据，取之以优雅地降级。

Twitter在上文中已经讨论过设备上的回退重试策略。在设备端网络中断、服务器端短时无服务情况下，重试保证数据最终能够到达服务器。随机回退确保设备不会在某区域网络中断或者后端服务器短时间不可用之后，不会压垮（DDos攻击）服务器。

当实时处理层失效时，会发生什么？Twitter待命的工程师会受到通知并去解决问题。因为实时处理层的输入是存储在持久化的Kafka集群里，所以没有数据会丢失；等实时处理恢复之后，它会赶上处理那些停机期间应该处理的数据。

因为实时处理和批处理是完全解耦的，批处理层完全不会受到影响。因此唯一的影响就是实时处理层失效期间，对数据点实时更新的延迟。

如果批处理层有问题或者严重延迟的话，会发生什么？Twitter的API会无缝地多获取实时处理的数据。一个时间序列数据的查询，可能先前只取一天的实时处理结果，现在就需要查询两到三天的实时处理结果。因为实时处理和批处理是完全解耦的，实时处理不受影响继续运行。同时，Twitter的待命工程师会得到消息并且解决批处理层的问题。一旦批处理层恢复正常，它会执行那些延迟的数据处理任务，API也会无缝切换到使用现在可以得到的批处理的结果。

Twitter系统后端架构由四大组件构成：事件接收，事件存储，实时计算和批量计算。各个组件之间的持久化队列确保任意组件的失效不会扩散到其他组件，并且后续可以从中断中恢复。API可以在计算层延迟或者失效时无缝地优雅降级，在服务恢复后重新恢复；这些都是由API内部的检索逻辑来保证的。

Answer的目标是创建一个仪表盘，这个仪表盘能够把了解你的用户群变得非常简单。因此你可以将时间花费在打造令人惊叹的用户体验上，而不是用来掘穿数据。