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 对~