返回列表

关于一个高并发大数据的问题

默认分类 2013/11/06 00:11

Cindy_Lee 写道
你需要了解大数据高并发的瓶颈在哪里,一般都是数据库层面的,机械硬盘承载不起非常快速的读写操作,cpu承载不起大量的逻辑运算,所以最基本的解决思路就是:
1.换固态硬盘加快硬盘的读写效率。
2.建立缓存中间件降低对硬盘的读写次数,缓存不用多说了,最最最基本和重要的优化策略。
3.将硬盘的读写或者数据的计算分摊到多台机器上,也就是集群。hadoop就是基于这个层面的。
4.良好的查询算法,降低读的次数,分表,分库,索引等都是基于这层面的。

理论上来讲,在带宽充裕的情况下,只要遵循上面的4个思路进行延伸就可以解决大部分的高并发问题。

★海洋★2013-11-05 22:21:07
用户a去过1,2,3这几个地点,地点1,有用户a,b去过

★海洋★2013-11-05 22:21:07
这样a去过的地点数就是3,地点1有2人去过

★海洋★2013-11-05 22:24:19 当1个小时内有10W个人去过10W个地点时候,每个人看到的统计信息都是不一样的,如何解决像这样的高并发和大数据处理,帅哥,有什么方案么

广

★海洋★2013-11-06 10:17:16
目前的解决方案是自己写了一个简单数据库

王金华2013-11-06 10:17:13
memory db or file db?

★海洋★2013-11-06 10:18:29 前者,用C写的,使用连续内存保存等长数据(int)型,然后用指针扫

★海洋★2013-11-06 10:18:50 据说一秒能扫2G的数据

★海洋★2013-11-06 10:19:24 机器16核64G内存

★海洋★2013-11-06 10:19:52 缺点是不能横向扩展

王金华2013-11-06 10:19:32
好友访问过该地点的 逻辑是怎么写的啊?

王金华2013-11-06 10:19:53
为什么不能横向扩展?

★海洋★2013-11-06 10:20:50 这边自己写的.....,而且写的人跑路了,后面没人能改他的代码

★海洋★2013-11-06 10:22:33 数据结构是一张表addr_id1,uid1,0(没来过)/1(来过)/2(想来),uid2,0(没来过)/1(来过)/2(想来),.....

王金华2013-11-06 10:22:32
不清楚的具体的逻辑,横向扩展的要点就是服务对外无状态

王金华2013-11-06 10:22:50
我想想

★海洋★2013-11-06 10:23:23 定长用指针操作,减少定位时间

王金华2013-11-06 10:23:41
就是这个数据结构? 够简单

★海洋★2013-11-06 10:24:07

★海洋★2013-11-06 10:24:41 对的,复杂了就慢了,而且它增加列也不能

王金华2013-11-06 10:27:12
嗯, 那实现好友访问过该地点 loop users addr_id var user if user.visited loop friends var friend if(user == friend) print friend end end

王金华2013-11-06 10:27:32
大概逻辑是这样么?

王金华2013-11-06 10:28:17
如果这些数据是在内存中的话, 你们怎么将这些数据持久化的? 不能一直在内存里吧

★海洋★2013-11-06 10:29:50 一直放在内存里,定时 housekeep到磁盘

★海洋★2013-11-06 10:30:22 主要是为了处理大量高并发查询

★海洋★2013-11-06 10:31:25 如果数据量上去了目前只能增加内存,这终究不是长远之计

王金华2013-11-06 10:41:36
不是定时housekeep到磁盘么

王金华2013-11-06 10:41:53
应该可以腾出内存

★海洋★2013-11-06 10:48:27 是backup(Copy),没有move因为数据还会用

王金华2013-11-06 10:48:27
哦明白了

王金华2013-11-06 10:50:10
现在是要在这个基础上改呢,还是推掉重来?

★海洋★2013-11-06 10:51:01 推掉重来

★海洋★2013-11-06 10:51:42 要不然后面没法升级啊

王金华2013-11-06 10:51:27
你们那边架构师怎么说?

王金华2013-11-06 10:51:41
现在性能遇到瓶颈了?

★海洋★2013-11-06 10:52:37 架构师说你去问一下王金华吧

★海洋★2013-11-06 10:52:53 我就照办了

王金华2013-11-06 10:52:47
□。。。。。。。。。。。。。。

王金华2013-11-06 10:53:29
这个可以参考一下weibo啊

★海洋★2013-11-06 10:54:08 现在是很难增加新功能,而且一搞活动用户量一大就不稳定

王金华2013-11-06 10:53:49
主要的问题就是上面说的3个

★海洋★2013-11-06 10:54:31 目前看来是这样

王金华2013-11-06 10:54:22
然后写这个的人又跑了。。。。

王金华2013-11-06 10:54:26
哈哈

★海洋★2013-11-06 10:56:47 https://github.com/lqs/crabdb/

★海洋★2013-11-06 10:57:09 http://lqs.me

★海洋★2013-11-06 10:57:16 据说是去百度了

★海洋★2013-11-06 10:57:22

王金华2013-11-06 10:58:36
这就是现在用的db?

★海洋★2013-11-06 10:59:14 对的

★海洋★2013-11-06 10:59:50 现在是crabDB+mysql+mongodb+redis

王金华2013-11-06 10:59:56
倒是上面db都用啊

★海洋★2013-11-06 11:01:34 对啊,历史遗留下来的,每个都解决不同的问题

★海洋★2013-11-06 11:01:59 其中crabdb解决了,其他都还好办

王金华2013-11-06 11:05:25
明白的,这是你们的核心服务啊

王金华2013-11-06 11:08:47
你们现在打算怎么推?几个人来推?

★海洋★2013-11-06 11:12:01 打算先找到一种可以扩展的方案,就是通过加机器而不是单纯加内存来解决问题,大约有5个人

★海洋★2013-11-06 11:13:54 都木有遇到过这种问题。。。,和百度那边用的也不一样

王金华2013-11-06 11:13:51
这么看下来应该还是使用开源的东西啦

王金华2013-11-06 11:14:10
自己写的东西,维护和扩展都是个问题啊

★海洋★2013-11-06 11:15:37 对啊,只是开源也有一定风险担心不稳定,又不像linux用了几十年了

王金华2013-11-06 11:15:53
建议你先找点 weibo 和 twitter的资料看一下

★海洋★2013-11-06 11:16:49 好主意~

★海洋★2013-11-06 11:17:14 我先看看他们的解决方案研究一下

王金华2013-11-06 11:17:00

王金华2013-11-06 11:17:10
我也回去看看

★海洋★2013-11-06 11:18:02

王金华2013-11-06 11:18:03
再想想,如果能顺利解决这个问题,基本再遇到大数据高并发,也就有思路了

★海洋★2013-11-06 11:19:17 对~