# Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件
> 原文: [http://highscalability.com/blog/2011/2/8/mollom-architecture-killing-over-373-million-spams-at-100-re.html](http://highscalability.com/blog/2011/2/8/mollom-architecture-killing-over-373-million-spams-at-100-re.html)
![](https://img.kancloud.cn/61/04/61043b6f99b337a668277fddad93c6df_240x66.png) [Mollom](http://mollom.com/) 是每个开发人员在绞尽脑汁寻找可行的软件即服务创业公司时都梦 of 以求的出色的 SaaS 公司之一。 Mollom 与一小部分地理位置分散的开发人员一起以有益的方式运行有用的服务-[垃圾邮件过滤](http://www.youtube.com/watch?v=anwy2MPT5RE)。 Mollom 帮助保护了近 40,000 个网站免受垃圾邮件的侵扰,其中包括[属于我的](http://biztaxtalk.com/),这是我第一次了解 Mollom 的地方。 为了在 Drupal 网站上停止垃圾邮件的拼命尝试,在该网站上,所有其他形式的 CAPTCHA 都失败了,我在大约 10 分钟内安装了 Mollom,它立即开始工作。 那是我一直在寻找的开箱即用的体验。
从 Mollom 开放其数字检查系统开始,他们已经拒绝了超过 3.73 亿封垃圾邮件,在此过程中,他们了解到,惊人的 90%的邮件都是垃圾邮件。 该垃圾邮件洪流仅由两台地理位置分散的计算机处理,这些计算机每秒处理 100 个请求,每个计算机都运行 Java 应用程序服务器和 Cassandra。 因为它们创建了一个非常高效的机器学习系统,所以几乎不需要任何资源。 那不是很酷吗? 那么,他们怎么做呢?
为了找出答案,我采访了 Mollom 的联合创始人 Benjamin Schrauwen,以及 Glassfish 和 Java 企业专家 Johan Vos。 证明软件没有国界,Mollom HQ 位于比利时的[HTG0] (来自比利时的其他好东西: [Hercule Poirot](http://en.wikipedia.org/wiki/Hercule_Poirot) ,[巧克力](http://www.google.com/images?q=belgian+chocolate),[华夫饼](http://www.google.com/images?q=belgium+waffles) )。
## 统计
* 服务于 40,000 个活跃的网站,其中许多是非常大的客户,例如 Sony Music,Warner Brothers,Fox News 和 The Economist。 很多大品牌,有大网站,还有很多评论。
* 每天查找 1/2 百万封垃圾邮件。
* 每秒处理 100 个 API 调用。
* 垃圾邮件检查的延迟很短,大约需要 30-50 毫秒。 最慢的连接将是 500 毫秒。 延迟的第 95 个百分位数是 250 毫秒。 它确实针对速度进行了优化。
* 垃圾邮件分类效率为 99.95%。 这意味着 Mollom 不会捕获 10,000 个垃圾邮件中的 5 个。
* [Netlog](http://mollom.com/blog/netlog-using-mollom) 是欧洲的一个社交网站,在其自己的数据中心中拥有自己的 Mollom 设置。 Netlog 每天根据自定义[分类器](http://en.wikipedia.org/wiki/Learning_classifier_system)处理大约 400 万条消息,这些分类器对其数据进行了训练。
## 平台
* 两个生产服务器在两个不同的数据中心中运行以进行故障转移。
* 一台服务器在东海岸,一台在西海岸。
* 每个服务器是一个 Intel Xeon Quad 核心,2.8 GHz,16 GB RAM,4 个 300 GB 磁盘,RAID 10。
* [SoftLayer](http://www.softlayer.com/ ) -机器由 SoftLayer 托管。
* [Cassandra](http://cassandra.apache.org/) -选择 NoSQL 数据库是因为它具有出色的写入性能和跨多个数据中心进行操作的能力。
* [Glassfish](http://en.wikipedia.org/wiki/GlassFish) -用于 Java EE 平台的开源应用程序服务器。 他们选择了 Glassfish,因为它具有企业级功能,例如复制和故障转移。
* [Hudson](http://hudson-ci.org/) -可在所有服务器上进行后端的连续测试和部署。
* Java-Mollom 从一开始就是用 Java 编写的。
* [Munin](http://munin-monitoring.org/) -用于测量和绘制有关服务器运行状况的指标。
* [MySQL](http://www.mysql.com/) -JPA(Java Persistence API)用于常规数据集,而 Cassandra 用于大型数据集。
* [Pingdom](http://www.pingdom.com/) -用于正常运行时间监视。
* [Zendesk](http://www.zendesk.com/) -用于支持。
* [Drupal](http://drupal.org/) -用于具有自定义电子商务模块的主网站。
* [解除混淆](http://unfuddle.com/)-Subversion 托管由其分布式开发团队用于源代码控制。
## 什么是 Mollom?
Mollom 是一项 Web 服务,用于从用户生成的内容中过滤掉各种类型的垃圾邮件:评论,论坛帖子,博客帖子,民意调查,联系表,注册表和密码请求表。 垃圾邮件的确定不仅取决于发布的内容,还取决于张贴者的过去活动和声誉。 Mollom 的[机器学习](http://en.wikipedia.org/wiki/Machine_learning)算法充当您的 24x7 数字主持人,因此您不必这样做。
### 如何使用?
例如,诸如 Drupal 之类的应用程序使用一个模块将 Mollom 集成,该模块将自身安装到内容编辑集成点中,以便在将内容写入数据库之前可以检查其内容是否为垃圾内容。 该过程看起来像:
* 当用户向网站提交评论时,将对后端服务器进行 API 调用。
* 会对内容进行分析,如果是垃圾内容,则将告知网站阻止该内容,或者如果后端不确定,它将建议该网站显示 [CAPTCHA](http://en.wikipedia.org/wiki/CAPTCHA) ,它们也可以提供该内容。
* 正确填写验证码后,内容将被接受。 在大多数情况下,人们不会看到验证码,该内容将直接被视为*火腿*,火腿是好内容,*垃圾邮件*是坏内容。
* 仅在机器学习算法不是 100%确定的情况下才显示 CAPTCHA,因此在大多数情况下不会给人类带来不便。
### 仪表板
Mollom 的每个帐户都包含一个漂亮的[漂亮的信息中心](http://mollom.com/scorecard),它向您显示了已接受多少火腿和已拒绝多少垃圾邮件。 在图中看到的垃圾邮件数量确实令人沮丧。
### 运作流程
**安装。** 对于 Drupal 来说,安装非常容易。 像安装其他模块一样安装它。 在 Mollom 网站上创建一个帐户。 获取一对安全密钥,将这些密钥配置到模块中,然后选择要使用 Mollum 保护的系统部分。 就是这样
**每日**。 我定期检查垃圾邮件是否已经通过。 它不是 100%,因此某些垃圾邮件确实可以通过,但很少。 如果垃圾邮件确实通过了,则有一种方法可以告诉 Mollom 该帖子确实是垃圾邮件,应将其删除。 无论如何,这都是您必须要做的,但是在此过程中,您正在帮助培训 Mollom 的机器学习算法,了解什么是垃圾邮件。
**允许匿名用户交互**。 有了出色的垃圾邮件检查程序,就有可能建立一个网站,人们可以进行匿名交互,这是许多使用某些类型网站的人真正喜欢的。 一旦您要求注册,参与活动就会减少,并且注册也不会阻止垃圾邮件发送者。
### 并非一切都是玫瑰色
处理误报是 Mollom 的最大缺点。 垃圾邮件检测是拒绝火腿和接受垃圾邮件之间的困难平衡行为。 Mollom 的机器学习算法似乎运行得很好,但是有时存在一个问题,即好的帖子被拒绝,您会感到恐惧:*您的提交触发了垃圾邮件过滤器,将不被接受*。 目前没有追索权。 对于用户而言,几乎没有什么比让他们的光荣评论被垃圾邮件拒绝更令用户生气的了。 用户只会尝试几次来解决问题,然后他们只会放弃并走开。
问题是无法解决此问题。 为了保护机器学习算法不被玩耍,Mollom 不允许您提供一个示例,该示例错误地拒绝了应接受的内容块,尽管他们正在努力在将来添加它。
这是一个艰难的决定。 静态 CAPTCHA 系统,即仅要求用户通过测试即可提交内容的系统,一旦将站点定为严重攻击目标就无法正常工作。 用户注册无效。 考虑到一个站点每天可能有成千上万的垃圾邮件,对每个帖子进行审核需要非常高的负担,尤其是对于“爱好”站点。 垃圾邮件完全杀死了一个站点,因此,要平衡激怒某些用户的风险,而不要因为一个被炸毁的站点而最终没有用户。
## 商业模式
* 让 Mollom 轻松自如的是,它是免费的。 您只需在网站开始每天接受 100 多个火腿消息后付款。 对于小型站点,这可能永远不会发生。
* 一旦超过免费门槛,便有 Mollom Plus(每天 1 欧元)和 Mollom Premium(3600 欧元/年/站点)的定价层,这似乎很合理。
* 免费的网站并不会像您期望的那样浪费资源,它们实际上是重要培训数据的来源。 所有使用 Mollom 的网站都在不断将数据反馈给后端分类器。 使用 Mollom 的人越多,通过从用户那里获得的所有反馈进行培训的效果就越好。 没有免费的网站,Mollom 就不会像现在那样准确。
## 建筑
* Mollom 非常受工程驱动。 主要重点在于使 Mollom 在代码和服务器资源使用上都尽可能高效。
* 实际上,每个服务器都可以处理所有请求,但是它们具有完整的故障转移。 工作在机器之间分配。 如果其中一个发生故障,则工作移至另一台机器。
* 他们曾经有 3 台服务器,但是由于它们提高了性能,因此可以将第三台服务器用作登台服务器。
* 每个服务器每秒可以处理完整的 100 个连接,并且每个连接运行整个管道:全文分析,计算作者的信誉并提供 CAPTCHAS。
* 真正针对低延迟进行了优化。 由于垃圾邮件检测是内容提交到站点过程的一部分,因此,如果花很长时间,对用户来说真的很烦。
* 软体动物经历了几个发展阶段:
1. 最初,一个由两个人组成的小团队在做兼职,负责算法,分类器和他们试图解决的实际业务问题。 为了在后端建立基础架构,他们使用了自己的线程池,连接池,资源管理实现。 他们发现他们花了太多时间来支持所有这些东西并使其扩展。 然后他们切换到 Java 应用程序服务器 Glassfish,因此他们不必担心内存管理,REST 处理,XML 解析和数据库连接池。
2. 过去的主要问题是磁盘带宽。 他们需要跟踪 Internet 上所有 IP 地址和所有 URL 的信誉,因此这是一个庞大的数据存储,具有许多随机访问权限。
3. 早期,他们使用廉价的虚拟机,而一切都在 MySQL 中进行,但无法扩展。
4. 然后,他们将其移至固态磁盘并将所有内容存储在文件中。 固态解决了写问题,但是有一些问题:
1. 真的很贵。
2. 这对安装的文件系统类型非常敏感。
3. 写入速度很快,但是遍历数据以清理数据或在数百万个小对象上训练新的分类器仍然非常缓慢。
5. 然后他们离开了固态,搬到了卡桑德拉。
* Cassandra 现在用作写繁重负载的数据库和缓存层:
* 在 [RAID 10](http://www.thegeekstuff.com/2010/08/raid-levels-tutorial/) 磁盘配置(条带化和镜像)上运行,这对于大量读/写非常有用。
* 卡桑德拉(Cassandra)针对写入进行了优化,而 Mollom 的写入量要大于读取量。
* 设计为分布在数据中心内部和整个数据中心。
* 缺点是没有标准的 NoSQL 接口,这使得编写应用程序变得困难。
* Cassandra 的行缓存使他们不必在系统中添加另一个缓存层,从而消除了大量应用程序代码。
* Cassandra 具有老化功能,该功能会在一段时间后自动删除数据。 欧洲有严格的隐私法,要求一段时间后删除某些数据。 此功能是一个巨大的胜利。 这是一个非常昂贵的操作,Cassandra 处理它会删除很多应用程序代码。
* 博客评论通过系统的路径:
* 请求可以来自任何客户端。 客户端跨服务器负载平衡请求。 这部分将在后面说明。 典型的客户端是 Drupal 系统。 请求可以是 XML-RPC 或 REST。
* 请求由 Glassfish 应用程序服务器处理并遵循典型的应用程序服务器工作流程:请求由 servlet 处理并委托给会话 bean。
* 付费客户首先得到服务,免费客户可能会遇到更长的延迟。
* 对该请求进行解析和分析。 稍后再详细介绍。 确定垃圾邮件分数并将其返回给用户。 因此,Mollom 有不同的功能部分:垃圾邮件检查和 CAPTCHA 处理。 CAPTCHA 包括生成,提供和处理响应。 不同的会话 bean 负责 Mollom 功能的各个部分。
* 分类器完全位于 RAM 中。 一小部分内容被炸裂成数千个可以识别垃圾邮件的小令牌。 这些分类器在 RAM 中具有几百万个令牌。 分类器需要真正快速运行,因此它们必须位于 RAM 中。
* 卡桑德拉(Cassandra)中保存的是信誉分数,频率,URL 和 IP 地址。 Cassandra 的新行缓存功能现在充当其缓存层。 以前,他们实现了内部缓存,但是已将其删除。
* 两个数据中心中的两台机器都运行 Cassandra 和 Glassfish 应用程序服务器。 Cassandra 不断在数据中心之间复制数据。
* 内存中的数据结构不会直接复制。 他们写信给 Cassandra,然后复制。 另一端的缓存超时,因此它将转到 Cassandra 并获取新数据。 最终是一致的。 不一致的窗口很小,但是模型在这么短的时间内不会受到负面影响。
* 一致性是根据具体情况进行管理的。 对于信誉和 IP 地址,最终的一致性很好。 会话数据(包括 CAPTCHA 会话)保持严格一致,因此当计算机进行故障转移时,它们将正确跟踪。
* 客户端负载平衡
* Mollom 使用[客户端负载平衡](http://mollom.com/api/client-side-load-balancing),该负载平衡基于延迟等进行分配。作为一家初创公司,他们没有钱购买大型负载平衡器。 他们的另一个目标是能够对多个数据中心进行全局负载平衡,这将需要昂贵且复杂的设置。
* 客户端列表的管理通过 API 进行。 每个客户端都有其可以使用的可用服务器的列表。
* 每个客户端可以获取要使用的服务器的不同列表。 可以向付费客户提供更近的服务器列表,以减少延迟。
* 当服务器发生故障时,客户端将尝试列表中的下一个服务器。
* 客户端负载平衡有助于从旧系统迁移到新的基于 Glassfish 的系统。 将为新用户提供已迁移计算机的地址,而旧用户仍在旧计算机上工作,并且可以通过更新其服务器列表以有序方式进行迁移。 这允许进行测试,以便他们可以测试功能,然后测试伸缩性和性能。 他们查看了响应时间,连接队列中有多少个连接以及队列中将保留多长时间。 他们可以测试如果增加线程池中的线程,更改 JDBC 连接数以及其他配置会发生什么情况。 所有人迁移后,旧服务器将关闭。 过渡期间几乎没有停机时间,这对于高可用性系统至关重要。 当系统关闭时,垃圾邮件正在通过。
* 客户端方法的缺点是,如果第三方客户端的文字写得不好,就会出现问题。 例如,客户端可以获取服务器列表,并以相反的顺序对其进行迭代,这是错误的。 他们现在与客户开发人员紧密合作,并提供高质量的参考代码示例,以便开发人员可以学习最佳实践。
* 机器学习
* Mollom 是一组学习系统。 一个既不考虑用户行为也不考虑起点的 CAPTCHA 解决方案,永远无法达到这种水平的知情保护,并且通常要求用户在每个帖子上都解决 CAPTCHA 问题。 使用 Mollom 的文本分析,仅当 Mollom 不确定帖子时,用户才必须解决验证码。
* 平均消息长度约为 500 个字符,这被分解为 3,000 个功能。 通过查看 IP 地址或 Open ID 的信誉来确定帖子的混乱状态,可以查看用户 ID,情感,语言,亵渎,特定单词和单词组合,还可以查看文字的写法。 等等。所有这些都是基于分类器的。 一些分类器本质上是统计的,可以自动学习。 一些基于规则的分类器可确保它们永远不会出错。 最终,所有这些测试将决定垃圾邮件得分。
* 他们从该过程中学习,并实时更新分类器和内部指标。
* Glassfish 可处理工作计划,并旨在处理多核工作负载。
* 关键是创建一个尽可能平行的作品设计,并具有尽可能小的锁定窗口。
* 调整并发 HTTP 连接的数量,以便它们具有适当大小的可用连接池。
* 每个服务器使用 16 个线程。
* 大多数调用由无状态会话 Bean 处理,该会话状态可很好地进行并发管理。
* 他们在池中保留了多个会话 bean,但让 Glassfish 决定池中应包含多少个会话 bean。 在峰值负载下,池中将有更多会话 Bean,因此可以有效地处理请求。 任何给定时刻都可以并行运行 32 个会话 Bean。
* 所有的分类器实际上都是会话 Bean,它们被不同的线程重用。
* 每个会话 bean 都有自己的与 Cassandra 的客户端连接,因此它们不会互相阻塞。
* 当用户不响应 CAPTCHA 时,该会话将被清除,Mollom 得知这可能是垃圾邮件。
* 每个服务器的每个分类器都有一个实例。
* 会话清理的锁争用时间很短,其中正在更新分类器。
* 每 1/2 小时将更新的分类器写回到 Cassandra。
* 应用整合
* Mollom 使用开放式 API,可以将其集成到任何系统中。
* 库:Java,PHP,Ruby 等。
* 集成解决方案:Drupal,Joomla,Wordpress 和其他内容管理系统。
* 第三方根据 Mollom 产生的示例代码生成新的绑定。
* 为了监视服务器的运行状况,他们使用 Munin 进行了持续监视:
* 垃圾回收后堆的大小是多少?
* 可用连接数是多少?
* 线程池中可用的线程数是多少? 确保没有一个线程长时间等待锁。
* 当您查看他们的体系结构时,Mollom 试图构建一种可以透明地在多个数据中心内工作的体系结构,当它们已经超出单个服务器系统的规模时,它们本身可以向上扩展:
* 客户端负载平衡用于选择和故障转移服务器。
* Glassfish 群集将用于在应用程序层进行故障转移,并使添加和删除计算机变得容易。
* Cassandra 将用于跨数据中心管理数据层。
* Netlog 的 Mollom 安装具有一些有趣的特征。 它比 Mollom.com 主要服务器处理的更多,但是垃圾邮件的分布完全不同,因为他们的人员进行通信是社交网络的一部分。 Netlog 上的垃圾邮件分布为 90%的火腿和 10%的垃圾邮件,而在残酷的博客世界中,这恰恰相反。 有趣的含义是,处理火腿所需的资源较少,因此它们实际上可以在同一服务器上执行更多工作。
* 他们最初尝试使用虚拟服务器,并考虑使用 Amazon,但是他们发现 IO 是使用共享虚拟服务器的主要瓶颈。 IO 延迟和带宽是真正的问题,因此他们决定扩大规模并使用更大的计算机和更大的磁盘。
* 令人惊讶的是,它们不受 CPU 限制。 8 个内核中只有两个在计算。 其他人只是在做 IO。
* Mollom 的流量相当稳定,因此拥有专用服务器更具成本效益。 他们看到亚马逊更多地是一种处理高峰负载的方式。
* 开发过程
* 他们是分散的团队。 三个人在比利时,一个在德克萨斯州,波士顿和德国。
* Scrum 被用作开发过程,他们对此非常满意。 Scrum 会议在下午 2 点通过 Skype 进行。 他们发现随着他们的成长,他们需要更多的过程。
* 开发人员在本地进行开发,并将代码提交到 Unfuddle 中。
* Hudson 被用作他们的持续集成环境。 Hudson 使他们从旧系统到新 Glassfish 系统的迁移更加容易,因为必须在部署之前通过测试。 他们并没有浪费太多时间,因为在生产部署之前就发现了问题。
* 他们有很多测试:单元测试,系统测试,Drupal 测试。 只有当 Hudson 通过了这些测试时,才能部署系统。
* 仍然可以手动进行部署,以减少潜在的停机时间。
* 每当他们发现垃圾回收时间出现问题时,这总是归因于其应用程序中的内存泄漏。 万一发生内存泄漏,他们将进行核心转储。 要从 16GB 的计算机分析核心转储不是那么容易,您可能无法在本地计算机上对其进行分析,因此他们要做的是在 Amazon 上租用一个大内存实例来分析转储。 处理堆转储大约需要 2 个小时。 他们比较了两个转储,一个在执行时间 10 小时后,另一个在执行时间 20 小时后。 如果存在重大差异,则可能是由于内存泄漏。
## **未来方向**
* Mollom API 使用 XML-RPC,他们现在正在测试 REST 实现,以使服务更易于使用 Mollom 进行混搭。
* 现在,他们已经过渡到 Cassandra,在增长需要时,他们可以更轻松地进行横向扩展。
* 即将发布的企业功能可以将数百个网站作为一个单元进行管理。 通过情绪,垃圾邮件分数或从某些 IP 地址删除所有评论,很容易在一组网站上进行审核。
* 他们已经进行了有关进入 Twitter 等流数据业务的讨论,但受到欧洲更加严格的隐私政策的限制。
* 他们将使用 Glassfish 进行实验,以平衡每个数据中心的负载。
* 如果负载增加 10 倍,则必须添加更多的 Cassandra 节点。 磁盘 IO 是瓶颈。 仅当它们的增长速度必须超过 10 倍时,才需要添加更多的应用程序服务器。
## 经验教训 [
* ****效率带来幸福。** Mollom 非常重视高性能工程。 他们为 Mollom 极具成本效益而感到自豪。 它可以在一台服务器上处理许多请求,而延迟时间很短,这使客户感到满意,这使他们感到满意,因为他们不必维护大量机器,而且成本很低。 他们从一开始就将其作为优先事项,并选择了正确的技术来实现其目标。 这样一来,他们就可以利用自己赚的钱,在营销,建立用户群以及在 Mollom 之上开发新产品方面进行投资。**
* **广度免费,付出深度**。 机器学习需要大量示例数据才能成功检测到垃圾邮件。 为了获得这些数据,Mollom 为客户提供了免费的服务,他们提供了更好地训练学习算法所需的广泛数据,他们是不断提供情报和反馈的来源。 较大的客户不仅提供收入,而且还可以从免费客户那里学到的数据受益。 该模型似乎是大数据和机器学习所特有的,众所周知,这是一切的未来。
* **移除非特定领域的障碍物**。 大型系统需要大量基础架构工作。 基础架构的工作通常使工作不再涉及与产品的真正价值产生领域相关的功能(分类器,信誉系统,客户端库)。 Mollom 有意识地尝试通过选择 Cassandra 和 Glassfish 来尽可能地摆脱基础设施业务。
* **注意客户端代码**。 客户端代码很有吸引力,因为它使用别人的资源而不是您的资源。 问题在于代码编写得不好,这会使您的系统看起来很糟糕。 与客户开发人员紧密合作,并提供高质量的参考代码示例,以便开发人员可以学习最佳实践。
* **优先考虑付费客户**。 付费客户可以获得更好的服务质量。 它们首先在队列中处理,并且减少了整个系统的延迟。 付费客户可以访问故障转移服务器,而免费客户只能使用一台服务器。
* **通过让堆栈进行繁重的操作**来减少代码。 在早期,Mollom 代码库比现在大得多。 Cassandra 通过处理复制和行缓存删除了许多复杂的代码,Glassfish 删除了许多应用程序代码,并将处理集群。 随着时间的推移而简化。
* **最小化锁争用**。 Mollom 花了很多时间来减少 Glassfish 服务器中的锁争用,因为这已成为主要瓶颈。 尽可能少地锁定即可保持完全的并行性。
## 相关文章
* [Mollom API](http://mollom.com/api)
* [Mollom Drupal 模块](http://drupal.org/project/mollom)
* [Mollom 技术白皮书](http://mollom.com/files/mollom-technical-whitepaper.pdf)
* [Mollom 的 Twitter 帐户](http://twitter.com/#!/mollom)
* [第 072 集-Mollom.com 的 GlassFish 后端,带有 Dries 和 Johan](http://blogs.sun.com/glassfishpodcast/entry/episode_072_mollom_com_s)
* [Mollom 获得了一个新的后端](http://buytaert.net/mollom-gets-a-new-backend)
* [在 Glassfish 上用 Mollom 打击垃圾邮件](http://blogs.lodgon.com/johan/)
* 要了解有关大数据和机器学习的更多信息,请查看 [Strata Conference](http://strataconf.com/strata2011/public/schedule/proceedings) 中的一些资料。
好帖子!
我想念什么吗? 100 rps 令人印象深刻吗?
托德
首先,我是该网站的忠实拥护者,我会定期关注您的帖子。
我喜欢这篇文章,但是每秒的请求引起了我的注意。 我很好奇您认为“高吞吐量”服务。 我问是因为我是 Proxomo 的首席软件架构师(http://www.proxomo.com)。 我们的负载测试已在两台服务器(在 Microsoft Azure 上运行)上以每秒超过 500 个请求的速度为 REST 服务提供时钟。
谢谢
Daniel .....
丹尼尔,您好,如果您想谈谈您的架构,请给我发电子邮件。 关于您的问题,我认为没有任何特定的阈值定义“高吞吐量服务”。 Mollom 给我留下了深刻的印象,因为它们有一个复杂的机器学习应用程序,可以在一台(大型)机器上运行,它们遵循严格的质量和性能指标,它们是可盈利的,并且它们以正确的方式做事。 有很多人在创建应用程序,不是每个人都是 Google,所以我真的很喜欢这些提供真正价值的更人性化服务的示例。
垃圾邮件取决于上下文。 如果我经营一个科技网站,那么政治评论就是垃圾邮件。 如果我经营一个政治网站,那么技术评论就是垃圾邮件。 如果使用“从用户那里获得的所有反馈”对 Mollom 进行培训,如何避免出现问题?
如何将其整合到 Drupal 中???
- LiveJournal 体系结构
- mixi.jp 体系结构
- 友谊建筑
- FeedBurner 体系结构
- GoogleTalk 架构
- ThemBid 架构
- 使用 Amazon 服务以 100 美元的价格构建无限可扩展的基础架构
- TypePad 建筑
- 维基媒体架构
- Joost 网络架构
- 亚马逊建筑
- Fotolog 扩展成功的秘诀
- 普恩斯的教训-早期
- 论文:Wikipedia 的站点内部,配置,代码示例和管理问题
- 扩大早期创业规模
- Feedblendr 架构-使用 EC2 进行扩展
- Slashdot Architecture-互联网的老人如何学会扩展
- Flickr 架构
- Tailrank 架构-了解如何在整个徽标范围内跟踪模因
- Ruby on Rails 如何在 550k 网页浏览中幸存
- Mailinator 架构
- Rackspace 现在如何使用 MapReduce 和 Hadoop 查询 TB 的数据
- Yandex 架构
- YouTube 架构
- Skype 计划 PostgreSQL 扩展到 10 亿用户
- 易趣建筑
- FaceStat 的祸根与智慧赢得了胜利
- Flickr 的联合会:每天进行数十亿次查询
- EVE 在线架构
- Notify.me 体系结构-同步性
- Google 架构
- 第二人生架构-网格
- MySpace 体系结构
- 扩展 Digg 和其他 Web 应用程序
- Digg 建筑
- 在 Amazon EC2 中部署大规模基础架构的六个经验教训
- Wolfram | Alpha 建筑
- 为什么 Facebook,Digg 和 Twitter 很难扩展?
- 全球范围扩展的 10 个 eBay 秘密
- BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展
- 《 FarmVille》如何扩展以每月收获 7500 万玩家
- Twitter 计划分析 1000 亿条推文
- MySpace 如何与 100 万个并发用户一起测试其实时站点
- FarmVille 如何扩展-后续
- Justin.tv 的实时视频广播架构
- 策略:缓存 404 在服务器时间上节省了洋葱 66%
- Poppen.de 建筑
- MocoSpace Architecture-一个月有 30 亿个移动页面浏览量
- Sify.com 体系结构-每秒 3900 个请求的门户
- 每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训
- Playfish 的社交游戏架构-每月有 5000 万用户并且不断增长
- 扩展 BBC iPlayer 的 6 种策略
- Facebook 的新实时消息系统:HBase 每月可存储 135 亿条消息
- Pinboard.in Architecture-付费玩以保持系统小巧
- BankSimple 迷你架构-使用下一代工具链
- Riak 的 Bitcask-用于快速键/值数据的日志结构哈希表
- Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件
- Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求
- Node.js 成为堆栈的一部分了吗? SimpleGeo 说是的。
- 堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量
- Medialets 体系结构-击败艰巨的移动设备数据
- Facebook 的新实时分析系统:HBase 每天处理 200 亿个事件
- Microsoft Stack 是否杀死了 MySpace?
- Viddler Architecture-每天嵌入 700 万个和 1500 Req / Sec 高峰
- Facebook:用于扩展数十亿条消息的示例规范架构
- Evernote Architecture-每天有 900 万用户和 1.5 亿个请求
- TripAdvisor 的短
- TripAdvisor 架构-4,000 万访客,200M 动态页面浏览,30TB 数据
- ATMCash 利用虚拟化实现安全性-不变性和还原
- Google+是使用您也可以使用的工具构建的:闭包,Java Servlet,JavaScript,BigTable,Colossus,快速周转
- 新的文物建筑-每天收集 20 亿多个指标
- Peecho Architecture-鞋带上的可扩展性
- 标记式架构-扩展到 1 亿用户,1000 台服务器和 50 亿个页面视图
- 论文:Akamai 网络-70 个国家/地区的 61,000 台服务器,1,000 个网络
- 策略:在 S3 或 GitHub 上运行可扩展,可用且廉价的静态站点
- Pud 是反堆栈-Windows,CFML,Dropbox,Xeround,JungleDisk,ELB
- 用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术
- StackExchange 体系结构更新-平稳运行,Amazon 4x 更昂贵
- DataSift 体系结构:每秒进行 120,000 条推文的实时数据挖掘
- Instagram 架构:1400 万用户,1 TB 的照片,数百个实例,数十种技术
- PlentyOfFish 更新-每月 60 亿次浏览量和 320 亿张图片
- Etsy Saga:从筒仓到开心到一个月的浏览量达到数十亿
- 数据范围项目-6PB 存储,500GBytes / sec 顺序 IO,20M IOPS,130TFlops
- 99designs 的设计-数以千万计的综合浏览量
- Tumblr Architecture-150 亿页面浏览量一个月,比 Twitter 更难扩展
- Berkeley DB 体系结构-NoSQL 很酷之前的 NoSQL
- Pixable Architecture-每天对 2000 万张照片进行爬网,分析和排名
- LinkedIn:使用 Databus 创建低延迟更改数据捕获系统
- 在 30 分钟内进行 7 年的 YouTube 可扩展性课程
- YouPorn-每天定位 2 亿次观看
- Instagram 架构更新:Instagram 有何新功能?
- 搜索技术剖析:blekko 的 NoSQL 数据库
- Pinterest 体系结构更新-1800 万访问者,增长 10 倍,拥有 12 名员工,410 TB 数据
- 搜索技术剖析:使用组合器爬行
- iDoneThis-从头开始扩展基于电子邮件的应用程序
- StubHub 体系结构:全球最大的票务市场背后的惊人复杂性
- FictionPress:在网络上发布 600 万本小说
- Cinchcast 体系结构-每天产生 1,500 小时的音频
- 棱柱架构-使用社交网络上的机器学习来弄清您应该在网络上阅读的内容
- 棱镜更新:基于文档和用户的机器学习
- Zoosk-实时通信背后的工程
- WordPress.com 使用 NGINX 服务 70,000 req / sec 和超过 15 Gbit / sec 的流量
- 史诗般的 TripAdvisor 更新:为什么不在云上运行? 盛大的实验
- UltraDNS 如何处理数十万个区域和数千万条记录
- 更简单,更便宜,更快:Playtomic 从.NET 迁移到 Node 和 Heroku
- Spanner-关于程序员使用 NoSQL 规模的 SQL 语义构建应用程序
- BigData 使用 Erlang,C 和 Lisp 对抗移动数据海啸
- 分析数十亿笔信用卡交易并在云中提供低延迟的见解
- MongoDB 和 GridFS 用于内部和内部数据中心数据复制
- 每天处理 1 亿个像素-少量竞争会导致大规模问题
- DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长
- SongPop 在 GAE 上可扩展至 100 万活跃用户,表明 PaaS 未通过
- Iron.io 从 Ruby 迁移到 Go:减少了 28 台服务器并避免了巨大的 Clusterf ** ks
- 可汗学院支票簿每月在 GAE 上扩展至 600 万用户
- 在破坏之前先检查自己-鳄梨的建筑演进的 5 个早期阶段
- 缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量
- Facebook 的网络秘密
- 神话:埃里克·布鲁尔(Eric Brewer)谈银行为什么不是碱-可用性就是收入
- 一千万个并发连接的秘密-内核是问题,而不是解决方案
- GOV.UK-不是你父亲的书库
- 缩放邮箱-在 6 周内从 0 到 100 万用户,每天 1 亿条消息
- 在 Yelp 上利用云计算-每月访问量为 1.02 亿,评论量为 3900 万
- 每台服务器将 PHP 扩展到 30,000 个并发用户的 5 条 Rockin'Tips
- Twitter 的架构用于在 5 秒内处理 1.5 亿活跃用户,300K QPS,22 MB / S Firehose 以及发送推文
- Salesforce Architecture-他们每天如何处理 13 亿笔交易
- 扩大流量的设计决策
- ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行
- 如何制作无限可扩展的关系数据库管理系统(RDBMS)
- Bazaarvoice 的架构每月发展到 500M 唯一用户
- HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息
- NYTimes 架构:无头,无主控,无单点故障
- 接下来的大型声音如何使用 Hadoop 数据版本控制系统跟踪万亿首歌曲的播放,喜欢和更多内容
- Google 如何备份 Internet 和数十亿字节的其他数据
- 从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧
- AOL.com 体系结构如何发展到 99.999%的可用性,每天 800 万的访问者和每秒 200,000 个请求
- Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构
- 使用 AWS,Scala,Akka,Play,MongoDB 和 Elasticsearch 构建社交音乐服务
- 大,小,热还是冷-条带,Tapad,Etsy 和 Square 的健壮数据管道示例
- WhatsApp 如何每秒吸引近 5 亿用户,11,000 内核和 7,000 万条消息
- Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延迟进行实时处理
- 关于 Disqus 的更新:它仍然是实时的,但是 Go 摧毁了 Python
- 关于 Wayback 机器如何在银河系中存储比明星更多的页面的简短说明
- 在 PagerDuty 迁移到 EC2 中的 XtraDB 群集
- 扩展世界杯-Gambify 如何与 2 人组成的团队一起运行大型移动投注应用程序
- 一点点:建立一个可处理每月 60 亿次点击的分布式系统的经验教训
- StackOverflow 更新:一个月有 5.6 亿次网页浏览,25 台服务器,而这一切都与性能有关
- Tumblr:哈希处理每秒 23,000 个博客请求的方式
- 使用 HAProxy,PHP,Redis 和 MySQL 处理 10 亿个请求的简便方法来构建成长型启动架构
- MixRadio 体系结构-兼顾各种服务
- Twitter 如何使用 Redis 进行扩展-105TB RAM,39MM QPS,10,000 多个实例
- 正确处理事情:通过即时重放查看集中式系统与分散式系统
- Instagram 提高了其应用程序的性能。 这是如何做。
- Clay.io 如何使用 AWS,Docker,HAProxy 和 Lots 建立其 10 倍架构
- 英雄联盟如何将聊天扩大到 7000 万玩家-需要很多小兵。
- Wix 的 Nifty Architecture 技巧-大规模构建发布平台
- Aeron:我们真的需要另一个消息传递系统吗?
- 机器:惠普基于忆阻器的新型数据中心规模计算机-一切仍在变化
- AWS 的惊人规模及其对云的未来意味着什么
- Vinted 体系结构:每天部署数百次,以保持繁忙的门户稳定
- 将 Kim Kardashian 扩展到 1 亿个页面
- HappyPancake:建立简单可扩展基金会的回顾
- 阿尔及利亚分布式搜索网络的体系结构
- AppLovin:通过每天处理 300 亿个请求向全球移动消费者进行营销
- Swiftype 如何以及为何从 EC2 迁移到真实硬件
- 我们如何扩展 VividCortex 的后端系统
- Appknox 架构-从 AWS 切换到 Google Cloud
- 阿尔及利亚通往全球 API 的愤怒之路
- 阿尔及利亚通往全球 API 步骤的愤怒之路第 2 部分
- 为社交产品设计后端
- 阿尔及利亚通往全球 API 第 3 部分的愤怒之路
- Google 如何创造只有他们才能创造的惊人的数据中心网络
- Autodesk 如何在 Mesos 上实施可扩展事件
- 构建全球分布式,关键任务应用程序:Trenches 部分的经验教训 1
- 构建全球分布式,关键任务应用程序:Trenches 第 2 部分的经验教训
- 需要物联网吗? 这是美国一家主要公用事业公司从 550 万米以上收集电力数据的方式
- Uber 如何扩展其实时市场平台
- 优步变得非常规:使用司机电话作为备份数据中心
- 在不到五分钟的时间里,Facebook 如何告诉您的朋友您在灾难中很安全
- Zappos 的网站与 Amazon 集成后冻结了两年
- 为在现代时代构建可扩展的有状态服务提供依据
- 细分:使用 Docker,ECS 和 Terraform 重建基础架构
- 十年 IT 失败的五个教训
- Shopify 如何扩展以处理来自 Kanye West 和 Superbowl 的 Flash 销售
- 整个 Netflix 堆栈的 360 度视图
- Wistia 如何每小时处理数百万个请求并处理丰富的视频分析
- Google 和 eBay 关于构建微服务生态系统的深刻教训
- 无服务器启动-服务器崩溃!
- 在 Amazon AWS 上扩展至 1100 万以上用户的入门指南
- 为 David Guetta 建立无限可扩展的在线录制活动
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿个通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训
- 缩放原理
- TripleLift 如何建立 Adtech 数据管道每天处理数十亿个事件
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿条通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训