数据量很大和很小的情况下编程有什么区别？

09年刚进搜狐的时候，只有半年多的工作经验，完全不懂什么叫做高并发，什么叫做大数据。
入职产品技术中心，接手视频的模块，就做了一个最简单的功能。

用户点击视频的时候，视频点击次数+1.
用Memcache做缓存。

这TMD已经是简单的不能再简单的操作了，但是改完发布上线之后，他们发现视频的点播次数会出现倒退的情况。
就是本来点播次数已经是18834了，点击一次播放，没有变成18835，反而变成了18830.

心都碎了。完全看不出代码错在哪里。
后来各种调试，看日志，慢慢看出点门道来。

第一次感受到什么叫做并发。当时每秒并发好像有100多还是200多？不太记得了，一些热门的视频播放次数比较多，而且当时还支持转到QQ空间什么的播放。

就看到日志里记录的点播次数完全是乱的。
完全是乱的！

想了好久才想明白，NND，从Memcache里取数据是需要时间的，这个时间是几MS我不记得了。
我最恨画图：
总之单个用户访问的时候是这样的


1.用户A点击了一次视频==》从Memcache取数据，如10086
2.用户A做+1操作=》10087
3.用户A保存进Memcache=》10087


不要问我为什么用Memcache，而不是直接用DB。

这是一个非常非常简单的逻辑。



多个用户访问的时候是这样的。

1.用户A点击了一次视频=》从Memcache取数据，如10086
2.用户A做+1操作=》10087
3.用户B点击了一次视频=》从Memcache取数据，仍然是10086
4.用户C点击了一次视频=》从Memcache取数据，仍然是10086
5.用户D点击了一次视频=》从Memcache取数据，仍然是10086
6.用户E点击了一次视频=》从Memcache取数据，仍然是10086
7.用户F点击了一次视频=》从Memcache取数据，仍然是10086
8.用户G点击了一次视频=》从Memcache取数据，仍然是10086
9.用户H点击了一次视频=》从Memcache取数据，仍然是10086
10.用户A保存进Memcache=》10087
11.用户B做+1操作=》10087
12.用户C做+1操作=》10087
13.用户B保存进了Memcache=》10087
14.用户I点击了一次视频=》从memcache取数据，数据是10087
15.用户I做+1操作=》10088
16.用户I保存进Memcache=》10088
17.用户C保存进Memcacche=10087


你们看明白没？
坦诚的说，我是一脸的懵逼，完全不知道该怎么处理，后来是申总教我用锁。
嗯。说起来那个时候Memcache如果直接有原子+1操作就好了。

还用到了concurrentHashMap等等。



马丹，传不了图。就这么着吧。
求也没用，渣渣网络传不上去图。


简单来说就是在把数据取出来，又回写进去的时间里，恰巧有其他的用户也获取数据，写进去。
出错就在这几MS的网络传输上。


这就是所谓并发的含义。在单个线程里不会出错的逻辑，在并发的情况下成为了一个明确的漏洞。
这也是为毛要加各种锁的原因。



除此之外，没过多久，我需要对数据库建索引，DB也不大，也就是几千万条数据。
马丹我年少无知，压根不知道那是线上数据库。

用了Navicat连上之后直接点了建索引。

So。剩下的事就不说了，瞬间公司全炸了，视频下面的页面都打不开。

我仍然一脸懵逼，后来才知道原来TMD几千万条数据建索引跟几十条数据建索引的时间根本不是一个量级的。

也根本没考虑过不锁表建索引的方案。

后来鹏哥过来了问我怎么能大白天在线建索引，我一脸无辜的说我不知道这是线上数据库。
还在心里默默的补了句我也不知道建索引要这么久。


一个是很简单的视频播放数+1，一个是很简单的DB建索引。
小数据量， 无并发的情况下随便你玩儿。


这两件事都是差不多我入职一两个月的时候发生的，也非常感谢搜狐的包容，做为当时三大门户网站之一，搜狐当时的同事非常非常赞，跟他们学到了很多很多东西。

不过那时候搜狐没有QA，没有运维，全靠工程师自觉搞定。
到后来做白社会的时候更是神一样的速度和效率。

离开搜狐之后，根本就找不到像当前的同事一样有职业素养，技术好，又负责的同事。
没办法只好通过各种流程来确保线上故障不发生。

所以我一直都在想，有多少程序员有幸能接触到这些顶级的工程师？能接触到大数据，高并发的业务场景？

我见过3~5年工作经验的人都不知道日志如何打，出了线上故障不看日志纯靠猜。
互联网之所以能推动技术快速发展，应用场景是非常非常重要的因素。


这就是自己做练习和真正做项目的差别吧？
代码要求严格的时候，项目名，函数命名，包路径，哪些要写单元测试，哪些不要写，都是要统一的。
自己写的时候哪会注意这个？



==========再补充一段====================
1.08年的搜狐产品技术中心，确实是没有QA，没有运维的。在白社会项目开始了一年之后，似乎都没有QA和运维，我不记得了。白社会的是一个60多人的产品技术团队协作项目，现在我都很钦佩能够带领这么多工程师在3个月之内内测上线，6个月之内正式上线的Mark。没有QA去做验证，我只能说当时的搜狐工程师很强很强很强很强。在之后我带的团队中，没有QA的话。。。

