微博基本架构思路
该文章是转载链接是：http://www.cellphp.com/article-read-nosql-20-handlersocket-nosql-zeromq-micro-blog-gps-tokyocabinet.html，在强调不是本人创新，只是感觉写的好用来借鉴一下经验
?
?
?
在我的结构中还有一个重要角色就是"Key GPS Server"(简称:KGS)简单来说,这个是分布式数据存储的中心索引服务器.一切数据的存储和获取,都通过KGS来定位. KGS支持多个服务器,多个机房多重备份存储。KGS是以Tokyo Cabinet的hash db为存储的socket server。记录key跟服务器之间的对应关系. KGS的任务就是告知key该存储在哪几台服务器上,或者告知该key存储在哪几台服务器上，并不做其他的服务.这样大大的减轻KGS的压力.
?
再说一下Redis集群,redis是以纯内存形式模式运行,关闭了热备的功能(redis的热备并不是那么好). 自己写了个backend server.在每台运行redis的机子上都运行着backend socket 进程, backend进程也是以tc的hash db为存储。备份着当前服务器的redis数据。当redis重启的时候，从本机的bakcend db 加载所有数据. Redis的集群是以用户水平切分法来分布的
?
现在该轮到mysql里, 在这个架构中,基本消除了这边缓存 那边缓存的问题。因为在这个集群中的每个服务都是高速运行的.唯一的一处的cache 就是在php端的eAccelerator local cache.?eAccelerator是基于共享内存的,所有速度比基于socket类型的cache快多了. eAccelerator 缓存了用户top N条的微博信息还有从KGS查询的结果。?看到这里有人问了，你把用户信息和微博信息都放在mysql里,怎么能不用cache了.嘿嘿，因为我用了handler socket。HS 是小日本写的一款mysql插件.HS避开了MySQL通讯协议,直接读取MySQL引擎。在多核、大内存、 InnoDB引擎环境,性能直超memcached.HS能以Key-Value方式直接读写mysql引擎
?
?
里面有一个附加关于流程图
