14
回答
大家对大数据量 高并发处理有啥见解?
利用AWS快速构建适用于生产的无服务器应用程序,免费试用12个月>>>   
大家对大数据量 高并发处理有啥见解?
<无标签>
举报
共有14个答案 最后回答: 11个月前

一般情况,

 在没有数据的情况下,或者没有见过数据 

就开始考虑大数据量的问题

根本知道什么叫做并发的时候

就会开始考虑大并发的问题


什么时候应该考虑大鸟的问题

首先应该有一只鸟, 很小的鸟, 

然后考虑怎么变大鸟, 再去考虑大鸟的问题

一个开始就谈大鸟的

基本上都是什么鸟都不懂的人

       也没那么多的数据量.  对于高并发, 多台机器就OK了.   一致性和分布式的矛盾倒是可以讨论下,不过也就那么回事.  媒体,新闻总是在造神, 就象初中懂点小歪招的黑客就能渲染成超高智商, 精通IT技术, 精英人才. 吹的好像 即使是拉面馆招了他, 拉面馆的GDP都能瞬间暴涨几百倍一样. 人类社会的道理都是类似的.
      如楼上所说, 有多少数据量就使用怎样的方法, 就象oschina, 只用一台服务器就搞定了.玩集群,玩hadoop,  就象去找邻居玩 却要开车去一样. 自寻烦恼,增加RPC时间,除了降低性能外没什么实质上的好处.

如果我有个服务器,接一个点,可以获得1K的的数据,那么我们把网络的东西折腾折腾,让100万个点,无论过多少路由,或中间缓存服务器,最终落到这个服务器里,那么一天就是1个G的数据。那么365天,就是365G的数据。这个就叫大数据。

如果一个服务器,一个时间,可同时挂10个客户端打数据,那么100万个点,我们用1000台前段服务器做收集,每个服务器承接1000个客户端。要求不搞,集齐到1M的数据(一天时间吧),给后端分100K打10次,那么这1001台服务器,我们可以说是在一天内,有100万的并发。

你当并发一定说是同一个时间?这年头,时分复用的方案比频分复用的方案多很多。

是人都说大数据,高并发。但认为没什么难度的不多。说有难度是因为只看到裸女,没看到骨头。

引用来自“Lunar_Lin”的答案

       也没那么多的数据量.  对于高并发, 多台机器就OK了.   一致性和分布式的矛盾倒是可以讨论下,不过也就那么回事.  媒体,新闻总是在造神, 就象初中懂点小歪招的黑客就能渲染成超高智商, 精通IT技术, 精英人才. 吹的好像 即使是拉面馆招了他, 拉面馆的GDP都能瞬间暴涨几百倍一样. 人类社会的道理都是类似的.
      如楼上所说, 有多少数据量就使用怎样的方法, 就象oschina, 只用一台服务器就搞定了.玩集群,玩hadoop,  就象去找邻居玩 却要开车去一样. 自寻烦恼,增加RPC时间,除了降低性能外没什么实质上的好处.
这是大实话。哈。其实关键在于 @宏哥 说的业务。当业务需求不得不要处理大量数据,而我们使用更复杂的整体系统时,会引发一些列和大数据,高并发,没有直接联系的问题。解决这些问题,往往是主要工作。而这些工作本身由受业务的特性,各有细节偏差。但成败在细节。通常这些细节是团队竞争力的地方。不是 COPY来COPY去就学会的。

引用来自“中山野鬼”的答案

引用来自“Lunar_Lin”的答案

       也没那么多的数据量.  对于高并发, 多台机器就OK了.   一致性和分布式的矛盾倒是可以讨论下,不过也就那么回事.  媒体,新闻总是在造神, 就象初中懂点小歪招的黑客就能渲染成超高智商, 精通IT技术, 精英人才. 吹的好像 即使是拉面馆招了他, 拉面馆的GDP都能瞬间暴涨几百倍一样. 人类社会的道理都是类似的.
      如楼上所说, 有多少数据量就使用怎样的方法, 就象oschina, 只用一台服务器就搞定了.玩集群,玩hadoop,  就象去找邻居玩 却要开车去一样. 自寻烦恼,增加RPC时间,除了降低性能外没什么实质上的好处.
这是大实话。哈。其实关键在于 @宏哥 说的业务。当业务需求不得不要处理大量数据,而我们使用更复杂的整体系统时,会引发一些列和大数据,高并发,没有直接联系的问题。解决这些问题,往往是主要工作。而这些工作本身由受业务的特性,各有细节偏差。但成败在细节。通常这些细节是团队竞争力的地方。不是 COPY来COPY去就学会的。

其实核心问题就是大多人把" 业务" 狭隘化了

其实分开了就明白了

顶部