剛剛看了楊衛華的微博技術分享視頻，收獲不少，簡單的記了下來。

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

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

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

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

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

轉載于:https://www.cnblogs.com/wanself/archive/2012/08/31/2664723.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。