一个分布式的负载设计

要求:对于saas这种服务一个用户名,同一段时间只能有一次登录系统。因为用户数量大,所以对于用户的登录,需要能够在多个server上做负载均衡。

Hash 潜在冲突检测模块


节点检测模块

上线用户连接发现与维持模块

各个节点


节点的说明:

1.hash函数计算用户名后,映射到Mbits中的一个,并置1(初始为0),如果已经不是0,就加1.

2.使用countingbloom filter进行计算,支持用户下线删除

3.减少一个node。可能新到的用户名唯独在这个node里面检测是为0,其他都是1,所以认为他上线过了。这样就需要在“hash冲突检测模块”里进行查找,产生退化。

4.增加一个node。只要把“hash冲突检测模块”里的每一个已登陆用户名在这台机器的Mbits里面做hash就可以了。

流程:

登陆的用户,在若干个node里面计算hash,如果有一个空间之前是0,反馈给“节点检测模块”,此模块知道这个用户之前没有登陆过,发送count指令给各个node,各个node把计算出来的那个bitM空间中置1

登陆的用户,在若干个node里面计算hash,如果所有空间之前都是大于等于1,反馈给“节点检测模块”,此模块知道这个用户‘可能’之前登陆过(可能是因为hash存在冲突)。于是在“Hash潜在冲突检测模块”里面查找一次,找到表明真的登录过,没找到表明没有登录过。登陆过则给各个nodecancel指令使之结束这次计算过程,并拒绝登陆,没有登陆则给各个node发送count指令,各个node把计算出来的那个bitM空间中置1

上线用户连接发现与维持模块”发现登陆过用户的长连接断开,则表明用户下线,对各个node的这个用户名计算hash,并把Mbits位中的计算结果哪一位减1

设计缺陷:

对于负责动态负载均衡的nodecountingbloom filter本身有空间M和最优hash函数个数的要求,最好根据用户数确定。

如果用户数很多,那么每个node都做hash函数,其实并没有负载均衡,而是增加了计算的负担。



2012323

快一年了,重新看自己的设计,觉得细节是有,但思路比较复杂,主要思想还是hash+MapReduceBloomfilter错误率其实可以做到很小的,所以偶尔有人重复登陆也不要紧。下面是现在的思路。

服务器端的自动更新程序可以自动更新客户端的配置文件。(写一个服务端程序,自动搜集客户端节点存活信息,调整分配hash值的策略?)

登陆:对用户名散列值的计算可以放到若干台机器上,计算时主登陆服务器轮询分配,此节点死去就不再分配(其中未计算完成的散列导致用户可以二次登陆),主登陆服务器程序动态读取配置文件,给新增节点分配计算量。

检测:计算完成的散列根据散列值的大小的空间分配到相应的机器上按照“拉链法”查找,找到返回主登陆服务器“已登陆”,没找到,返回主登陆服务器“允许登陆”,并把hash值和用户名存储起来。对这些存放登陆信息的服务器通过存储冗余信息,达到坏死一个节点仍能正常运行的目的。比如:10台机器,每一台机器在给主登陆服务器发送“允许登陆”存储hash值和用户名时,把hash值和用户名信息发送给后一台机器(第10台发送给第1台),这样形成一个循环冗余。坏死一个节点时,只要先查询删除后一台机器,并保证迅速恢复坏死机器。增加机器需要重新分配hash值空间,从第一台机器开始逐渐往后拷贝hash值和用户名。或使新增机器和已存在的一台机器共用已存在机器的hash空间,让这几个机器充当一台机器的角色,是为了不重新分配hash空间。

上线用户连接发现与维持模块”发现登陆过用户的长连接断开,则表明用户下线,根据散列空间给相应的机器发送“删除”命令,删除此用户的登陆信息。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值