刚刚看了杨卫华的微博技术分享视频，收获不少，简单的记了下来。
观看地址：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的接口。
架构的责任是让系统尽量的简单。
新服务上线，老服务没有优化。
不怕出问题，就怕不知道哪出得问题。
给业务降级，每个业务独立开关。