我们终将成为我们嘲笑的人

此文发布在博客园上，当然说的都是IT的事。

　　去年，在一汽车金融公司做内部网站，其中就发现一个奇葩的现象：发布一辆车源，后端服务返回成功，但是从数据库查询却查询不到结果，等待几分钟后，再查询就有结果了。这是多烂的程序，出现这种bugs。再加之服务器端是之前.net1.4时代，用vb写的，鄙夷之意顿生。所以找想相关的人去解决，告知后端有个队列，不是直接入库，所以问题解决不了。那没办法，是内网的系统，而且使用频率不高，那就用使用者忍忍吧。服务器端在优化下，尽量直接入库，反正后来优化到5秒多钟，算是解决了。

　　去年下半年，为了追赶行业潮流，换了另外一个汽车行业公司，但是改做手机服务器端。到这发现，发车也是用队列做的？why？而且用队列实现的地方还很多，比如用户登录的时候记录用户登录信息，用户出错后，记录的日志，都是异步发向队列的，之后直接返回。后来发现消息队列其实是挺主流的东西，当数据量过大的时候，这样能提高程序相应性能，减少数据库压力等等好处。只是自己见识短而已。

　　之后再程序设计中，出现一个需求。客户端（client or app）需要对新消息进行提示，可以对于不同的客户端显示不一样。（也就是这数据不存在服务器上，而是存在客户端就行了），原有示例中是服务器端每次调用借口都返回最后（最新）的一条的时间，然后看这次返回的最后时间和上次是否一致，以判定是不是存在最新。看到这个设计，又忍不住笑。这种设计多笨啊！！客户端有时间，每次调用的时候，客户端把时间给服务器端就行了，反正不同客户端显示不一致是可以的。而且这样客户端也不用存储这个时间。but，问题出现了，客户端时间和服务器时间可能不一致，有些条目原本人家已经看过，但是由于客户端时间比服务器端时间晚太多，所以下次还是显示成未读（有新消息），好吧，这是我的失误，那我用服务器端时间，我不用查数据库，总比你查数据库取最后一条好点吧。再But，测试的时候出现问题了，还是原本看过的，依旧显示成未读？这是why？？？经过多次排查，千辛万苦，找到了答案——入库的时候时间是数据库服务器生成的，而查询的时候是服务端服务产生的时间，而数据库和服务不再一台机器上，时间不一致！！！生产环境会这样吗？也许不会但是保不准，而且生产环境有n台服务作的负载，他们之间会不会有时间差。怎么办？蓦然回首，那人却在灯火阑珊处。我用原来我嘲笑的方案，不就perfect了吗？

　　自古文人相轻，现在程序员亦是。.net、java、PHP、JS纷争能几时。他山之石，可以攻玉。今天你所嘲笑的人，明天或许你就会成为他。哎。前人为之，后人不解而笑之；后人复为之，后后人不解而复笑之。