第四周小结
一周的时间过得很快，做得事情却很少。周一处理了一个线程间signal处理时间窗口的问题，周三处理了一个代码function logic的问题，周四分享了一篇Pingmesh论文，周五处理数据一致性的问题仍然没有结果。期间，还抓紧时间补充了一些覆盖率，脑力工作一周下来所做的结果，看着少得很。
马上也到月底了，计划本月内把线性代数一书看完、看懂；现在审视一下，发现书本看完了全书的80%，掌握到手的知识在40%，剩下的四五天应该够把其余40%再掌握到手。当前来看，线性代数课本剩下20%的内容怕是难以在本月内看完了，只能计划放到2月份里、第一周内看完了。计划有偏差了！还有一点需要说的是，这个月内就只阅读了一篇论文。与年前所作的计划，仍然是有偏差的。好的习惯要坚持，不能够丢弃，许多东西一旦丢弃了，就很难在拾回来的。
这周投入问题单的时间是比较长的，也看出来，数据库中关于数据一致性的问题，解决和分析的难度、代价都是比较大的。主要体现在几个方面：
- 复现代价大。 数据一致性的问题，很多是概率性的，或者说是难以找到一个必现的条件的。在没有弄明白根因之前，许多问题要依赖黑盒复现，涉及到了并发度、数据量、集群规模、时间窗以及故障模拟等。有一种瞎猫抓老鼠的感觉。有的时候，换一次编译、换一个机器，它就可能不再出现，或者复现的时长要比前几次要更长了。
- 分析代价大。 正是因为复现代价比较大，又没有头绪，所以出现一次之后，很难拿到一些关键的、重要的、有用的信息。只能在现有的信息中进行有限的推理和猜测，然后修改代码、增加日志、增加断言，盼望着下一次复现的时候，关键的线索可以体现在新做的修改之中。倘若不是的话，又只能再次进行分析和推理，在已有基础上进行增强和修改，循环复现、分析这两个过程了。
- 解决代价大。 如果确实是一个代码实现上的漏洞，那么，解决代价要小得多。倘若不是，是整个框架上或者基础设施上的缺陷，那么就比较麻烦了。如何可以规避问题而又不引入新的问题，在二者之间做一个tradeoff，这是一个大的学问了。不好的话，就会引入大量的hack代码，形成一个破窗效应，慢慢腐化了。
偶然间看到了ARIES论文的中文论述版本，准备在一个月内把这篇论文再看一遍的，顺手也把Github关于它的中文翻译弄完。 数学知识属于工具，先能够知道、理解就好，深入的掌握可以慢慢来。在我的计划中，2月份会开始看概率论那本书，最后再是高等数学；期间，其他方面的书也会同时看着。
这个周是1月份的月末周六，下周是2月份的月末周六。用一天的时间调研了一下关于c、c++函数backtrace方面的实现方法，大多是使用glibc提供的如下几个函数来实现的：
- backtrace, 用于获得调用栈的函数地址；
- backtrace_symbols，依据传入的函数地址来获得函数名称；
- abi::__cxa_demangle，对于c++的话，主要是把符号反解成对应的函数，可以应对重载问题。
有如下两篇文章写得不错，也主要是参考了下：