Twitter的水平擴(kuò)展的一些關(guān)鍵點(diǎn)，雖然它是個(gè)RoR應(yīng)用，但是這些建議絕對(duì)是放之四海而皆準(zhǔn)的，非常好的總結(jié)。
因?yàn)槟瓿鮐witter曾經(jīng)遇到了性能瓶頸，而且?guī)缀跏譄o(wú)策。當(dāng)初很多人開(kāi)始懷疑Ruby的性能問(wèn)題，而后Twitter站起來(lái)了 ^__^
有時(shí)間的朋友看看這個(gè)slide：http://www.slideshare.net/Blaine/scaling-twitter，沒(méi)有時(shí)間的看看我的摘要。
開(kāi)發(fā)：
1、一定要測(cè)試！一定要早點(diǎn)測(cè)試！一定要早點(diǎn)測(cè)試！否則你就死定了。不要存任何僥幸心理，從項(xiàng)目的開(kāi)始就寫好測(cè)試。
2、對(duì)任何部分都要測(cè)試。還是測(cè)試！
3、性能測(cè)試要交給用戶來(lái)做。那樣才有意義。所以要做好log。用好分析工具：Munin（服務(wù)器內(nèi)存占用監(jiān)控）、Nagios（服務(wù)器服務(wù)網(wǎng)絡(luò)狀態(tài)監(jiān)控）、AWStats & Google Analytics、錯(cuò)誤日志、發(fā)現(xiàn)了錯(cuò)誤馬上進(jìn)入問(wèn)題跟蹤系統(tǒng)（Trac、Jira……太多了，但是最好有一個(gè)）。
架構(gòu)：
1、使用可以分區(qū)的架構(gòu)。按照架構(gòu)上的功能清晰的分區(qū)。這意味著你可以通過(guò)替換一個(gè)實(shí)現(xiàn)來(lái)改進(jìn)性能，因?yàn)樾阅芎蛷?fù)雜度往往是不可兼得的。
對(duì)于數(shù)據(jù)庫(kù)：
1、盡量不要分布式數(shù)據(jù)庫(kù)，包括數(shù)據(jù)庫(kù)分區(qū)。最好通過(guò)提高單臺(tái)服務(wù)器的性能提升這個(gè)節(jié)點(diǎn)的性能。更重要的是查詢優(yōu)化。通過(guò)備份服務(wù)器解決單點(diǎn)故障。
2、對(duì)where子句中的字段增加index。（這個(gè)當(dāng)然了）
3、扁平化查詢，比如一個(gè)user有很多朋友，查一個(gè)人的朋友如果通過(guò)外鍵會(huì)浪費(fèi)很多性能。可以把ids序列化為1,2,3這樣，然后用like查詢速度更快。
4、一定要優(yōu)化你的SQL，不要寄希望于ORM給你解決（不管是DataMapper、ActiveRecord或者UnitOfWork）。
Cache：
1、一定要考慮Cache，最重要的是領(lǐng)域?qū)ο蟮腃ache，一定要考慮Memcache，如Memcached。
2、應(yīng)該有90%的查詢可以Cache。
3、但是要注意Cache實(shí)效問(wèn)題（要及時(shí)標(biāo)注實(shí)效），這個(gè)是個(gè)難點(diǎn)也是個(gè)重點(diǎn)。
4、可以考慮用Message來(lái)標(biāo)記實(shí)效（這樣可以保證異步，無(wú)阻塞的按照順序的讓數(shù)據(jù)失效），據(jù)稱也不是很難。
Messaging：
1、混合應(yīng)用。不用去看Java的OpenFire了，即使它很好，完全可以考慮erlang的ejabberd了，俄羅斯的產(chǎn)物。
2、排隊(duì)問(wèn)題有很多解決方案：ActiveMQ、RabbitMQ、MySQL + Lightweight Locking、Drb（for ruby）