cryptozombies源码解析一中对以太坊开发中的事件与合约交互进行了介绍，看过这篇文章的同学我相信对Dapp开发也有了一个初步的了解，下面我们继续学习一些智能合约开发中特性。
cryptozombies源码解析一
学习区块链的朋友应该都了解去年又一款迷恋猫的爆款游戏，他是一款基于以太网的Dapp游戏。此游戏将区块链应用推向了高潮，网上各种解读接踵而来。
但对于学习区块链的技术人员肯定想从代码层次学习下，想借此掌握一些Dapp开发的技巧，我也是这么想的，但是不巧的是我的水平有限(虽然代码真的很简单，代码量也不多)，读了一遍源码发现脑子里没有留下什么。
于是就在网上各种找资料，无意中发现了Loom Network的一个游戏教程cryptozombies，就尝试了下，发现停不下来，就把Solidity 教程: 智能合约基础教程给学完了。在学习的过程中发现很多知识也在迷恋猫的代码中出现了，瞬间感觉开朗了很多。
此篇博客算是学完课程之后的回顾和总结吧。
Ozone感悟
前面提到Ozone的原创团队对大规模Hadoop集群运维和优化有着丰富的经验，所以Ozone的设计中也体现了很多HDFS的优点，并屏蔽了一些HDFS的性能瓶颈。
HDFS目前的瓶颈主要在NN上，NN内存中维护着两个大对象，一个是NameSpace，另一个是BlocksMap，这两个是常驻内存而且随着集群存储的文件数和规模成线性增长，这就造成NN的内存占比越来越大，成为HDFS扩展的瓶颈。
那么Ozone是如何解决这些瓶颈呢？
Hadoop小文件利器Ozone调研
之前一篇文章介绍了在小文件合并方面的一些心得，本篇介绍下Hadoop解决小文件的最新利器Ozone(本篇基于0.3.0-alpha版本)。
Ozone诞生的背景
众所周知，HDFS是大数据存储系统，并在业界得到了广泛的使用。但是无论大集群还是小集群其扩展性都受NN的限制，虽然HDFS可以通过Federation进行扩展，但是依然深受小文件和4亿个文件的困扰。
于是分布式key-value存储系统Ozone诞生了，Ozone能够轻松管理小文件和大文件。(HDFS提供了类似POSIX的语义，Ozone的外观和行为更像一个Object存储系统。)
HDFS小文件合并实战
HDFS是一个大数据存储系统，主要面向的场景是一次写入多次读取，大文件。但是在实际使用过程中由于各种原因集群中总是充斥着各种小文件，而且数据惊人。无论社区还是公司都在积极解决这个问题。(为什么要解决小文件，这个问题我想看到这篇文章的人应该都知道啊!)
无论你怎么优化集群，指定各种规范，让业务方优化程序，小文件总是无法避免的。
Merkle Patricia Tree(MPT)
区块链一个重要的亮点就是防篡改，那么它是怎么做到防篡改的呢？其中一个重要的知识点就是Merkle Patricia Tree(MPT)，本篇就来解析下何为MPT。
MPT是一种加密认证的数据结构，它融合了Merkle树和Patricia Trie树(基数树/压缩前缀树)两种数据类型的优点。
则在介绍MPT树之前先介绍下Merkle树(默克尔树)、Trie树(前缀树)和Patricia Trie(基数树/压缩前缀树)，介绍Trie树是因为Patricia Trie是基于Trie树衍化来的。
Docker容器log采集实践
随着容器和编排技术持续发展，各个公司都已陆续在容器云领域有了相关实践，转转也不例外，也在进行一些积极探索与实践。
本文以日志采集为切入点，介绍下转转容器云平台中的业务日志是如何自动化采集的。
函数式编程之闭包
维基百科)中是这样定义闭包的：
在计算机科学中，闭包（英语：Closure），又称词法闭包（Lexical Closure）或函数闭包（function closures），是引用了自由变量的函数。这个被引用的自由变量将和这个函数一同存在，即使已经离开了创造它的环境也不例外。
这里有两点需要把握，自由变量和函数。则判断是不是闭包首先判断是不是函数，如果都不是函数那么肯定不是闭包，是函数再继续判断是否有自由变量。
自由变量就是这里的重点了。。。
全栈Voting Dapp Demo
Application运行失败导致RM主备切换
先说故障现象:
某天收到RM主备切换报警，正常切换并不会有什么影响，但我当时还是出于警觉想去服务器上check下为什么切，check的时候发现集群无法提交任务，所以的任务都被挂起了。
第一反应是原standby节点有问题，于是手动又触发了一次切换，但任务依然无法运行。主备RM都重启过了但问题依然无法解决，那只能使用终极杀手锏了，重启了整个yarn集群。
集群重启之后任务恢复了，心里舒了一口气，去查RM的log吧，看下是什么原因导致了这次故障，log还没有细看，只看到一些KeeperErrorCode = ConnectionLoss，此时悲剧发生了，又收到了RM切换的报警，任务又被挂起了。。。
毫无头绪，只能再次重启集群，这次重点关注了下集群上运行任务，估计是哪个任务把集群给干瘫了，观察到有个任务运行失败的时候集群就会被瘫，看了下该任务的报错信息特别特别的长，于是告诉任务的负责人暂时把任务停掉，观察下集群是不是因为这个任务导致的。
该任务停掉之后集群正常运行了一段时间，在这段时间内在查RM的log并没有发现太多有价值的东西，全是与zk的连接丢失，连接丢失确实是会触发主备切换，但关键是为什么连接会丢失呢？没有头绪，只好去zk server端看下log，发现报2018-11-27 15:54:30,208 [myid:1] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@373] - Exception causing close of session 0x36753e378030000 due to java.io.IOException: Len error 8603591