怎么做！我看到这个题，第一想法就是观察者模式，可是，大数据量，又让我觉得很犹豫！==
求解答....
多谢
16 个解决方案
#1
该回复于2015-04-28 10:26:46被管理员删除
#2
个人觉得10000的数据量不算大的 几十万以上的时候估计就要优化硬件了 这种设计无非就是服务器缓存的推或者拉，也可以说成是观察者模式 只不过按时间 分区存储了下 你可以看看nosql
#3
这确实是一个问题。假设当前系统在线的人中有1000人都有1w关注者，那么需要进行“通知到客户端”的消息就有1千万，而这些消息需要在几秒钟内通知到所有的用户，还不能严重干扰网站其它功能的用户体验。
你会发现面试者跟自己的一个最主要的区别：面试者是从通讯效率和用户体验出发的，而你自己竟然只知道从服务器内存计算或者数据库存取出发。二者完全不在一个频道，所以你无法准确回答。
你会发现面试者跟自己的一个最主要的区别：面试者是从通讯效率和用户体验出发的，而你自己竟然只知道从服务器内存计算或者数据库存取出发。二者完全不在一个频道，所以你无法准确回答。
#4
如果1个人的状态改变了，此时要你统计一下这1000人的所有关注者的id，你用5毫秒（不算数据反序列化和显示时间）。
而人家其实是问你“如何让1000个Vip的所有1000万的客户端全都迅速完成通知”这个问题，这时候需要你清晰地表示出你如何估计网络上都跑多少信令、此时不同种类信令的带宽占用大概是多少，将全栈系统数据结构设计贯通而不是只知道一点点后台编程的放之四海而皆准的概念。
而人家其实是问你“如何让1000个Vip的所有1000万的客户端全都迅速完成通知”这个问题，这时候需要你清晰地表示出你如何估计网络上都跑多少信令、此时不同种类信令的带宽占用大概是多少，将全栈系统数据结构设计贯通而不是只知道一点点后台编程的放之四海而皆准的概念。
#5
此时要你统计一下这1000人的所有关注者的id --> 此时要你统计一下这1人的所有关注者的id
这个东西不会随便说答案，有两个原因：
1. 它是当今互联网软件企业创业热点问题。
2. 说了答案你没有5年以上服务器系统架构设计和测试经验，可能也做不到。
3. 大多数没有经验的人会去拼凑堆砌大数据的通用名词儿。而面试者就是想拨开谎言而看真实的经验，所以这还是看你自己回答。
这个东西不会随便说答案，有两个原因：
1. 它是当今互联网软件企业创业热点问题。
2. 说了答案你没有5年以上服务器系统架构设计和测试经验，可能也做不到。
3. 大多数没有经验的人会去拼凑堆砌大数据的通用名词儿。而面试者就是想拨开谎言而看真实的经验，所以这还是看你自己回答。
#6
一个memcached搞定,没看出有什么技术含量.硬件维护和估算是专门的一个职业.
#7
是对应届毕业生的实习面试题吗？？这种难度应该是社招吧。。。
#8
既然是实习题，你就说思路，表达你的思考，实际做的话，暂时应该不要考虑
#9
个人感觉，这个像是个广播，被关注的人只需要将他的状态广播给关注了他的人就可以了，至于10000不算大吧
#10
我的理解，被关注者相当于博主，是消息的发起者A，关注者相当于是接受者B，A将消息发给微博服务器S，S在将消息发给所有的B。那么A给S的消息MSG要包含｛"status":"break heart again","sendto":["b1","b2","b3"....]}。服务S就要设计成一个分布式得异步消息系统，将消息推给在线的B。核心就在于这个异步消息系统怎么设计。至于加缓存redis，队列zeromq，消息推送技术，websocket之类的，具体实现和部署服务S才是难点哈。
#11
这种实习生的笔试题
真的太变态了
真的太变态了
#12
可不可以换个思路，一个帐号的被关注数可能十分庞大，采用发送的方式数据量较大；但是每个用户的关注数较小，采用接收的方式数据量也就较小。即不在发布状态时发送给每个关注者，而是在关注者打开应用时接收状态。我也是初学者，不对莫怪啊
#13
可以参考redis（nosql）的订阅，发布者、接收者、管道
#14
这种是系统架构级别的问题，实习期就让你解决这个实际上不会的。既然问算法，就是让你列出些逻辑。例如：分批发送之类的。
#15
姑且称被关注者为消息生产者，关注者为消息消费者。
生产者：生产者发布消息到消息服务器，消息以栈后进先出的形式存储，每个生产者的消息都有一个栈，那么服务器上就有一个生产者的消息列表。
消费者：关注被关注者，也就是订阅服务器消息，服务器上会保存一条关联记录。
假设一个生产者被10000个人关注，他只需要发一条消息到服务器，关注者从服务器上读取这条消息，但是服务器要向10000个关注者推送消息通知。
ps:我记得微博上是这样的，如果被关注者发布了一条新消息，这条消息会被放到服务器上存储，然后向关注者发送一条有新消息的通知，关注者需要刷新下页面才可以获取最新的消息。
生产者：生产者发布消息到消息服务器，消息以栈后进先出的形式存储，每个生产者的消息都有一个栈，那么服务器上就有一个生产者的消息列表。
消费者：关注被关注者，也就是订阅服务器消息，服务器上会保存一条关联记录。
假设一个生产者被10000个人关注，他只需要发一条消息到服务器，关注者从服务器上读取这条消息，但是服务器要向10000个关注者推送消息通知。
ps:我记得微博上是这样的，如果被关注者发布了一条新消息，这条消息会被放到服务器上存储，然后向关注者发送一条有新消息的通知，关注者需要刷新下页面才可以获取最新的消息。
#16
这个是消息队列的典型应用场景吧，发布/订阅。activemq、rabbitmq、kafka
#1
该回复于2015-04-28 10:26:46被管理员删除
#2
个人觉得10000的数据量不算大的 几十万以上的时候估计就要优化硬件了 这种设计无非就是服务器缓存的推或者拉，也可以说成是观察者模式 只不过按时间 分区存储了下 你可以看看nosql
#3
这确实是一个问题。假设当前系统在线的人中有1000人都有1w关注者，那么需要进行“通知到客户端”的消息就有1千万，而这些消息需要在几秒钟内通知到所有的用户，还不能严重干扰网站其它功能的用户体验。
你会发现面试者跟自己的一个最主要的区别：面试者是从通讯效率和用户体验出发的，而你自己竟然只知道从服务器内存计算或者数据库存取出发。二者完全不在一个频道，所以你无法准确回答。
你会发现面试者跟自己的一个最主要的区别：面试者是从通讯效率和用户体验出发的，而你自己竟然只知道从服务器内存计算或者数据库存取出发。二者完全不在一个频道，所以你无法准确回答。
#4
如果1个人的状态改变了，此时要你统计一下这1000人的所有关注者的id，你用5毫秒（不算数据反序列化和显示时间）。
而人家其实是问你“如何让1000个Vip的所有1000万的客户端全都迅速完成通知”这个问题，这时候需要你清晰地表示出你如何估计网络上都跑多少信令、此时不同种类信令的带宽占用大概是多少，将全栈系统数据结构设计贯通而不是只知道一点点后台编程的放之四海而皆准的概念。
而人家其实是问你“如何让1000个Vip的所有1000万的客户端全都迅速完成通知”这个问题，这时候需要你清晰地表示出你如何估计网络上都跑多少信令、此时不同种类信令的带宽占用大概是多少，将全栈系统数据结构设计贯通而不是只知道一点点后台编程的放之四海而皆准的概念。
#5
此时要你统计一下这1000人的所有关注者的id --> 此时要你统计一下这1人的所有关注者的id
这个东西不会随便说答案，有两个原因：
1. 它是当今互联网软件企业创业热点问题。
2. 说了答案你没有5年以上服务器系统架构设计和测试经验，可能也做不到。
3. 大多数没有经验的人会去拼凑堆砌大数据的通用名词儿。而面试者就是想拨开谎言而看真实的经验，所以这还是看你自己回答。
这个东西不会随便说答案，有两个原因：
1. 它是当今互联网软件企业创业热点问题。
2. 说了答案你没有5年以上服务器系统架构设计和测试经验，可能也做不到。
3. 大多数没有经验的人会去拼凑堆砌大数据的通用名词儿。而面试者就是想拨开谎言而看真实的经验，所以这还是看你自己回答。
#6
一个memcached搞定,没看出有什么技术含量.硬件维护和估算是专门的一个职业.
#7
是对应届毕业生的实习面试题吗？？这种难度应该是社招吧。。。
#8
既然是实习题，你就说思路，表达你的思考，实际做的话，暂时应该不要考虑
#9
个人感觉，这个像是个广播，被关注的人只需要将他的状态广播给关注了他的人就可以了，至于10000不算大吧
#10
我的理解，被关注者相当于博主，是消息的发起者A，关注者相当于是接受者B，A将消息发给微博服务器S，S在将消息发给所有的B。那么A给S的消息MSG要包含｛"status":"break heart again","sendto":["b1","b2","b3"....]}。服务S就要设计成一个分布式得异步消息系统，将消息推给在线的B。核心就在于这个异步消息系统怎么设计。至于加缓存redis，队列zeromq，消息推送技术，websocket之类的，具体实现和部署服务S才是难点哈。
#11
这种实习生的笔试题
真的太变态了
真的太变态了
#12
可不可以换个思路，一个帐号的被关注数可能十分庞大，采用发送的方式数据量较大；但是每个用户的关注数较小，采用接收的方式数据量也就较小。即不在发布状态时发送给每个关注者，而是在关注者打开应用时接收状态。我也是初学者，不对莫怪啊
#13
可以参考redis（nosql）的订阅，发布者、接收者、管道
#14
这种是系统架构级别的问题，实习期就让你解决这个实际上不会的。既然问算法，就是让你列出些逻辑。例如：分批发送之类的。
#15
姑且称被关注者为消息生产者，关注者为消息消费者。
生产者：生产者发布消息到消息服务器，消息以栈后进先出的形式存储，每个生产者的消息都有一个栈，那么服务器上就有一个生产者的消息列表。
消费者：关注被关注者，也就是订阅服务器消息，服务器上会保存一条关联记录。
假设一个生产者被10000个人关注，他只需要发一条消息到服务器，关注者从服务器上读取这条消息，但是服务器要向10000个关注者推送消息通知。
ps:我记得微博上是这样的，如果被关注者发布了一条新消息，这条消息会被放到服务器上存储，然后向关注者发送一条有新消息的通知，关注者需要刷新下页面才可以获取最新的消息。
生产者：生产者发布消息到消息服务器，消息以栈后进先出的形式存储，每个生产者的消息都有一个栈，那么服务器上就有一个生产者的消息列表。
消费者：关注被关注者，也就是订阅服务器消息，服务器上会保存一条关联记录。
假设一个生产者被10000个人关注，他只需要发一条消息到服务器，关注者从服务器上读取这条消息，但是服务器要向10000个关注者推送消息通知。
ps:我记得微博上是这样的，如果被关注者发布了一条新消息，这条消息会被放到服务器上存储，然后向关注者发送一条有新消息的通知，关注者需要刷新下页面才可以获取最新的消息。
#16
这个是消息队列的典型应用场景吧，发布/订阅。activemq、rabbitmq、kafka