再谈新浪微博架构——视频观后笔记

刚刚看了杨卫华的微博技术分享视频，收获不少，简单的记了下来。

观看地址：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的接口。

架构的责任是让系统尽量的简单。

新服务上线，老服务没有优化。

不怕出问题，就怕不知道哪出得问题。

给业务降级，每个业务独立开关。