【51CTO 2月15日外电头条】编者按：每一个网站的维护人员多少都被垃圾信息困扰。本文介绍的这个垃圾信息过滤系统只是众多可以选择的方案之一，但是观察这个系统的架设与成长的过程无疑会对大家有所启发。本文是HighScalability网站的作者Todd Hoff写的一篇垃圾信息过滤系统的介绍文章，原文标题为“Mollom架构：以每秒处理100个请求的速度查杀3730万条垃圾信息”，内容主要围绕系统的技术设计。当然，根据Todd的说法，100rps并不是Mollom吸引他的地方（这并不是一个高的惊人的数字），Mollom的吸引力在于它的智能学习能力，提供针对“人”的服务。下面为正文：
每个开发人员在绞尽脑汁寻找一家切实可行的SaaS新兴公司，而Mollom正是他们梦想创办的其中一家很酷的SaaS公司。Mollom的盈利方式依赖于一项实用的服务：垃圾信息过滤，而一小批开发人员分散在不同地方。Mollom有助于保护近40000个网站远离垃圾信息，包括本人的一个网站，我也因此有机会初次了解Mollom。为了竭力阻止垃圾信息出现在我的一个Drupal网站上（不管使用怎样的验证码，结果都无济于事），我花了约10分钟安装好Mollom，它立即开始发挥功效。这正是我所寻求的即可即用的体验。
自从Mollom打开其数字检查系统以来，它就拒绝了3730万条以上的垃圾信息；在这个过程中，它也明白了多达90%的信息是垃圾信息。处理这么多垃圾信息的只有两台机器，分布在不同地方，它们每秒可处理100个请求；都运行Java应用服务器和Cassandra系统。所需要的资源极少，因为Mollom建立了一套非常高效的学习系统。这不是很酷吗？那么，Mollom是如何做到的呢？
为了一探究竟，我采访了Mollom的创办人之一Benjamin Schrauwen以及Glassfish和Java Enterprise方面的专家Johan Vos。Mollom的总部位于比利时（比利时还有其他好东西：大侦探波洛、巧克力和华夫饼），这证明了软件不分国界的道理。
统计数字
◆Mollom服务于40000个活跃网站，其中许多是大客户，比如索尼音乐公司、华纳兄弟、福克斯新闻网和《经济学家》杂志社。有许多大品牌，有许多大网站，还有许多评论。
◆每天查出50万条垃圾信息。
◆每秒处理100个应用编程接口（API）调用。
◆垃圾信息检查方面的延迟很低，用时在30至50毫秒。最慢的连接用时500毫秒。5%以下的延迟是250毫秒。它确实为了提高速度进行了优化。
◆垃圾信息的分类效率高达99.95%。这意味着，在10000条垃圾信息中只有5条没有被Mollom发现。
◆欧洲的社交网站Netlog在其数据中心实施了自己的Mollom系统。Netlog每天处理约400万条信息，所用的自定义分类器经受数据方面的训练。
平台
◆两台生产服务器在两个不同的数据中心运行，确保故障切换。
◆一台服务器放在美国东海岸，另一台放在西海岸。
◆每台服务器配备英特尔至强四核2.8GHz处理器、16GB内存和4只采用RAID 10配置的300 GB硬盘。
◆SoftLayer—机器由SoftLayer托管。
◆Cassandra—选择了NoSQL数据库，原因是写入性能高，还能够跨多个数据中心来操作。
◆Glassfish—面向Java EE平台的开源应用服务器。Mollom选择Glassfish的理由是，它具有企业就绪功能，比如复制和故障切换。
◆Hudson—提供了跨所有服务器，不断测试和部署后端系统的功能。
◆Java—Mollom一开始就是用Java编写而成的。
◆Munin—用于测量和描绘关于服务器运行状况的度量标准。
◆MySQL—JPA（Java持久性API）用于普通的数据集，Cassandra则用于庞大的数据集。
◆Pingdom—用于监测正常运行时间。
◆Zendesk—用于支持。
◆Drupal—用于使用自定义电子商务模块的主网站。
◆Unfuddle—分布式开发团队使用Subversion托管来控制源代码。
Mollom是什么？
Mollom是一项Web服务，用于将各种类型的垃圾信息从用户生成的内容中过滤掉，这些内容包括：评论留言、论坛帖子、博客帖子、民意调查、联系表单、登记表单和密码请求表单。确定垃圾信息的依据不仅仅有所发的内容，还有发帖者过去的行为和信誉。Mollom的机器学习算法为你充当24 x 7不间断的数字版主，所以你不必操心。
Mollom是怎么使用的？
比如说，Drupal等应用程序使用模块（Module）来整合Mollom；模块可以将自己安装到内容编辑集成点上，那样可以在内容写到数据库之前，先检查内容里面有没有垃圾信息。这个过程就像这样：
◆用户将评论提交到网站上后，对后端服务器进行API调用。
◆内容经过分析；如果是垃圾信息，就会告知网站阻止内容；或者如果后端服务器不确信，它会建议网站显示验证码，后端服务器同时会提供验证码。
◆验证码正确填写后，内容将得到接受。在大多数情况下，人是看不到验证码的，内容将直接作为非垃圾信息的正常信息（ham）而被接受。ham是好的内容，而垃圾信息是不好的内容。
◆只有机器学习算法不是百分之百确信的情况下，才会显示验证码；所以通常来说，不会给人带来不便。
仪表板
Mollom为每个帐户包含了相当简洁的仪表板，可以显示你有多少非垃圾信息的正常信息已被接受，有多少垃圾信息已被拒绝。你在图表中看到的垃圾信息数量之多确实很令人沮丧。
操作过程
◆安装。对于Drupal来说，安装很容易。可以把它当作其他任何模块那样来安装。先在Mollom网站上设一个帐户。获得一对安全密钥，把这些密钥配置到该模块中，然后选择你想用Mollum来保护系统中的哪些部分。就是这样。
◆日常操作。我定期检查，看看垃圾信息有没有进入。无法做到百分之百有把握，一些垃圾信息还是会进入，但数量很少。要是垃圾信息的确进入，就要有办法告诉Mollom：这个帖子其实是垃圾信息；应予以删除。这是你无论如何要做的工作，但这个过程其实在帮助训练Mollom的机器学习算法，明白什么是垃圾信息。
◆允许匿名用户交互。借助良好的垃圾信息检查工具，就有可能做到人们在网站上，能够以匿名方式进行交互，使用某几类网站的许多人其实很喜欢这样。一旦你需要注册，用户的参与热情就会大大减低，注册无论如何也阻止不了垃圾信息发送者。
不是一切看上去都很美
处理误报是Mollom最大的弱项。检测垃圾信息是一项高难度的平衡艺术，需要在拒绝非垃圾信息的正常信息与接受垃圾信息之间掌握好度。Mollom的机器学习算法效果似乎相当好，但存在一个问题，那就是有时好的帖子被拒绝：你提交的内容触发了垃圾信息过滤器，不会被接受。目前没有什么好的办法。分明是好好的评论，却被误作垃圾信息而被拒绝，没有比这更让人恼火的了。用户只好尝试几次避开这个问题，但结果只好放弃、败兴而归。
问题是，没有办法解决这个问题。为了保护机器学习算法以防被人操纵，Mollom不允许你提供一段示例性的应该被接受、却误被拒绝的内容，不过他们正致力于在将来增添这项功能。
这是个艰难的决定。一旦网站遭到了严重攻击，静态验证码系统根本不管用；静态验证码系统是指只要求用户通过一次测试即可提交内容的系统。用户注册不管用。考虑到一个网站每天可能会有成千上万条电子信息，审查每个帖子会面临非常重的负担，对于“业余爱好”网站来说尤为如此。而垃圾信息会完全要了网站的命，所以要在有可能激怒一些用户与由于网站被垃圾信息挤爆，到头来没有一个用户之间掌握好度。
经营模式
◆让Mollom成为不二选择的秘诀就是它免费试用。只有一旦你的网站每天接受的非垃圾信息的正常信息开始超过100条，才需要付费。对于小型网站来说，这种可能根本不会出现。
◆一旦你需要付费，可以选择Mollom Plus（每天1欧元）和Mollom Premium（每个网站每年3600欧元）这两个价位，价位似乎很合理。
◆免费网站并不像你想象的那样很耗费资源，其实它们提供了有助于训练算法的关键数据。所有使用Mollom的网站不断地将数据反馈给后端的分类器。使用Mollom的人越多，通过从用户处得到的所有反馈训练算法的效果就越好。要是没有免费网站，Mollom的准确性不会像现在这么高。
架构
◆Mollom非常注重技术设计。Mollom过去很重视在代码和服务器资源使用方面尽可能高效。
◆实际上，每台服务器都能处理所有请求，但它们都有完整的故障切换机制。工作负载在多台机器之间分配。如果一台机器出了故障，那么工作负载会转移到另一台机器上。
◆Mollom过去有三台服务器，但由于大大提升了性能，所以可以将第三台服务器用作登台服务器（staging server）。
◆每台服务器每秒能够处理整整100个连接，每个连接执行整个流程：全文本分析、计算作者的信誉以及提供验证码。
◆真正为低延迟进行了优化。由于垃圾信息检测是内容提交到网站的整个过程的一部分，要是检测所花时间很长，用户会觉得很烦人。
◆Mollom经历了几个发展阶段：
1、最初，只有两个人的小团队业余时间开发算法、分类器以及Mollom要解决的真正的商业问题。为了扩建后端系统上的基础架构，他们实施了自己开发的线程池、连接池和资源管理机制。他们发现，用于支持这一切、确保可以扩展的时间太多了。随后他们改用Glassfish这种Java应用服务器，那样他们基本上不用太担心内存管理、REST处理、XML解析和数据库连接池。
2、过去的主要问题是磁盘带宽。Mollom需要跟踪互联网上所有IP地址和所有URL的信誉，所以这是一个随机访问频繁的庞大数据存储区。
3、在早期日子，Mollom使用廉价的虚拟机，一切都放在无法进行扩展的MySQL中。
4、随后，Mollom又改用固态磁盘，把一切存储在文件中。固态磁盘解决了写入问题，但存在这些问题：
◆价格很昂贵。
◆对于所安装的文件系统的类型非常敏感。
◆写入速度快，但是对数据进行迭代处理（经常需要这么做），以便清理数据，或者通过成千上万个小对象来训练新的分类器，这个过程的速度还是相当慢。
5、随后，Mollom由固态磁盘改用Cassandra。
◆Cassandra现用作写入密集型工作负载的数据库，并用作一个缓存层：
◆运行在RAID 10磁盘配置上（经条带化和镜像处理），非常适合于密集的读/写操作。
◆Cassandra针对写操作进行了优化，Mollom面临的写操作比读操作多得多。
◆被设计成可以在数据中心里面分布，也可以跨数据中心分布。
◆一个缺点是没有标准的NoSQL接口，因而很难编写应用程序。
◆Cassandra的行缓存（row caching）让Mollom不必往系统中添加另一个缓存层，这消除了好多的应用程序代码。
◆Cassandra拥有老化功能：经过一段时间后，会自动删除数据。欧洲订有严格的隐私法，要求某些数据在一段时间后必须予以清除。这项功能因而大受欢迎。这是一项成本极其高昂的操作；Cassandra可以处理这项工作，消除了好多的应用程序代码。
◆博客评论在整个系统中的路径如下：
◆请求可能来自任何客户端。客户端跨服务器对请求进行负载均衡处理。这部分稍后解释。典型的客户端是Drupal系统。请求可能是XML-RPC请求或REST请求。
◆请求由GlassFish应用服务器来处理，遵循典型的应用服务器工作流程：请求由服务器小程序来处理，并委托给会话组件（session bean）。
◆付费客户优先得到服务，免费客户遇到的延迟可能比较长。
◆请求经过解析和分析；后面详细介绍这一点。垃圾信息分数确定后，返回给用户。所以，Mollom有不同的功能部分：垃圾信息检查和验证码处理。验证码包括：生成、提供和处理响应。不同的会话组件负责Mollom功能的不同部分。
◆分类器完全在内存中。一小块内容被拆开来，分成了成千上万个可识别垃圾信息的小标记（token）。这些分类器在内存中大约有几百万个标记。分类器需要高速运行，所以它们必须在内存中。
◆Cassandra里面保存的是信誉分数、频率、URL和IP地址。Cassandra新的行缓存功能现在充当其缓存层。以前Mollom实施了内部缓存，但现在内存缓存被拿掉了。
◆两个数据中心中的两台机器都运行Cassandra和Glassfish应用服务器。Cassandra在数据中心之间不断数据。
◆内存中的数据结构并不直接复制。它们写入到Cassandra，再由Cassandra来复制。另一端的缓存有超时机制，所以它会访问Cassandra，获取新的数据。内容最终是一致的。有一小段时间会出现不一致，但是在这么短的时间里，数据模型并未受到负面影响。
◆视具体情况来管理一致性。对于信誉和IP地址来说，最终一致性很好。包括验证码会话的会话数据严格做到完全一致，那样机器进行故障切换时，数据会正确迁移过去。
◆客户端负载均衡
◆Mollom使用的客户端负载均衡基于延迟等标准来分配负载。作为一家新兴公司，Mollom没有钱来买大型负载均衡工具。他们还有一个目标：能够在多个数据中心之间进行全局负载均衡，这就需要安装一套昂贵又复杂的系统。
◆客户列表通过API来进行管理。每个客户都有一份服务器列表，列出了可以使用的服务器。
◆每个客户可以使用不同的服务器。为付费客户提供了位置更近的服务器，以缩短延迟。
◆当一台服务器发生故障时，客户会尝试连接列表中的下一台服务器。
◆客户端负载均衡有助于从旧系统迁移到基于Glassfish的新系统。新用户获得了迁移后的机器的地址，老用户仍在旧机器上工作，只要更新服务器列表，就可以有条不紊地迁移过去。这就允许进行测试，那样用户就可以测试功能，然后测试扩展性和性能。他们观察响应时间、连接队列中有多少个连接，以及连接在队列中停留多长时间。他们可以测试：如果增加线程池中的线程、改变JDBC连接的数量以及其他配置，会出现什么样的情况。一旦每个人都迁移完毕，旧服务器就被关闭。迁移过程中遇到的停机时间极短，这对于高可用性的系统来说很关键。系统停运期间，垃圾信息还是在进来。
◆客户端方法的一个缺点是，要是第三方客户软件编得很差，就会有问题。比如说，客户获得服务器列表后，可能以相反的顺序对列表进行迭代处理，这其实是不对的。现在Mollom与客户的开发人员紧密合作，提供优质的参考代码示例，那样开发人员可以学习最佳实践。
机器学习
◆Mollom是一套学习系统。一个独立的验证码解决方案既不考虑用户的行为，也不考虑信息源自何处，是根本无法获得这种保护级别的，通常需要用户解答每个帖子的验证码。而使用Mollom的文本分析功能，用户只要在Mollom对帖子不确信时解答验证码就行。
◆信息的平均长度是大约500个字符，每一条信息被分解成了3000个特征。信息是不是垃圾信息，只要看看IP地址或Open ID的信誉就能确定。Mollom会查看用户ID、情感、语言、亵渎语言、特定的词语和词语组合，还会查看文本写得多合乎文法，等等。这一切都基于分类器。一些分类器本身就具有统计功能，所以能够自动学习。一些分类器基于规则，可确保根本不会出错。到头来，确定垃圾信息分数的是所有这些测试的组合。
◆Mollom从这个过程中不断学习，分类器和内部度量标准实时更新。
◆Glassfish负责工作调度，旨在可以处理多核工作负载。
◆关键是设计出一种框架，以便并行处理尽可能多的工作，确保锁定窗口尽可能小。
◆并发HTTP连接的数量经过了调整，以便拥有大小合适的可用连接池。
◆每台服务器使用16个线程。
◆大多数调用由无状态会话组件来处理，无状态会话组件很适合并发管理。
◆Mollom把许多会话组件保留在池中，但是让Glassfish来决定池中应该有多少会话组件。在峰值负载下，池中会有更多的会话组件，以便高效地处理请求。在任何一个既定的时间，32个会话组件可以并行运行。
◆所有分类器实际上是不同线程重复使用的会话组件。
◆每个会话组件都有自己的客户端连接至Cassandra，所以它们不会彼此阻塞。
◆当用户没有响应验证码时，该会话被清理，Mollom就明白这可能是垃圾信息。
◆存在每台服务器一个分类器的情况。
◆会话清理方面存在一个很短的锁定争用期间，此时分类器被更新。
◆更新后的分类器每半小时被写回到Cassandra。
应用程序集成
◆Mollom使用开放的API，可以集成到任何系统中。
◆库：Java、PHP、Ruby及更多库。
◆集成的解决方案：Drupal、Joomla、WordPress及其他内容管理系统。
◆第三方基于Mollom创建的示例代码，生成新的绑定。
◆要监测服务器的运行状况，Mollom使用Munin来不断监测：
◆废料收集后堆的大小有多大？
◆可用连接的数量有多少？
◆线程池中可用线程的数量有多少？确保没有一个线程在等待很长的时间以至于造成锁定。
◆如果你看一下Mollom的架构，就会发现Mollom在努力建立一种可以跨多个数据中心透明地运行的架构，以便在单一服务器系统无法满足发展需要时，能够向外扩展：
◆客户端负载均衡用于选择和故障切换服务器。
◆Glassfish集群将用于应用层的故障切换，并且便于添加和移除机器。
◆Cassandra将用于跨数据中心来管理数据层。
◆Netlog安装的Mollom具有值得关注的一些特点。它处理的不仅仅是Mollom.com主服务器，但垃圾信息的分布是完全不同的，因为人与人的沟通是社交网络的一部分。在Netlog上垃圾信息的分布如下：90%是非垃圾信息的正常信息，10%是垃圾信息，而博客界的实际情况恰好与之相反。值得关注的是，处理非垃圾信息的正常信息所用的资源比较少，所以实际上可以在同样的服务器上处理更多的工作。
◆Netlog最初试过虚拟服务器，还想到了利用亚马逊的服务，但后来发现，输入/输出是使用共享式的虚拟服务器存在的主要瓶颈。输入/输出延迟和带宽是重大问题，于是Netlog决定向上扩展，使用更大型的机器和更大容量的硬盘。
◆令人惊讶的是，它们不受处理器的约束。8个处理器核心中只有两个负责计算；其余几个核心完全负责输入/输出。
◆Mollom的流量相当稳定，所以使用专用服务器更具成本效益。亚马逊服务主要是用来处理峰值负载。
发展过程
◆Mollom是分布式团队。三个人在比利时，另几个人在得克萨斯州、波士顿和德国。
◆Scrum用作开发方法，Mollom的人员对它觉得非常满意。下午两点通过Skype召开Scrum会议。他们发现，随着自身规模不断变大，需要更多的开发方法。
◆开发人员在本地开发，然后将代码提交到Unfuddle。
◆Hudson用作Mollom的持续集成环境。Hudson让Mollom更容易从旧的Glassfish系统迁移到新的Glassfish系统，因为只有先通过测试，才可以部署。Mollom没有损失太多的时间，因为在部署到生产环境之前就可以发现问题。
◆Mollom有很多测试：单元测试、系统测试和Drupal测试。只有Hudson通过这些测试，才可以部署系统。
◆部署仍是手动进行，以缩短潜在的停机时间。
◆每当Mollom发现废料收集时间存在问题，总是归因于应用程序存在内存泄漏。若出现内存泄漏的情况，Mollom就会分析核心转储（core dump）文件。要分析来自16GB机器的核心转储文件并不那么容易，你可能无法在本地机器上分析它，所以Mollom采取的做法是，在亚马逊上租用一个庞大的内存实例来分析转储文件。处理堆转储文件大约需要2个小时。Mollom比较两个转储文件，一个是执行10小时后的，另一个是执行20个小时后的。要是两者存在重大区别，那么很可能是由于内存泄漏。
未来方向
◆Mollom API使用XML-RPC，Mollom现正在测试REST实施方法，以便服务更容易与Mollom进行混搭。
◆由于Mollom现已改用Cassandra，那样发展形势需要时，更容易向外扩展。
◆即将发布企业级功能，那样有可能把几百个网站作为一个整体来管理。这将很容易根据情感、垃圾信息分数来审查一批网站，或者删除来自某些IP地址的所有评论。
◆Mollom已经谈论了如何进入到流数据领域，比如Twitter，但受到了欧洲比较严格的隐私政策的限制。
◆Mollom将尝试使用Glassfish用于每个数据中心的负载均衡。
◆如果负载加大10倍，Mollom将不得不添加更多的Cassandra节点。磁盘输入/输出是瓶颈。只有当发展需求增加10倍以上，才需要添加更多的应用服务器。
经验教训
◆高效率才会带来满意的结果。Mollom非常重视高性能的技术。让Mollom人员引以为豪的是，Mollom极具成本效益。它可以在一台服务器上处理好多请求，延迟低，因而让客户满意、高兴，因为他们没必要维护众多的机器，成本又低。Mollom一开始就把这当作头等大事，选择了合适的技术来实现其目标。这让Mollom能够将创造的利润用于投入到市场营销、建立用户群以及开发基于Mollom的新产品。
◆广泛数据免费，深入数据收费。机器学习需要大量的示例数据，那样才能成功地检测出垃圾信息。为了获得这些数据，Mollom为客户提供了一项免费服务，因为客户提供了更好地训练学习算法所需的广泛数据；客户在源源不断地提供宝贵信息和反馈意见。大客户贡献了收入，同时得益于从免费客户处获得的数据。这种模式似乎特别适合庞大数据和机器学习；正如我们所知，数据和机器学习是一切的未来。
◆消除非特定领域的障碍。庞大系统需要处理基础架构方面的许多工作。基础架构工具常常让人们没空处理产品中真正创造价值的与特定领域相关的部分（分类器、信誉系统和客户库）。Mollom选择了Cassandra和Glassfish，就是为了尽量减少基础架构方面的工作。
◆对于客户端代码要小心。客户端代码很吸引人，因为它可以使用别人的资源，而不是你自己的资源。问题是，代码可能写得不好，结果让你的系统看起来很糟糕。与客户的开发人员紧密合作，提供优质的参考代码示例，那样开发人员就能学习最佳实践。
◆优先对待付费客户。付费客户得到更好的服务质量。他们在队列中优先得到处理，整个系统中遇到的延迟比较短。付费客户可以访问故障切换服务器，而免费客户只能访问一台服务器。
◆让堆栈来处理繁重任务，以减少代码。在早期，Mollom代码库要比现在大得多。Cassandra可以处理复制和行缓存，因而清除了好多复杂代码；Glassfish可以处理集群，也因而清除了好多应用程序代码。代码库慢慢简化下来。
◆尽量减少有锁争用。Mollom花了很多时间来尽量减少GlassFish服务器中的有锁争用，因为这成了主要瓶颈。尽量减少有锁争用，才有可能保持真正的并行处理。
原文：Mollom Architecture - Killing Over 373 Million Spams At 100 Requests Per Second
【编辑推荐】
