4岁的小孩子，每天读10分钟的三字经，一两个月下来，一本三字经居然从头背到尾了。让我这个成人不免惭愧。

然而真的是像科学家说的成人记忆力衰退了? 还是我们与小孩的记忆模式不同？

我胡诌了下面的说法：

小孩子的大脑，是像余量充足的硬盘，每天少量接受的一些信息，他能挑选性的存到这个硬盘里； 成人的大脑，像是繁忙的内存，每天处理着大量信息，然而多数是稍纵即逝，关机就消失，很少有最终能存到硬盘的。慢慢的也习惯了这种暂存内存，忙忙碌碌的模式。

Service agent (SA) 这个项目与service manager (SM) 集成经历过两种方案，一种是直接与SM的数据库进行集成交互；另外一种就是面向服务的集成，通过SM提供的SMRWS API服务进行交互集成。我概括地称之为直接面向基准数据源的集成设计(SA->SMDB) 和面向服务的集成设计(SA->SMRWS->SMDB)。

问题

今天遇到一个面向服务的集成设计的问题，SMRWS的主从web servers的cache数据出现同步了问题，导致SA连接SMRWS获取的信息不准确，有一个场景就是我们通过SMRWS来验证用户权限，因为获取的信息不准确导致我们误判用户不再存在于SM源系统，进而删除了用户在SA系统的权限。

结果

作为下游系统的SA这种情况下显得格外尴尬，用户抱怨SA系统的可用性和稳定性。

反思

作为面向服务的下游系统，必须考虑外接服务的不稳定性，提前做好准备，进行一些异常应对， 比如当对方服务无法连接，要让本系统通过本地缓存保持”off-line” 继续工作。 当然对于上述的那个因上游系统的问题，导致本系统逻辑上的误判 (到底是用户真的不存在于上游系统背后的数据库了，还是因为上游系统出现了同步问题，这个需要和上游系统就关键逻辑场景进行标志，比如当上游系统的cache出现同步问题时候，需要在API返回结果里进行标识)。

随时过期的技术文章

在网络上搜索最流行的三大web服务器的对比，看到一些2014年的博客(比如http://yanguz123.iteye.com/blog/2055589），言之凿凿地做了一些表格化的对比整理。其中就有一项说nginx 不支持 sticky session. 还算比较有怀疑精神的我，当即表示怀疑最新的版本里nginx 是不是像这篇文章里所述仍然不支持sticky session.

于是去google搜到一些nginx官网的文章链接1 and 链接2 证实nginx 已然支持 sticky session.

My Point

写这篇的目的不是为了责难一些过往的博客，毕竟人家把自己当年学习的经验进行了总结和分享，特别值得肯定。 我想说的是技术本身一直在发展，一些技术文章和知识会过期。当你第一次学习某个主题的技术时，除了要了解他的历史，更重要的是知道他最新的样子。

My Suggestion

当你学习某个主题时( 比如nginx)：

1. 经常光顾官网的document, wiki
2. 买最新的出版的这个主题的书籍
3. 网络blog里的过往的文章当成历史去读，一定要自己加以验证。
4. 不要转载别人的文章的内容，建议只引用原始文章标题和链接。（理由： a. 转载后的拷贝版本是死的，不能获取到原作者对老文章进行的最新的修订。b.减少网络资源重复，创造绿色环保的网络）

图片类

台北故宫博物院免费图像

Why I write blog

The bottom line of morality

1. Don’t write advertorial. 拒绝软文，浪费时间
2. Don’t cheat readers. 不欺骗读者

The intention

1. Share experience in life. 分享生活经历或体会
2. Share experience of work. 分享工作中的经验