Twitter的技术给我们的启发

Twitter的水平扩展的一些关键点，虽然它是个RoR应用，但是这些建议绝对是放之四海而皆准的，非常好的总结。

　　因为年初Twitter曾经遇到了性能瓶颈，而且几乎束手无策。当初很多人开始怀疑Ruby的性能问题，而后Twitter站起来了 ^__^

　　有时间的朋友看看这个slide：http://www.slideshare.net/Blaine/scaling-twitter，http://www.bt285.cn 没有时间的看看我的摘要。

　　开发：

　　1、一定要测试！一定要早点测试！一定要早点测试！否则你就死定了。不要存任何侥幸心理，从项目的开始就写好测试。

　　2、对任何部分都要测试。还是测试！

　　3、性能测试要交给用户来做。那样才有意义。所以要做好log。用好分析工具：Munin（服务器内存占用监控）、Nagios（服务器服务网络状态监控）、AWStats & Google Analytics、错误日志、发现了错误马上进入问题跟踪系统（Trac、Jira……太多了，但是最好有一个）。

　　架构：

　　使用可以分区的架构。按照架构上的功能清晰的分区。这意味着你可以通过替换一个实现来改进性能，因为性能和复杂度往往是不可兼得的。

　　对于数据库：

　　1、尽量不要分布式数据库，包括数据库分区。最好通过提高单台服务器的性能提升这个节点的性能。更重要的是查询优化。通过备份服务器解决单点故障。

　　2、对where子句中的字段增加index。（这个当然了）

　　3、扁平化查询，比如一个user有很多朋友，查一个人的朋友如果通过外键会浪费很多性能。可以把ids序列化为1,2,3这样，然后用like查询速度更快。

　　4、一定要优化你的SQL，不要寄希望于ORM给你解决（不管是DataMapper、ActiveRecord或者UnitOfWork）。

　　Cache：

　　1、一定要考虑Cache，最重要的是领域对象的Cache，一定要考虑Memcache，如Memcached。

　　2、应该有90%的查询可以Cache。

　　3、但是要注意Cache实效问题（要及时标注实效），这个是个难点也是个重点。

　　4、可以考虑用Message来标记实效（这样可以保证异步，无阻塞的按照顺序的让数据失效），据称也不是很难。

　　Messaging：

　　1、混合应用。不用去看Java的OpenFire了，即使它很好，完全可以考虑erlang的ejabberd了，俄罗斯的产物。

　　2、排队问题有很多解决方案：ActiveMQ、RabbitMQ、MySQL + Lightweight Locking、Drb（for ruby）

 

 

评论

2 楼 xiuxiuxiu 2008-10-19  

Arden 写道

　　3、扁平化查询，比如一个user有很多朋友，查一个人的朋友如果通过外键会浪费很多性能。可以把ids序列化为1,2,3这样，然后用like查询速度更快。

这一点是啥意思？

大概就是把join拆成若干单表的select来做吧

1 楼 Arden 2008-10-19  

　　3、扁平化查询，比如一个user有很多朋友，查一个人的朋友如果通过外键会浪费很多性能。可以把ids序列化为1,2,3这样，然后用like查询速度更快。

这一点是啥意思？