一次关于知识储备的思考

 

事情的通过是这样的：

一个夏日的午后，我在啪啪啪的敲代码，正爽着呢，老大在背后拍了拍个人肩膀，说让我写个功能。

我说啥功能，他说：“operate 模块那边每次收到文件都会给你发一条消息。而后对消息进行计数，每隔一段时间，你把这个计数写入一次数据库。”

 

我说为何。
老大说对文件数量进行计数。

 

我说为何不让他们直接去更新数据库。
他说 operate 那边是多线程，数据量比较大的时候，同时更新数据库会出问题。因此须要经过消息队列，把数据都汇总到你这儿，你来统一更新这个数据。

 

大概意思我听明白了，我说行，我作。

意思应该是这样：operate 那边是多线程处理数据，而且是多个线程共同维护同一个数据库的某个统计字段。在数据更新比较频繁的时候，数据会出现错误。

我猜应该是同步没作好。可是为何没作好，我不知道，部门多了，产品复杂了，什么状况均可能出现。老大让这么作，那就有他的道理，既然是和其它部门商议后的结果，这个方案确定就肯定了。

 

和老大商量后，个人工做是这样的：建立一个线程出来，获取数据库中统计字段的当前值，监听发送给个人消息，而后累加这个值，每隔一段时间（暂定5秒）更新一次这个值。

开始写代码的时候在想，为何要把这个数据取出来，而后再加上一个数字，而后再放回去呢？为何把更新一个数字的过程分红三个部分呢？这多麻烦啊。我印象中好像在《深刻浅出MySQL》这本书里看到过，mysql 中能够写表达式。不过平时没怎么用过，就去一个MySQL的QQ群里咨询了下，网友们都很热情，在逗图和吹牛逼的时候还顺便回答了我这个问题。

若是咱们要更新的字段是 sum ，那么就能够直接写“update table_name set sum = sum + 5 where id = 1;”就能够了。而后我 就把这个状况告诉老大了，老大说你测试下这个方式是否是线程安全的，还有测试下多线程下的效率。

我写了个程序，测试了下效率，也查阅了咱们使用的MySQL引擎的文档，在咱们的开发环境下是线程安全的，效率也让老大看了，他以为还能够接受。而后，而后他就找 operate 部扯皮去了。

由于这样更新数据，是线程安全的，因此当 operate 模块是多线程的时候，使用这个方式更新数据，就不存在线程同步问题了。也就不必让我再拉个统计线程出来了。

 

老大说更新数据库的部分让 operate 来作，operate 的人确定是不情愿啦。他们说，既然已经这么定了，就得这么作，咱们的都快收尾了，你又让咱们改这个。
老大说这么作太复杂了，大家直接更新会更简单。他们反问我老大，说：“既然这么作简单，你干吗一开始要那么搞呢？”。老大愣了两秒钟，很愤怒的说：“当时没人告诉我能够这么作啊！”。

后来两个部门又开了个会，通过一天的扯皮，更新统计数据的部分，成功推给 operate 部去作了。后来我发现， operate 的东西其实并无收尾。

 

嗯，故事讲完了，说说个人感觉。

首先，在听到老大的愤怒后，我第一个想到的词是，知识储备。

至少从我刚刚经历的这个事情来看，知识储备是很是重要的事。虽然就是一个SQL语句的事儿，但是不知道这个用法的话，就真的会把东西弄复杂了。因此平时没事的时候还真应该多读书，多学习，增长本身的知识储备，指不定在哪天就用到了呢。

第二点就是对事物审慎的态度。
在我告诉老大，我发现了一条真理的时候，他没有让我直接去用，而是让我检验这个真理的安全性和性能如何。

这个也是很重要的。估计要是个人话，直接就用上了，万一真的是性能达不到或者不支持线程安全的话，前面的工做估计也白作了。因此在接触一个新东西的时候，应该先全方位的考察下这个东西是否是真的能解决眼下的问题，而且不会带来新的问题。要是不能的话，那就宁愿不要用。

 

---

 

同步发表于：http://www.fengbohello.top/blog/p/knowledge-reserve