2015 2.10  

       系统化学习这本书的原因很简单，在写Maven Dependency Mediator这个开源插件的时候，希望能做的和开源社区诸如Ning那些组件不同，系统研究了Maven 2和3的源码，学习了Gradle这套编译体系，后来发现Gradle冲突检测这块实现上和Maven差不多。目前，已经将几个开源组件迁移到Gradle上了。另外，在读这本书的过程中，还学习了Groovy这门JVM语言，比scala简单，JVM平台上Domain specific language首选。借此推荐一下官方文档，非常棒的系统化了解Groovy的地方，地址：http://groovy-lang.org/documentation.html#gettingstarted

2015.4.1

       在学习了Getting Started With Storm后，继而阅读了这本书，怎么说呢，因为之前对Storm的架构，源码有过研究，所以看这本书，没有给我带来太多的感受。个人觉得比较亮的地方是与Hadoop YARN集成这一块，如何构建一个实时离线批处理平台，以及如何在统一调度平台YARN上跑这些任务，是自己还未曾尝试过的事情。

2015.4.10
Oracle Berkeley DB, Java Edition .
Getting Started with High Availability Applications

       文档和源代码配合着看，效果更好。老实说，Oracle的这文章真心水准很高，在我看过的官方文档里，绝对数的上数。

       闲话莫多扯，在BDB里，HA是借助自实现的一套类ZK分布式选举算法（这么讲有些不妥当，更准确一点说，也算是一种Paxos算法实现，连数据模型都一致，proposer，acceptor，learner）：每个Replication group只允许有一个Master node，一个或多个replica node，secondary node（也是一种read-only Replicas，不参与选举，不参与响应事务提交），monitor node（轻量级监控节点，也可以负责写路由）；只有Master node负责写，所有参与选举过程的节点负责读（read-only Replicas and read-write Masters模式），写路由可以通过一个独立模块TCP Command监听来完成；分布式的两阶段表决协议来选择Master节点，需要确保此过程中至少有简单多数的可选节点参与。具有最新环境状态（说白了，这里就是log，核心算法可参看RankingProposer这个类）的参与的electable nodes将选为master node。

       两个很关键的指标Durability（影响到可用性）和Consistency，通俗讲就是CAP里面的AC矛盾。

       先说Durability，分为三档Durability.SyncPolicy.SYNC，Durability.SyncPolicy.NO_SYNC，Durability.SyncPolicy.WRITE_NO_SYNC。重点介绍一下后两者区别：WRITE_NO_SYNC会写文件系统buffer，但不刷盘，提供最好的可靠性保障，前者只写内存，无疑吞吐更大，但它无法抗拒硬件资源歇菜的场景。这里面还有一个应答策略，也基本全了，提供了Durability.ReplicaAckPolicy.ALL，Durability.ReplicaAckPolicy.NONE，Durability.ReplicaAckPolicy.SIMPLE_MAJORITY，最后一个也是我们常见的多数原则，很多同学会立马联想到ZK的选择策略里面要求机器必须是奇数，也遵循少数服从多数的原则。没错，BDB的选举策略也是这样的！

        再来看Consistency，三种保障，NoConsistencyRequiredPolicy，TimeConsistencyPolicy，CommitPointConsistencyPolicy，重点看下后面两个， TimeConsistencyPolicy顾名思义要求时间必须时钟同步，毫无疑问这又涉及到分布式程序一个老生常谈问题，NTPD服务，上吧，不多说了。一旦Replica落后Master一定时间，挂起事务操作，等待一定的时间，等待Replica追赶。 CommitPointConsistencyPolicy大致和会话token差不多，master 节点产生token，然后应用下次读请求带着token进来，可读节点使用该token生成CommitPointConsistencyPolicy，伴随着一定的token失效期，如果环境已经就绪，那就执行读事务，如果没有，推迟直到replica节点追赶上来。

        然后，来看看一个设计很棒的地方，HA的异常体系。大致分三类Master-Specific HA Exceptions，Replica-Specific HA Exceptions，Replicated Environment Handle-Specific Exceptions。每种异常都戳中分布式系统一个痛点，如跟Master相关的异常中，InsufficientReplicasException就至少有两种可能会抛出，写事务开始前，或者commit前，如果是后者，表示该事务参与持久化ack的replica不能满足多数原则；再比如InsufficientAcksException异常，表示本地事务提交成功，但是没有收到足够多的ack，处理方式取决于你自己。ReplicaWriteException异常，尤其是当你的master变更为replica时会碰到，这个时候你需要路由当前的写操作到Master，再比如LockPreemptedException异常，读锁被写锁抢占到，这个时候你要放弃你的读请求，进行重试，保证数据的一致性。InsufficientLogException异常通常意味着该节点已经宕机多时，需要足够多的日志流来追赶Master，但有可能后台日志Cleaner线程根据一定的时间规则清理丢弃了这部分日志，这个时候就不能通过正常的日志复制流去追赶了，必须借助NetworkRestore这个类玩。

       至于里面提到的几个很棒的工具类ReplicationGroupAdmin，NetworkRestore，DbBackup，没啥说的，一笔带过～

       最后，来看一个变态特性，如果选择Master的过程中，多数原则不满足，怎么破？简单说，你原先有3个节点，挂了一个节点，按理说，无法完成新master的选举，机器这个时候也准备不来，BDB提供了一个特性，通过JMX动态调整ELECTABLE_GROUP_SIZE_OVERRIDE，两个节点也可以进行Master选举，待第三个节点恢复过来，再连上来，这个时候我们动态地再关闭这个选项，恢复多数原则。如果不这么玩，你还能想到什么玩法？一种是5个节点，挂了一个，你干脆再挂它一个，这样凑成奇数，照样可以选举master节点；多数据中心部署？等等，这个问题比较复杂，以后有机会会和大家分享一下这块的思路以及工具集。另外说道这里，补充一下其实BDB的Secondary节点和ZK的Observer节点的设计初衷很像，它也是实现水平扩展一个很好的突破口。

