完全用nosql轻松打造千万级数据量的微博系统.pptVIP

完全用nosql轻松打造千万级数据量的微博系统

七夜(李锦星

重要小提示

架构说明

本架构只是起着抛砖引玉的作用,只介绍大概的架构.本架构注重的是可以动态扩展集群种的效劳器。关于图片附件,数据备份等架构,今天不作介绍.有兴趣的话可以找我讨论.已有类似本架构的微博系统已经在实际运用

ID一致性的问题

通常ID是由mysql自增来产生的.但是在分布式集群里这样的自增ID就带来各个效劳器之间的一致性的问题。在本架构中的唯一ID是由rdtsc+两位随机整数拼接而成的64位整数唯一ID

KeyGPSServer

KGS是本架构重要组成局部.GPS大家都知道是定位的意思.发送一条数据的ID过去。KGS就会告诉你该ID所对应的数据存放在哪几台效劳器上.KGS是基于TokyoCabinet存储,epoll事件驱动的单进程socketserver

所使用的开源工具

整体的架构图

架构图

原图请见架构.png

架构具体讲解—访问流程图

看了架构图,到处都是线,是不是觉的很乱,眼花缭乱的.不要着急,现在我要以流程图慢慢的引领大家看清楚这个框架

名词解说

Handlersocket

大家刚刚可能比较奇怪,我的主题讲的是完全用nosql打造微博系统,怎么会又出现了mysql了?现在给大家介绍Handlersocket。HS是小日本写的一款mysql插件.HS避开了MySQL通讯协议,直接读取MySQL引擎。在多核、大内存、InnoDB引擎环境,性能直超memcached.HS能以Key-Value方式直接读写mysql引擎

ZeroMQ

ZMQ是高性能的消息队列效劳器.单纯的发简单的小文本消息和python的函数调用一样快.publish操作是个很耗时的操作.所以让publish集群从ZMQ取发布信息，在后台并行publish,大大的提高发布效率.当publish速度跟不上的时候,只要增加publish效劳器就行.

KeyGPSServer

刚刚简单的介绍过KGS,我再稍微深入一点介绍一下KGS.KGS是用TC来做物理存储的.把Key跟效劳器的关系记录在TC的hashdb里.这样做到多个效劳器备份存储、权重、最小存储量优先级等一系列操作.

数据分布结构

Redis

Redis主要存储的是发布者和订阅者之间的关系。关系结构主要是以队列+各种信息的64位唯一ID组成,所以存储量是很小的.虽然存储量很小,但是操作量很大.所以放在redis上,redis以纯内存的方式运行,不启用redis自身的热备份.在运行Redis效劳器上，同时运行着backend同步进程。Backend的用TC来存储的.在信息发送给Redis的同时,也发送给backend进行存储.当redis重启的时候,从backend加载用户的结构关系.Redis的集群方式是以水平方式切换.简单来说就是每台Redis效劳器存储着各自5w用户量.这个数值可以根据各自的情况定义

MySQL

mysql存储的是实际信息内容,比方微博信息，和用户信息.把操作很密集的数据,放在Redis里,相对小一点的就放在mysql里

MySQL表结构

Redislist数据结构

example4

Redis数据结构list

1.Following(有多少人订阅我的微博的列表)

2.Followers(我订阅谁的微博的列表)

3.Publish(我发布的微博消息列表)

4.Subscribe〔我订阅的消息包括我发布的信息〕

总结

明星会员问题

所谓的明星会员问题,就是刘德华来咱微博开了个微博。他有成千上万个订阅者.他发布一条微博消息。那得一下子发布到成千上万个订阅者那。多来几个刘德华这样的明星微博,咱们效劳器不是要死翘翘了。所以我这里有个publish集群,根据订阅者分为活泼用户，一般用户，半死不活用户.根据活泼度分到不同的快速publish效劳器或慢速publish效劳器里去.因为是纯内存的只是在redislist里加个信息ID。还是很快的

理解不了本架构

对于本架构理解的同学,请先阅读一下Retwis.Retwis是完全用redis写的简单微博系统,再结合本架构，多看几次就懂了。很快的

集群

本架构讲究的是高可用,稳定，可动态扩展的架构.谢谢大家