真的有这么多大数据高并发分布式的程序要搞吗?

OSC688888 发布于 01/11 13:55
阅读 1K+
收藏 0

最近准备找工作,看了下要求,占比非常大的一部分都是大数据,高并发,分布式,真的有这么多流量么?

简历里面没这几点都不好意思投,像我们这种搞应用需求开发的,天天就是搞产品的需求,哪来这么多这些经验,公司只想你赶紧把东西搞出来。

加载中
4
非常路过
非常路过

互联网有并发要求,传统项目有大数据需求,搞架构师还是要懂点的,分布式环境下带来的问题挺多的。开发岗位没有这么多要求,但面试时嘴巴要会,用来体现个人NB性。算法也是,嘴上要会讲,写不写得出来是另一回事。

Gfast开源-qixun
Gfast开源-qixun
过来人。。。
freekevin
freekevin
nice
1
小呆呆的星空
小呆呆的星空
这个主要看做什么类型的系统,像是智能家居平台的,一个设备每秒上报一次数据,上万个设备,不就是高并发加大数据加分布式咯。
小呆呆的星空
小呆呆的星空
回复 @kakai : 俺属于抛砖引玉了:sunglasses:
kakai
kakai
长连接上万个设备上报,这个算不上高并发,nio、aio连接数单机都破十万、百万了,一台单机上万的连接不成问题,出现高并发的唯一资源竞争就是写入数据库了,要么分库分表,要么使用消息队列消峰,这种架构挺简单的,日积月累,大数据还是算得上。
z
zb1513749907775
那不是高并发 仅仅一个insert 需要时序性数据库 一秒能插入10W+的数据库
freekevin
freekevin
我们IOT 5G 物联网 都是这种场景
0
z
zb1513749907775

其实并没有那么多,小公司哪有那么多的业务

0
却又让幽兰枯萎
却又让幽兰枯萎

哪来的那么多的大数据并发分布式需求嘛,都是搞噱头,拿我们公司来说搞运维,有的大的客户监控1~2千台设备,每天存历史最多2个多G,采用hbase或者mysql,这是存历史的部分,就这个量级的数据还是经常出问题,这种问题都是公司自己对应自己的情况解决,没有标准答案;还有就是itsm工单,采用云的方式,有十几个单位在用,使用mongdb存储数据,到目前为止还没有出现过什么并发呀,数据量过大的问题,随便用,真正是出现什么并发场景同步影响性能的东西那公司的体量就相当大了,那些要求什么大数据呀,并发呀,分布式呀,基本上就是什么技术新就套什么,完全不考虑部署的难度呀,网络开销带来的性能下降呀,分布式系统组件过多不稳定呀,就纯属装个B,为了使用而使用

0
杰克伦敦尘
杰克伦敦尘

我手头有个系统,接手的时候已经上线运行了几年。有个表拆分成 100 个表,运行超过10年,所有表数据量加起来不超过 200 行。

软件设计,真不能太超前、太脱离实际。

现在看到某些国内大厂技术文章,反复谈分库、分表,我有拿榔头敲他的冲动。

杰克伦敦尘
杰克伦敦尘
回复 @kakai : 不该分表、分库的时候,做了分表、分库,只能说水平很差了。 就像北京到天津,有近路不走,非要走一趟非洲,如果没有特别原因,只能说是笨。
kakai
kakai
分库、分表现在来说轻而易举,随便用个sharding-jdbc就搞定了
0
10进制宇宙
10进制宇宙

西安一码通招聘的人估计就是抱着你这种想法,结果你看西安一码通挂了没有。

 

西安一码通刚做的时候能预料到有一天会有这么高的并发量? 年轻人,这东西事先是不知道的。并发量高不高根本不是技术问题,是产品能否推向市场,是个企业运营问题。

0
F
Francesca

大公司大项目上这些东西很正常,小公司小项目也盲目上大数据高并发就是来搞笑的了,跟风而已,100个人用的东西上集群,离谱

0
sprouting
sprouting

不知道你待的是什么公司,我待过的公司,不搞点分布式、高并发根本无法解决

终究还是要看公司的业务的,同时,如果你是架构师,你都不了解这些东西,那你怎么能解决相应的问题,用不用的到是一回事,知不知道又是另外一回事了

OSCHINA
登录后可查看更多优质内容
返回顶部
顶部