Twitter的水平擴展的一些關鍵點，雖然它是個RoR應用，但是這些建議絕對是放之四海而皆準的，非常好的總結。
因為年初Twitter曾經遇到了性能瓶頸，而且?guī)缀跏譄o策。當初很多人開始懷疑Ruby的性能問題，而后Twitter站起來了 ^__^
有時間的朋友看看這個slide：http://www.slideshare.net/Blaine/scaling-twitter，沒有時間的看看我的摘要。
開發(fā)：
1、一定要測試！一定要早點測試！一定要早點測試！否則你就死定了。不要存任何僥幸心理，從項目的開始就寫好測試。
2、對任何部分都要測試。還是測試！
3、性能測試要交給用戶來做。那樣才有意義。所以要做好log。用好分析工具：Munin（服務器內存占用監(jiān)控）、Nagios（服務器服務網絡狀態(tài)監(jiān)控）、AWStats & Google Analytics、錯誤日志、發(fā)現了錯誤馬上進入問題跟蹤系統(tǒng)（Trac、Jira……太多了，但是最好有一個）。
架構：
1、使用可以分區(qū)的架構。按照架構上的功能清晰的分區(qū)。這意味著你可以通過替換一個實現來改進性能，因為性能和復雜度往往是不可兼得的。
對于數據庫：
1、盡量不要分布式數據庫，包括數據庫分區(qū)。最好通過提高單臺服務器的性能提升這個節(jié)點的性能。更重要的是查詢優(yōu)化。通過備份服務器解決單點故障。
2、對where子句中的字段增加index。（這個當然了）
3、扁平化查詢，比如一個user有很多朋友，查一個人的朋友如果通過外鍵會浪費很多性能。可以把ids序列化為1,2,3這樣，然后用like查詢速度更快。
4、一定要優(yōu)化你的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）