剛剛看了楊衛(wèi)華的微博技術(shù)分享視頻，收獲不少，簡單的記了下來。

觀看地址：http://www.infoq.com/cn/presentations/ywh-build-high-performance-weibo mysql一個端口放到4-500G，就基本到極限了。

mysql 讀得速度 一個端口，一個服務器也就幾千的讀速度。

微博的用戶資料的查詢上萬上十萬的查詢。

用好一款開源產(chǎn)品的前提條件是深刻了解它的產(chǎn)品定位。

Redis非常簡單。源代碼只有兩萬行。 Redis持久方式： snapshot,主流方式，（微博采用），數(shù)據(jù)必須小于內(nèi)存大小。 vm ：自動將冷數(shù)據(jù)放到磁盤，然后將熱數(shù)據(jù)放到內(nèi)存，Redis的作者放棄這個功能。 diskstore：作者新方向，類mysql-memcache。 aof:所有的操作寫磁盤日志，便于內(nèi)存數(shù)據(jù)定時寫磁盤中間數(shù)據(jù)的保留，重建慢。 Redis數(shù)據(jù)類型： string： key,value,redisObject 16bytes/item,是C語言的struct數(shù)據(jù)結(jié)構(gòu)。 list: 雙向列表 40bytes/item hash：zipmap壓縮，（<64） set：可排序和特定的需求。 Redis-定位 高速讀寫，容忍短期不可用，沒有成熟的failover方案，有l(wèi)ist、set數(shù)據(jù)結(jié)構(gòu)需求。 海量存儲 Mysql，久經(jīng)考驗的海量存儲， Nosql，填補Mysql與cache之間空隙，但是需要有合適的駕馭能力。 你用一款nosql，你要問自己能否駕馭它，他的特性是什么，適合什么場所，會出現(xiàn)什么問題，業(yè)務上能不能容忍。 實時計算 大部分WEB系統(tǒng)瓶頸在于cache數(shù)據(jù)訪問，僅用壓縮是否能夠？ 可用的cache資源中的熱點資源，肩負和擴容。 一般喜歡用json放入cache，但很浪費空間。一條微博用2~5K字節(jié)，使用xml需要10K，最后使用protobuf（二進制）序列化后，大約只有500字節(jié)。并且編解碼高效。取出來后直接就是對象，修改也很輕松，不擔心運算量，還有可以存儲中間對象。 異步處理的需求 一上線就出問題，原因是使用人員對異步操作沒有深入理解。 Redis 的master 1s寫幾千條沒有問題， 監(jiān)控每一個APP的接口。 架構(gòu)的責任是讓系統(tǒng)盡量的簡單。 新服務上線，老服務沒有優(yōu)化。 不怕出問題，就怕不知道哪出得問題。 給業(yè)務降級，每個業(yè)務獨立開關(guān)。

轉(zhuǎn)載于:https://www.cnblogs.com/wanself/archive/2012/08/31/2664723.html

總結(jié)

以上是生活随笔為你收集整理的再谈新浪微博架构——视频观后笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。