2015.10.15

       这本书其实2012年就出版了，读这本书的初衷很简单，再次检验一下自己的并发知识体系。通篇基本上都是利用零碎时间阅读，一些小程序，比较精炼。美中不足，对其中的一些并发技巧阐述的较少，看来赛的过JCIP的书还真是没有，如果希望再深入地研究并发编程，推荐大家读读<<并发的艺术>>，C语言实现，绝对的经典。另外之前还读过一本<<Windows并发编程指南>>，也是一本比较经典的著作。接下来的时间，要着手开始写书了，系统阅读计划可能要稍微停下来，期待明天的出版之日～

2015.11.3

      如果说Maven把约定大于配置发挥到极致的话，Spring boot则是自动优于配置的经典代表~

       Manning 出版的，目前还是MEAP版本。这本书写的不错（更多的细节，可以参考官方文档PDF，尤其是它的附录，满满的细节），对照着之前写的MQ Spring boot代码，很快浏览完了整本书,并对之前写的代码进行了精简优化。最深刻的印象是作者有一个误区，认为Gradle传递依赖与Ｍaven（closest dependency）的有一个不同，favors the newest version of a dependency，什么意思呢？就是说如果你直接依赖一个低版本，必须把传递依赖的新版本排除掉，其实maven也是这样的。除此之外，还想提下Actuator，像CounterService,PublicMetrics,GaugeService接口方法的值要么是number,要么是double，我有一些需求，如暴漏本机IP机器端口，像这些，用Metrics和Guage就不行了。如何破？可以考虑使用AbstractEndpoint。至于Spring boot里面的一些实现细节，本书几乎没有阐述，感兴趣的同学必须自己动手研究源码。顺带说下，之前如果对spring源码有过研究，应该不难，就是时间成本问题啦。不罗嗦了，赶紧写书去。。。。。。

补充一个不错的PPT资料：http://presos.dsyer.com/decks/spring-boot-intro.html#slide45