完全用nosql轻松打造千万级数据量的微博系统【转】
12月19日很荣幸的参加了CU举办的PHP交流会,可能准备的
在我的结构中还有一个重要角色就是"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引擎
总结
Google首席科学家讲过一句话，就是一个大的复杂的系统，应该要分解成很多小的服务. 我的这个架构也是由一个个小的集群来共同处理大数据量发布数据。有的人为什么不用mongodb了,因为mongodb是一款大众性的分布式nosql db,我们有自己的key分布策略,不太适合用mongodb. 不理解redis的存储关系的同学，可以先参考一下 Retwis, Retwis是用纯redis实现的简单微博.
具体的架构图、流程图、ppt文件。请下载附件来阅读.? ?http://code.google.com/p/php-tok ... &q=#makechanges
我的QQ: 531020471 mail: lijinxing#gmail.com
我的 blog: http://www.cellphp.com/article-r ... s-tokyocabinet.html