最近对blog进行了改版，采用hexo和NexT

评论系统使用valine

上面是两个东西的中文文档，按照教程操作还是比较快的。

转载自infoq

站在未来的路口，回望历史的迷途，常常会很有意思，因为我们会不经意地兴起疯狂的念头，例如如果当年某事提前发生了，而另外一件事又没有发生会怎样？一如当年的奥匈帝国皇位继承人斐迪南大公夫妇如果没有被塞尔维亚族热血青年普林西普枪杀会怎样，又如若当年的丘老道没有经过牛家村会怎样？

2008 年底，淘宝开启一个叫做“五彩石”的内部重构项目，这个项目后来成为了淘宝服务化、面向分布式走自研之路，走出了互联网中间件体系之始，而淘宝服务注册中心 ConfigServer 于同年诞生。

2008 年前后，Yahoo 这个曾经的互联网巨头开始逐渐在公开场合宣讲自己的大数据分布式协调产品 ZooKeeper，这个产品参考了 Google 发表的关于 Chubby 以及 Paxos 的论文。

MyBatis源码分析是一个系列，旨在深入了解MyBatis执行流程以及原理。本篇我们先大体的看下MyBatis整个的执行流程，对MyBatis整体有个了解，然后我们在找几个主题深入的去讨论，比如缓存、连接池等，希望通过MyBatis系列，对你有所帮助，那么我们开始吧！

首先每一个框架都会有一个入口，让我们可以很容易的拿来即用，同样也可以沿着入口，了解这个框架的整体流程，然后在深扒底层的原理细节。MyBatis官网提供给我们如何在项目中使用它。

class文件格式

由Java虚拟机执行的编译代码使用独立于硬件和操作系统的二进制格式表示，通常（但不一定）存储在文件中，称为类文件格式。类文件格式精确定义了类或接口的表示形式，包括可能以特定于平台的目标文件格式获取的字节顺序等详细信息。

数据类型

JVM有两种类型，primitive type和reference type。

在InnoDB事务模型中，目标是将多版本（multi-versioning）数据库的最佳属性与传统的两阶段锁定相结合。InnoDB执行行级别锁定，默认情况下将查询作为非锁定一致性读取运行。

本篇介绍InnoDB使用的锁类型，并提供了一些例子来更加深入的介绍了锁。

共享锁和排它锁

我们都知道InnoDB实现了行级锁，行级锁分为两类：共享和排他。

• 共享锁(Sharded Lock, S)允许持有锁的事务读取行
• 排它锁(Exclusive Lock, X)允许持有锁的事务更新或删除行

年后对目前系统存在的问题现状，做了一次深入的分析，将已经存在以及应对未来的需求做了些规划。之前确实挖的坑实在是太多，整个分析下来要做的有十几个大项，大部分是关于架构、数据、规范、服务化等方面。估计要做下来怎么也得一两年。。。真正做到了前人挖坑，后人填，如果这次没能做好前期架构，以及严格保证开发过程，可能也会造成”后人哀之而不鉴之，亦使后人而复哀后人也“的局面。

其中有一项算是服务拆分相关，抽取关键的公共服务。消息系统算是其中之一。目前内部对于系统的要求场景比较单一，主要就是短信和钉钉两种。谈起设计起始感觉也有点老生常谈，平时我们听过的设计方案，基本就足以支持现在的业务量。更多的还是要关注细节。下图是整个系统的描述：

随着公司业务增长，系统间交互变得频繁，由于目前公司架构以及基础设施都比较差bug不断，通常需要多个系统共同排查问题。对于跨系统定位bug问题，由于没有一个统一的traceId，很难将一个业务线的请求跟另一个业务线的请求关联起来。于是花了点时间，写了一套简单的解决方案，目前也在向各业务线进行推广。

因为内部系统使用的Dubbo作为RPC框架，该方案也是针对dubbo。代码地址：https://github.com/metogefun/shadow

设计之初最优先考虑的就是零侵入。为了使业务线更方便接入，所有一切都为了给业务线节省成本。该方案主要实用了Dubbo的SPI机制扩展了Filter，自定义两个不同的Filter，TraceProviderFilter和TraceConsumerFilter。实现的功能也很简单，从代码就能看出来做了什么。

开发联调环境主要是为了解决开发过程中，需要对其他系统服务进行依赖的问题。项目过程中经常会遇到这种情况，前后端进行联调而后端接口需要依赖其他系统的服务，因为没有一套整体的环境，可能我们把这个问题就直接丢到测试环境去调试，这就没办法保证了测试环境的稳定性，也会影响测试的效率。

本文转载自原地址

本节将介绍ZooKeeper的架构，并结合实例分析原子广播(ZAB)协议的原理，包括但不限于ZooKeeper的读写流程，FastLeaderElection算法的原理，ZAB如何保证Leader Failover过程中的数据一致性。

ZooKeeper是什么

ZooKeeper是一个分布式协调服务，可用于服务发现、分布式锁、分布式领导选举、配置管理等。

这一切的基础，都是ZooKeeper提供了一个类似于Linux文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制。

既然是一个文件系统，就不得不提ZooKeeper是如何保证数据的一致性的。本节将将介绍ZooKeeper如何保证数据一致性，如何进行领导选举，以及数据监控/通知机制的语义保证。