随笔（2015.08）

1. 对于程序，需要考虑每个函数的返回错误，是否需要对错误处理。

2. 分布式事务强一致性的尽量避免。分布式事务有X/Open组织提出的分布式事务的规范XA，XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。

   分布式事务分为两阶段提交与一阶段提交，两阶段提交对一致性要求较强，（XA规范为两阶段提交）但对系统消耗较大。第一阶段为准备阶段，“准备阶段完成了几乎所有正式提交的动作，有的材料上说是进行了“试探性的提交”，只保留了最后一步耗时非常短暂的正式提交操作给第二阶段执行。)”，这里说“耗时非常短暂”我理解应该是“失败概率很小，处理简单快速”，因为为了保证一致性，所以“成功率”是关键。第二阶段为提交阶段，“参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)”

   “将提交分成两阶段进行的目的很明确，就是尽可能晚地提交事务，让事务在提交前尽可能地完成所有能完成的工作，这样，最后的提交阶段将是一个耗时极短的微小操作，这种操作在一个分布式系统中失败的概率是非常小的，也就是所谓的“网络通讯危险期”非常的短暂，这是两阶段提交确保分布式事务原子性的关键所在。（唯一理论上两阶段提交出现问题的情况是当协调者发出提交指令后当机并出现磁盘故障等永久性错误，导致事务不可追踪和恢复）”

   两阶段提交也不能完全保障完全的一致性，如在提交阶段出现问题（很小，但有可能），所以有时候需要额外的机制来保障一致性。例如补偿机制，日志记录等，如宕机后重启，会根据日志或其他机制，继续完成提交阶段的任务。

   两阶段提交中锁资源的释放是在事务完成的时候才释放的，第一阶段中占主锁之后会一直持有，也就是说系统性能的“消耗”会浪费在第一阶段提交交互的网络通信上。如果第一阶段中不占用锁，做完“预提交”之后把锁释放，那么可能在第二阶段到来之前，其他“事务”把第一阶段的“预提交”资源给修改掉，那么可能就会造成不一致的问题了。两阶提交因为长时间占有系统资源，所以可能会给系统的吞吐量造成极大的下降。

   这里对于锁（资源）的占有需要注意，同一个事务（走相同流程）不要并发的操作，既然是事务，必须第一个处理结束之后在处理第二个，中间的任何操作也是，都不能并发。例子多个客户端设置预置位到设备，协议从客户端到中心，消息分发线程回调处理消息，异步发送协议给接入，接入写入设备，更新接入内存，返回协议给中心，中心更改数据库，返回结果给客户端。这里有问题的就是中心异步发送消息这一步骤，没有任何同步处理，那么如果多个客户端第一个设置名字为p1,第二个为p2，第一个先发，第二个后发，因为是异步操作所以后面的就不能保证了，有可能给先处理p1消息，在处理p2消息，但是先返回p2消息，在返回p1消息，这个时候数据库中为p1,但设置到设备为p2。

   “解决分布式事务的最好办法就是不考虑分布式事务。
   拆分，大的业务流程，转化成几个小的业务流程，然后考虑最终一致性。”

   “淘宝之类的网站一般的做法是，如果4个都成功才算成功，那么这次提交时4个写都设置成一个中间状态，先容许不一致。然后4个执行完成了以后，回调或是定时任务里检查这4个数据是不是一致的，如果一致就全部置为成功状态，如果不一致就全部置为失败。”
   http://blog.csdn.net/bluishglc/article/details/7612811
   http://blog.csdn.net/kimmking/article/details/43197665

3. 工作中保持思考的状态，阶段性总结，最好每天总结一次，长的阶段性容易遗漏问题。遇到过什么问题，以后是否会出现这种情况？工作流程是否有可以改进优化的地方？工作习惯什么地方不好？Keep thinking.

4. 维护一个已发布版本的功能时候发现的问题：
   1 . 文档不全，侧重点错误。文档中写的最详细的是给用户看的，其次是给项目经理看的，最潦草最简单的就是给程序员看的，而往往开发维护人员面对的问题是最复杂的，涉及到详细业务流程，各种异常的处理，复杂的协议交互流程，而这些如果没有详细的文档说明，很可能开发维护人员只能从代码中去反过来读业务。如果代码中在没有注释，那么可能理解起来就非常困难也容易出错。
   ps: 上面的问题也提醒自己，以后开发项目时候，有必要写清相关项目中新增的需求，需求中涉及到的业务，具体的业务流程，协议交互过程，开发过程中及以后维护可能遇到的陷阱，新增的代码如果可以最好配上svn路径。这些文档一是给自己读的，二是给以后维护人员读的，具体分几个，什么格式没有必要硬性要求。不要为了写文档而写文档，不要一整片文档下来几十页，有用的就几页，不好检索。文档与代码一样也是个持续维护的过程。
   2 . 工作流程上问题。必须清楚的确定目标，是只修改一个小的功能就完了，还是说整个版本需要来维护。如果只修改一个小的功能，那么搞清楚业务流程（相关涉及到的也要清楚，这里容易出错。否则会隐含风险，最后时候可能发现影响到别的业务。）如果是整个版本要发布维护，那么还要清楚其他整个版本的需求功能，否则发布版本时候会有功能遗漏。
   3 . 工作习惯，不要存在侥幸心理。存在错误要马上修正，不修正也要记录通知到别人。