图解Twitter的服务器架构

Twitter的服务器架构的简要示意图：. Unicorn： Ruby 的HTTP服务器. Kestrel ： Twitter用Scala写的message queue. Flapp： Twitter做的图存储FlockDB. Gizzard： Twitter用Scala写的一个通用Sharding框架.

twitter系统架构分析. （一）twitter的核心业务. twitter的核心业务，在于following和be followed：. （1）following-关注. 进入个人主页，会看到你follow的人发表的留言（不超过140个字），这是following的过程；. （2）followed-被关注.

Twitter工程经理Sarrabh Pathak在伦敦QCon 2017大会上介绍了Twitter网站的通知系统架构. 他主要介绍了Twitter所面临的独特挑战，比如社交网络的双峰（bimodal）性、如何应付尖刺流量以及如何实现实时的通知机制. Pathak解释说，与一般的社交网络不同，Twitter的用户数据具有不对称性.

Twitter有两条时间线：. 用户时间线： 用户自己所有推文的集合，从磁盘中获取. 主页时间线： 用户关注的人的推文的集合，组成了用户的主页. 在设计数据库时，最简单的数据库只是将所有写操作附加到文件的末尾，并在需要时读取. 没有什么比简单的附加到文件中更快的了，但是，随着数据库文件的增长，从这种类型的数据库中查询某些内容将花费很长时间.

前Flickr的架构师  Cal Henderson，在 Flickr: Web Services 这个PPT中，有对其架构比较全面的阐述. Flickr运维团队的John Allspaw，有两个讲LAMP的幻灯，Hardware Layouts for LAMP Installations 和  capacity planning for LAMP，但应该是Flickr架构演进和运维的一些经验总结，其中也透露一些服务器架构.

Google，无疑是互联网时代最闪亮的明星. 截止到今天为止，Google美国主站在Alexa排名已经连续3年第一，Alexa Top100中，各国的Google分站竟然霸占了超过20多个名额，不得不令人感叹Google的强大. 不论何时，不论何地，也不论你搜索多么冷门的词汇，只要你的电脑连接互联网，只要你轻轻点击“google搜索”，那么这一切相关内容google都会在1秒钟之内全部搞定，这甚至比你查询“我的文档”都要快捷.

    任何一行都有自己的军规, 我想这篇著名的文章就是游戏服务器程序员的军规. 也许你认为游戏服务器程序员日常并不涉及这样底层的实现, 而只是去完成策划提出的需求, 我觉得也有道理, 毕竟这些是我们的工作, 下面的译文就不太适合你. 但是对于想改进现有系统, 在服务器方面给予更好的技术支持, 那么你在开始工作之前必须了解一些禁忌, 并且给出了一些解决方向上的真知灼见.

这篇文章 SKYPE’s Roadmap and Architecture 简化地描述了Skype的架构. Skype的数据库团队leader  Asko Oja 的幻灯， http://www.slideshare.net/highload/asko-oja-moskva-architecture-highload-presentation 则说Skype使用了PostgreSQL和Skype贡献的开源工具(plProxy, pgBouncer, PgQ…)做分布式数据库.

本文来自： http://wetest.qq.com/. 在服务器端程序开发领域，性能问题一直是备受关注的重点. 业界有大量的框架、组件、类库都是以性能为卖点而广为人知. 然而，服务器端程序在性能问题上应该有何种基本思路，这个却很少被这些项目的文档提及. 本文正式希望介绍服务器端解决性能问题的基本策略和经典实践，并分为几个部分来说明：.

今天（2011年5月31日），Twitter 发布了能够帮助我们的用户找到最相关的推文、图片和视频的 个人化搜索体验. 要创造这个产品，我们的基础架构需要支持两项主要的功能：搜索结果的相关性过滤和对于相关图片以及视频的识别. 两项功能都需要我们完全重写我们搜索架构，他们的核心就是 Blender 和 Earlybird.