2.我进去的时候不是实习生，是正式员工。
3.进去的时候只有7个月的工作经验，等会列一下当时会了什么东西就进了搜狐。
4.搜狐当时的很多牛人，最佩服的元涛，中兵，小刚，胡伟，吉子，琳姐，申总，都是我见过的最优秀的工程师，根本不存在各种各样的现在纠结的问题。现在可惜都散落在各家公司做高级架构师和CTO去了，还有经常在百度，新浪，阿里，滴滴，腾讯，京东等各家公司打转的。
5.那个时候memcache用的是比较多的，MQ是后来在白社会里才用到，也是踩了不少坑。


简单说一下当时我的技术水准，也给你们一个参考。

硕士期间基本上没怎么写过代码，全部是去写论文了，加上本科是计算机网络，又是自考，跟写代码基本上不沾边。

所以，基本上所有的编码经验都来自于毕业之后的，当时我只做过两个项目，一个是内部的CRM系统，做了差不多3个月，学会点皮毛，Spring，Mysql，JDBC，hibernate,jsp，js,html，eclipse,tomcat。
跟着做了一个短彩Wap的项目，学会了Maven,WebService,shell,memcache。

那个项目是电信项目，每个省一套独立的版本，每个省都有自己的接口，每次改东西特别麻烦。
当时做的时候就觉得这么做不对，之前看书的时候，看到过一点点设计模式，所以就尝试跟主管沟通。

可不可以我们在内部统一用一套Model，将所有外部各省不统一的名字，都映射到我们自己内部统一的Model里来。

这样，如果再变的话，也只是变外面的接口部分，这部分代码无论未来有多少省变更或者是接入都可以。

我们自己内部的处理流程基本上不变了，就不用在一个项目上打30多个分支，每次修Bug的时候都不知道哪个分支该修复。

但是当时的主管完全不理我，也是因为这件事儿，怒而辞职的，都不知道搜狐怎么找到的我。
反正当时也是海投和瞎投。

面试的时候我记得很清楚，琳姐和Mark分别见了我，问我期望薪水多少。我说我当前的薪水是5K，期望是6K。琳姐和mark都没说啥，刚面试完，HR打电话跟我说，给你6.5K，另外还有绩效奖，比你的预期要高很多。

当时瞬间就明白了自己好傻，马丹一定是我要求的薪水太低拉低了说出去太丢人了。
琳姐说，当时有很多人经验比我丰富，水平比我高，但是琳姐说我讲东西的时候条理清楚，思路清楚，所以才让我进来。

嗯。还记得琳姐说了，基本上搜狐的工程师都是一年左右成长起来的，她也希望我能够在一年之内能独挡一面，然而一年之后因为各种原因我走掉了。
现在想想，还有哪家一线公司的Leader愿意拿出一年的时间去培养一个新人？只是当时太不懂事儿，根本理解不了。直到后来自己花了很多心思去带团队，看到自己带起来的人一个个的离开，一个个的成长，才慢慢体会到一点点在当时，决定让一个新人去搜狐意味着什么。

当时一个组是6个人，我是最菜的，嗯。
所以业界一直在说搜狐是IT界的黄浦军校，我是百分百赞成这一点的。

只是，可惜，嗯。
搜狐的白社会也是我见过的效率最高，代码质量最高，Bug几乎没有，引入新技术最多，产品体验最好的产品。

现在已经被抛弃掉了，登上去之后基本上各种功能都不能用了，还是会偶尔登一下，偶尔会跟朋友说，看到没，这个是我做的，这个是我做的，这个还是我做的。

==========再补充一段==============

后来我在自己搭建团队的时候，基本上都很注意带新人。
我一直都觉得，水平有高有低，基础有强有弱，态度必须好。

如果你是一个新人，你自己都没有一个想要去努力，成为一个技术大牛的心愿，别人怎么可能帮你做这些事？
很多时候，并不是别人逼着你做东西，而是你感受到他们职业的态度。

多数公司都是架构师来说这个项目怎么做，然而搜狐产品技术中心的策略就是所有的方案设计都是由工程师发起，谁负责这个模块，谁来负责这个模块的所有设计，从DB到缓存到架构，到技术方案的细节，leader们只负责做评审。

所以当时的氛围是，身边的技术大牛们特别High的说我要用这个方案那个技术来解决这个问题，你看Facebook他们就用了这个，Myspace用了这个，Twitter用了这个，为毛我们不能用？

再不然就是这个开源框架不好，有缺陷，我们要自己来一套，很简单，很容易，没什么风险，你看我Demo都做出来了。

其实之前的贴子中也写过一些细节了，毕竟时间太久了，我自己也可能会记错。
这次回答的时候，也是刚好前几天跟知乎的一群{XX}骂了街，多写点平静一下，顺便也给那些新入门的程序员提个醒。

项目很重要，说一个项目成就一批人根本不为过。
无论是微信，还是微博，还是滴滴，或者是京东，都是靠着解决的应用场景成长起来的。

然而大部分应用都很难有大数据或者是高并发的场景，其实解决方案都是大同小异的，只是你能不能真正上手感触一下。

比如说，之前足迹服务器瘫痪的时候，金山云的朱桦带队支持，印象中是两三周就对整体架构做了优化和调整。

这些东西说难不难，就看你能否真实的接触到。

这想，这就是我希望能够对这个问题贡献的价值。