64,648
社区成员
发帖
与我相关
我的任务
分享大数据量用户下可扩展设计请教
公司最近做了个偷菜copy 的产品，反正是copy 项目，产品本身的
实现的细节，相信大家应该都清楚，就不多说了。因为现在用户少，
所以架构能抗住，但是我感觉以后用户多了 有很多问题，比如开心菜园
是2000w 用户，量很大了。我自己在尝试设计的时候发现很多问题 解决起来比较困难
还是要请大牛来解答
逻辑架构
网关1 网关2 网关3 ........
逻辑服务器1 逻辑服务器2 逻辑服务器3 逻辑服务器4 ..............
DB 缓存1 DB缓存2
因为目前的数量很低，很多数据是预测的，可能有偏差。
各个服务器的 作用，
网关服务器 ：接入web 客户端， 连接 逻辑服务器，简单的转发数据
逻辑服务器： 处理真正的逻辑业务，存储用户对象，包括好友列表。
DB缓存服务器： 从DB获取缓存， 或者直接以DB服务器代替。
同时每个用户都有自己唯1的数字ID
目前假设一个网关可以同时接入3w 连接， 而每台逻辑服务器可以完成1W 个用户的逻辑处理
并有 A 用户 ID 100
A 有一个好友B ID 90000
目前考虑的方案和它们的缺陷
方案1
每个用户以ID 被划分到固定的网关上， 比如 1-30000 就在网关1 30001-60000 在网关2
每个用户以ID 被划分在固定的逻辑服务器上 比如1-10000 就在逻辑1 10001-20000 在网关2
每个网关只负责固定数量的逻辑服务器， 网关1 只和 逻辑1 2 3服务器相连 网关2和逻辑 4 5 6服务器相连
如果 当用户A在网关2 登陆 那么将被拒绝。要求重新登陆网关1
当用户A 在逻辑服务器1 要求看自己的好友B 时候， 那么逻辑1 就需要和 逻辑9 交互，逻辑 9 去读取数据
处理后然后回给逻辑1。
优点是 固定用户， 压力固定，一旦某个网关坏掉或者逻辑服务器坏掉都不会影响其他服务器。
缺点
1 所有的逻辑服务器之间需要建立连接， 也就是有N 台服务器 就 N*(N-1) /2 条连接，
当服务器数量增加，这个连接管理会很麻烦。而且重连管理也会很麻烦。
2 当用户不在活跃以后，服务器的很多负载会很不均衡。 比如10000-20000 服务器的上的用户，大多数都不活跃了。
但是逻辑2 服务器还需要继续工作。
3 扩展困难， 当以后业务复杂了， 逻辑服务器单机只能负载5000 用户的时候，要升级会很麻烦。因为现在的很多算法是
定死了的。
方案2
1 客户可以登陆任何一个网关，
2 每个网关只负责固定数量的逻辑服务器， 网关1 只和 逻辑1 2 3服务器相连 网关2和逻辑 4 5 6服务器相连 同方案1
3 逻辑服务器可以产生所有的用户的实例
比如 A 登陆一个网关，那么网关就直接 找一个逻辑服务器，然后逻辑服务器生成所有需要的数据返回给A
问题，
B 登陆了 逻辑服务器1 而 好友A同时登陆了逻辑服务器2，此时， 可能出现脏数据的问题。
具体的 好友B 先获取自己的资料发现有100棵菜， 这时候A 上线，获取B的资料，发现也是100棵菜。此时100 这个数值
在2台逻辑服务器内。 A偷菜， B收菜。
数据同时回写到 DB, ..... 杯具!!!
多次登录的问题
A 用户登陆网关1 同时登陆网关2 网关3
那么此时他可能同时 在逻辑1 逻辑6 逻辑9 服务器上面有1个1样的实例。
同时收菜，逻辑1、 6 、9 完成操作， 回写DB .....又是杯具！！
优点 性能好，容易扩展。
缺点 脏数据。用户数据互斥问题无法解决。反馈消息无法返回。
实现的细节，相信大家应该都清楚，就不多说了。因为现在用户少，
所以架构能抗住，但是我感觉以后用户多了 有很多问题，比如开心菜园
是2000w 用户，量很大了。我自己在尝试设计的时候发现很多问题 解决起来比较困难
还是要请大牛来解答
逻辑架构
网关1 网关2 网关3 ........
逻辑服务器1 逻辑服务器2 逻辑服务器3 逻辑服务器4 ..............
DB 缓存1 DB缓存2
因为目前的数量很低，很多数据是预测的，可能有偏差。
各个服务器的 作用，
网关服务器 ：接入web 客户端， 连接 逻辑服务器，简单的转发数据
逻辑服务器： 处理真正的逻辑业务，存储用户对象，包括好友列表。
DB缓存服务器： 从DB获取缓存， 或者直接以DB服务器代替。
同时每个用户都有自己唯1的数字ID
目前假设一个网关可以同时接入3w 连接， 而每台逻辑服务器可以完成1W 个用户的逻辑处理
并有 A 用户 ID 100
A 有一个好友B ID 90000
目前考虑的方案和它们的缺陷
方案1
每个用户以ID 被划分到固定的网关上， 比如 1-30000 就在网关1 30001-60000 在网关2
每个用户以ID 被划分在固定的逻辑服务器上 比如1-10000 就在逻辑1 10001-20000 在网关2
每个网关只负责固定数量的逻辑服务器， 网关1 只和 逻辑1 2 3服务器相连 网关2和逻辑 4 5 6服务器相连
如果 当用户A在网关2 登陆 那么将被拒绝。要求重新登陆网关1
当用户A 在逻辑服务器1 要求看自己的好友B 时候， 那么逻辑1 就需要和 逻辑9 交互，逻辑 9 去读取数据
处理后然后回给逻辑1。
优点是 固定用户， 压力固定，一旦某个网关坏掉或者逻辑服务器坏掉都不会影响其他服务器。
缺点
1 所有的逻辑服务器之间需要建立连接， 也就是有N 台服务器 就 N*(N-1) /2 条连接，
当服务器数量增加，这个连接管理会很麻烦。而且重连管理也会很麻烦。
2 当用户不在活跃以后，服务器的很多负载会很不均衡。 比如10000-20000 服务器的上的用户，大多数都不活跃了。
但是逻辑2 服务器还需要继续工作。
3 扩展困难， 当以后业务复杂了， 逻辑服务器单机只能负载5000 用户的时候，要升级会很麻烦。因为现在的很多算法是
定死了的。
方案2
1 客户可以登陆任何一个网关，
2 每个网关只负责固定数量的逻辑服务器， 网关1 只和 逻辑1 2 3服务器相连 网关2和逻辑 4 5 6服务器相连 同方案1
3 逻辑服务器可以产生所有的用户的实例
比如 A 登陆一个网关，那么网关就直接 找一个逻辑服务器，然后逻辑服务器生成所有需要的数据返回给A
问题，
B 登陆了 逻辑服务器1 而 好友A同时登陆了逻辑服务器2，此时， 可能出现脏数据的问题。
具体的 好友B 先获取自己的资料发现有100棵菜， 这时候A 上线，获取B的资料，发现也是100棵菜。此时100 这个数值
在2台逻辑服务器内。 A偷菜， B收菜。
数据同时回写到 DB, ..... 杯具!!!
多次登录的问题
A 用户登陆网关1 同时登陆网关2 网关3
那么此时他可能同时 在逻辑1 逻辑6 逻辑9 服务器上面有1个1样的实例。
同时收菜，逻辑1、 6 、9 完成操作， 回写DB .....又是杯具！！
优点 性能好，容易扩展。
缺点 脏数据。用户数据互斥问题无法解决。反馈消息无法返回。
...全文
请发表友善的回复…
发表回复
Contemplating 2009-12-31
- 打赏
- 举报
提供一点建议：可以考虑使用内存数据库(IMDB)，比如eXtremeDB或Times Ten
我要戒烟了 2009-12-31
- 打赏
- 举报
B 登陆了 逻辑服务器1 而 好友A同时登陆了逻辑服务器2，此时， 可能出现脏数据的问题。
具体的 好友B 先获取自己的资料发现有100棵菜， 这时候A 上线，获取B的资料，发现也是100棵菜。此时100 这个数值
在2台逻辑服务器内。 A偷菜， B收菜。
数据同时回写到 DB, ..... 杯具!!!
-----------------------------------
由于是操作同一玩家的同一数据，所以这两个操作最终必然发生在同一进程中，操作的来源可能同时到达，感觉只能是加锁了...
具体的 好友B 先获取自己的资料发现有100棵菜， 这时候A 上线，获取B的资料，发现也是100棵菜。此时100 这个数值
在2台逻辑服务器内。 A偷菜， B收菜。
数据同时回写到 DB, ..... 杯具!!!
-----------------------------------
由于是操作同一玩家的同一数据，所以这两个操作最终必然发生在同一进程中，操作的来源可能同时到达，感觉只能是加锁了...
benjiam 2009-12-30
- 打赏
- 举报
up
我要戒烟了 2009-12-30
- 打赏
- 举报
ding
yinshisike 2009-12-30
- 打赏
- 举报
帮顶了
benjiam 2009-12-24
- 打赏
- 举报
数据库加锁 是个很不好的设计。 可以说非常低效。
关键是一个好的路由算法。
每个用户有一个Home Register数据库存储他的信息,
他可能漫游的地方时Visit Register数据库
而所有的收费（也就是你这里的蔬菜）只能在Home Resiger里面计算； 其实又回到 方案1 上面来了
也就是顶层是方案2 做接入 ，核心计算 是方案1.
关键是一个好的路由算法。
每个用户有一个Home Register数据库存储他的信息,
他可能漫游的地方时Visit Register数据库
而所有的收费（也就是你这里的蔬菜）只能在Home Resiger里面计算； 其实又回到 方案1 上面来了
也就是顶层是方案2 做接入 ，核心计算 是方案1.
kiwigiving 2009-12-19
- 打赏
- 举报
学习学习，帮顶了，楼主~
cattycat 2009-12-19
- 打赏
- 举报
不要对登录哪个网关作假设，网关由前面的处理进行负载均衡处理，保证各网关服务器连接数相当。
同样，让逻辑服务器能访问任何DB服务器，这样任何用户都能处理，只维护用户的一个实例，逻辑服务器之间不需通信。
这样关键就在于你的DB服务器数据如何分布了，考虑如何对数据进行分区，同样支持集群和负载均衡，这样扩展性就好了。
至于数据不统一，这个需要数据库访问时加锁就行，在你的方案1也要注意这个问题。
同样，让逻辑服务器能访问任何DB服务器，这样任何用户都能处理，只维护用户的一个实例，逻辑服务器之间不需通信。
这样关键就在于你的DB服务器数据如何分布了，考虑如何对数据进行分区，同样支持集群和负载均衡，这样扩展性就好了。
至于数据不统一，这个需要数据库访问时加锁就行，在你的方案1也要注意这个问题。
tan625747 2009-12-19
- 打赏
- 举报
楼主思路清析，分析到位，在下先学习了。
针对楼主：发生杯具的产生，是由于数据的不能更新
建议采用方案件2，进行修改
我的方案修改你方案2。可以利用db服务器呀
db服务器，对第一个用户登录进行一个标记，这样就了你说的一个用户在多个网关服务器登录问题。
不知道你的db服务器是不是自己的一些菜资料，如果是这样的话，就很解决了。
要不对偷菜和收菜动作发送时间标记，那个先到时间早就db服务器先处理谁的
针对楼主：发生杯具的产生，是由于数据的不能更新
建议采用方案件2，进行修改
我的方案修改你方案2。可以利用db服务器呀
db服务器，对第一个用户登录进行一个标记，这样就了你说的一个用户在多个网关服务器登录问题。
不知道你的db服务器是不是自己的一些菜资料，如果是这样的话，就很解决了。
要不对偷菜和收菜动作发送时间标记，那个先到时间早就db服务器先处理谁的
KnowKjava 2009-12-19
- 打赏
- 举报
大数据量
wanghao111 2009-12-19
- 打赏
- 举报
帮顶了
ThinkInAI 2009-12-18
- 打赏
- 举报
最近正在研究GSM的手机漫游实现，其实2者实质差不多。
我给你讲讲GSM的实现，你可以参考：
每个用户有一个Home Register数据库存储他的信息,
他可能漫游的地方时Visit Register数据库
而所有的收费（也就是你这里的蔬菜）只能在Home Resiger里面计算；
当然，任何一个稍微复杂的程序都有互斥的问题，因此不能因为互斥就傻眼了，解决办法：
相互加锁、
消息机制
也就是说菜是共享资源，每个访问者要互斥和同步：通俗易懂一点就是某一个菜在被偷的时候你的采的动作需要等待或者失败；反之亦然。
我给你讲讲GSM的实现，你可以参考：
每个用户有一个Home Register数据库存储他的信息,
他可能漫游的地方时Visit Register数据库
而所有的收费（也就是你这里的蔬菜）只能在Home Resiger里面计算；
当然，任何一个稍微复杂的程序都有互斥的问题，因此不能因为互斥就傻眼了，解决办法：
相互加锁、
消息机制
也就是说菜是共享资源，每个访问者要互斥和同步：通俗易懂一点就是某一个菜在被偷的时候你的采的动作需要等待或者失败；反之亦然。
taodm 2009-12-17
- 打赏
- 举报
可以google erlang语言
