from：https://www.infoq.cn/article/orvjbfycnrito5qiyfhf
前言

学习一个知识之前，我觉得比较好的方式是先理解它的来龙去脉：即这个知识产生的过程，它解决了什么问题，它是怎么样解决的，还有它引入了哪些新的问题（没有银弹），这样我们才能比较好的抓到它的脉络和关键点，不会一开始就迷失在细节中。

所以，在学习分布式系统之前，我们需要解决的第一个问题是：分布式系统解决了什么问题？

分布式系统解决了什么问题？

第一个是单机性能瓶颈导致的成本问题，由于摩尔定律失效，廉价 PC 机性能的瓶颈无法继续突破，小型机和大型机能提高更高的单机性能，但是成本太大高，一般的公司很难承受；

第二个是用户量和数据量爆炸性的增大导致的成本问题，进入互联网时代，用户量爆炸性的增大，用户产生的数据量也在爆炸性的增大，但是单个用户或者单条数据的价值其实比软件时代（比如银行用户）的价值是只低不高，所以必须寻找更经济的方案；

第三个是业务高可用的要求，对于互联网的产品来说，都要求 7 * 24 小时提供服务，无法容忍停止服务等故障，而要提供高可用的服务，唯一的方式就是增加冗余来完成，这样就算单机系统可以支撑的服务，因为高可用的要求，也会变成一个分布式系统。

基于上面的三个原因可以看出，在互联网时代，单机系统是无法解决成本和高可用问题的，但是这两个问题对几乎对所有的公司来说都是非常关键的问题，所以，从单机系统到分布式系统是无法避免的技术大潮流。

分布式系统是怎么来解决问题的？

那么，分布式系统是怎么来解决单机系统面临的成本和高可用问题呢？

其实思路很简单，就是将一些廉价的 PC 机通过网络连接起来，共同完成工作，并且在系统中提供冗余来解决高可用的问题。

分布式系统引入了哪些新的问题？

我们来看分布式系统的定义：分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。在定义中，我们可用看出，分布式系统它通过多工作节点来解决单机系统面临的成本和可用性问题，但是它引入了对分布式系统内部工作节点的协调问题。

我们经常说掌握一个知识需要理解它的前因后果，对于分布式系统来说，前因是「分布式系统解决了什么问题」，后果是「它是怎么做内部工作节点的协调」，所以我们要解决的第二个问题是：分布式系统是怎么做内部工作节点协调的？

分布式计算引入了哪些新的问题？

先从简单的情况入手，对于分布式计算（无状态）的情况，系统内部的协调需要做哪些工作：

1.怎么样找到服务？

在分布式系统内部，会有不同的服务（角色），服务 A 怎么找到服务 B 是需要解决的问题，一般来说服务注册与发现机制是常用的思路，所以可以了解一下服务注册发现机制实现原理，并且可以思考服务注册发现是选择做成 AP 还是 CP 系统更合理（严格按 CAP 理论说，我们目前使用的大部分系统很难满足 C 或者 A 的，所以这里只是通常意义上的 AP 或者 CP）；

2.怎么样找到实例？

找到服务后，当前的请求应该选择发往服务的哪一个实例呢？一般来说，如果同一个服务的实例都是完全对等的（无状态），那么按负载均衡策略来处理就足够（轮询、权重、hash、一致性 hash，fair 等各种策略的适用场景）；如果同一个服务的实例不是对等的（有状态），那么需要通过路由服务（元数据服务等）先确定当前要访问的请求数据做哪一个实例上，然后再进行访问。

3.怎么样避免雪崩？

系统雪崩是指故障的由于正反馈循序导致不断扩大规则的故障。一次雪崩通常是由于整个系统中一个很小的部分出现故障于引发，进而导致系统其它部分也出现故障。比如系统中某一个服务的一个实例出现故障，导致负载均衡将该实例摘除而引起其它实例负载升高，最终导致该服务的所有实例像多米诺骨牌一样一个一个全部出现故障。

避免雪崩总体的策略比较简单，只要是两个思路，一个是快速失败和降级机制（熔断、降级、限流等），通过快速减少系统负载来避免雪崩的发生；另一个为弹性扩容机制，通过快速增加系统的服务能力来避免雪崩的发生。这个根据不同的场景可以做不同的选择，或者两个策略都使用。

一般来说，快速失败会导致部分的请求失败，如果分布式系统内部对一致性要求很高的话，快速失败会带来系统数据不一致的问题，弹性扩容会是一个比较好的选择，但是弹性扩容的实现成本和响应时间比快速失败要大得多。

4.怎么样监控告警？

对于一个分布式系统，如果我们不能很清楚地了解内部的状态，那么高可用是没有办法完全保障的，所以对分布式系统的监控（比如接口的时延和可用性等信息），分布式追踪 Trace，模拟故障的混沌工程，以及相关的告警等机制是一定要完善的；

分布式存储引入了哪些新的问题？

接下来我们再来看分布式存储（有状态）的内部的协调是怎么做的，同时，前面介绍的分布式计算的协调方式在分布式存储中同样适用，就不再重复了：

1.分布式系统的理论与衡权

ACID、BASE 和 CAP 理论，了解这三个主题，推荐这一篇文章以及文章后面相关的参考文献：

英文版本：https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/

中文版本：https://www.infoq.cn/article/cap-twelve-years-later-how-the-rules-have-changed/

2.怎么样做数据分片？

单机的存储能力是不可能存储所有的数据的，所以需要解决怎么将数据按一定的规则分别存储到不同的机器上，目前使用比较多的方案为：Hash、Consistent Hash 和 Range Based 分片策略，可以了解一下它们的优缺点和各自的应用场景；

3.怎么样做数据复制？

为什么满足系统的高可用要求，需要对数据做冗余处理，目前的方案主要为：中心化方案（主从复制、一致性协议比如 Raft 和 Paxos 等）和 去中心化的方案（Quorum 和 Vector Clock）了解一下它们的优缺点和各自的应用场景，以及对系统外部表现出来的数据一致性级别（线性一致性、顺序一致性、最终一致性等）；

4.怎么样做分布式事务？

对于分布式系统来说，要实现事务，首先需要有对并发事务进行排序的能力，这样在事务冲突的时候，确认哪个事务提供成功，哪个事务提交失败。对于单机系统来说这个完全不是问题，简单通过时间戳加序号的方式就可以实现，但是对于分布式系统来说，系统中机器的时间不能完全同步，并且单台机器序号也没用全局意义，按上面的方式说行不通的。不过整个系统选一台机器按单机的模式生产事务 ID 是可以的，同城多中心和短距离的异地多中心都没有问题，不过想做成全球分布式系统的话，那么每一次事务都要去一个节点去获取事务 ID 的成本太高（比如中国杭州到美国东部的 RTT 为 200 + ms ），Google 的 Spanner 是通过 GPS 和原子钟实现 TrueTime API 来解决这个问题从而实现全球分布式数据库的。

有了事务 ID 后，通过 2PC 或者 3PC 协议来实现分布式事务的原子性，其他部分和单机事务差别不大，就不再细说来。

进阶学习阶段

到这里，对分布式系统脉络上有了基本的概念，接下来开始进入细节学习阶段，这也是非常幸苦的阶段，对于分布式系统的理解深入与否，对细节的深入度是很重要的评价指标，毕竟魔鬼在细节。这里可以往两个方面进行系统的学习：

1.从实践出发

研究目前比较常用的分布式系统的设计，HDFS 或者 GFS（分布式文件系统）、Kafka 和 Pulsar（分布式消息队列），Redis Cluster 和 Codis（分布式缓存），MySQL 的分库分表（传统关系型数据库的分布式方案），MongoDB 的 Replica Set 和 Sharing 机制集以及去中心化的 Cassandra（NoSQL 数据库），中心化的 TiDB 和去中心化的 CockroachDB（NewSQL），以及一些微服务框架等；

2.从理论出发

从理论出发，研究分布式相关的论文，这里推荐一本书「Designing Data-Intensive Applications」（中文版本：数据密集型应用系统设计），先整体看书，对比较感兴趣的章节，再读一读该章节中涉及到的相关参考文献。

总结

本文从分布式系统解决的问题开始，再讨论它是怎么样来解决问题的，最后讨论了它引入了哪些新的问题，并且讨论这些新问题的解决办法，这个就是分布式系统大概的知识脉络。掌握这个知识脉络后，那么就可以从实践和理论两个角度结合起来深入细节研究分布式系统了。

参考

知乎 | 如何系统性的学习分布式系统

Martin Kleppmann.Designing Data-Intensive Applications

CAP Twelve Years Later: How the “Rules” Have Changed

随着紫光展锐、ASR 等芯片厂商发布性价比更高的 Cat.1 芯片之后，Cat.1 模组厂商扎堆发布了自家的模组，
使得市场上的 Cat.1 模组价格已经迅速降至 45-60 元，玩家众多，竞争惨烈，基本重走 NB-IOT 的老路 —— 量未起，价已跌。

Cat.1 芯片原厂：

• 高通 MDM9207-1(2016 年发布)

• 紫光展锐春藤 8910DM（28nm工艺，集成蓝牙和WiFi 室内定位）

• 翱捷 ASR3601

Cat.1 模组厂商（不完全统计）：

• 中移物联网

• 移远通信

• 合宙电子

• 移柯通信

• 域格信息

• 广和通

• 芯讯通

• 高新兴物联

• 美格智能

• 有方科技

• 有人信息

• 信位通讯

• 锐骐(厦门)电子

• 深圳信可通讯

Cat.1 优势

• 相对 NB-IOT，其通信速率优势明显

• 相对 eMTC，其网络成本低

• 相对 Cat.4，其具有一定的成本优势

Cat.1 劣势：

• 现阶段芯片厂家少

  国外以高通为主，辅以 Sequans、Altair。

  国内主要是展锐和翱捷。

• 现阶段价格偏高

  NB-IoT、Cat.1、Cat.4 模组价格：

  
  

cat1 的主要市场和应用场景：

Cat.1 仍处于商用初期，落地的应用场景和案例还较少，一些明确的场景包括了共享、金融支付、工业控制、车载支付、公网对讲、POS 等等。

总结

工信部办公厅发布了《关于深入推进移动物联网全面发展的通知》（以下简称《通知》）同时为 NB-IOT 和 Cat.1 站台，未来 NB-IOT 依旧很香，Cat.1 则前途大好。

随着新基建的启动，5G 打头，未来将是 NB-IOT、4G（包括 Cat.1）、5G 共同承载蜂窝物联网的连接，以应对不同层次的物联网业务需求。

背景

QoS 等级 与 通信的流程有关，直接影响了整个通信。而且篇幅比较长，所以我觉得应该单独拎出来讲一下。

概念

QoS 代表了 服务质量等级。 设置上，由2 位 的二进制控制，且值不允许为 3(0x11)。

要注意的是，QoS 是 Sender 和 Receiver 之间达成的协议，不是 Publisher 和 Subscriber 之间达成的协议。

也就是说 Publisher 发布一条 QoS1 的消息，只能保证 Broker 能至少收到一次这个消息；至于对应的 Subscriber 能否至少收到一次这个消息，还要取决于 Subscriber 在 Subscribe 的时候和 Broker 协商的 QoS 等级。

这里又牵扯出一个概念："QoS 降级"：在 MQTT 协议中，从 Broker 到 Subscriber 这段消息传递的实际 QoS 等于 "Publisher 发布消息时指定的 QoS 等级和 Subscriber 在订阅时与 Broker 协商的 QoS 等级，这两个 QoS 等级中的最小那一个。"

QoS 0 的通信时序图

此时，整个过程中的 Sender 不关心 Receiver 是否收到消息，它"尽力"发完消息，至于是否有人收到，它不在乎。

QoS1 的通信时序图

此时，Sender 发送的一条消息，Receiver 至少能收到一次，也就是说 Sender 向 Receiver 发送消息，如果发送失败，会继续重试，直到 Receiver 收到消息为止，但是因为重传的原因，Receiver 有可能会收到重复的消息；

1）Sender 向 Receiver 发送一个带有消息数据的 PUBLISH 包， 并在本地保存这个 PUBLISH 包。

2）Receiver 收到 PUBLISH 包以后，向 Sender 发送一个 PUBACK 数据包，PUBACK 数据包没有消息体（Payload），在可变头中（Variable header）中有一个包标识（Packet Identifier），和它收到的 PUBLISH 包中的 Packet Identifier 一致。

3）Sender 收到 PUBACK 之后，根据 PUBACK 包中的 Packet Identifier 找到本地保存的 PUBLISH 包，然后丢弃掉，一次消息的发送完成。

4）如果 Sender 在一段时间内没有收到 PUBLISH 包对应的 PUBACK，它将该 PUBLISH 包的 DUP 标识设为 1（代表是重新发送的 PUBLISH 包），然后重新发送该 PUBLISH 包。重复这个流程，直到收到 PUBACK，然后执行第 3 步。

QoS 2 的通信时序图

QoS2 不仅要确保 Receiver 能收到 Sender 发送的消息，还要保证消息不重复。它的重传和应答机制就要复杂一些，同时开销也是最大的。

Sender 发送的一条消息，Receiver 确保能收到而且只收到一次，也就是说 Sender 尽力向 Receiver 发送消息，如果发送失败，会继续重试，直到 Receiver 收到消息为止，同时保证 Receiver 不会因为消息重传而收到重复的消息。

QoS 使用 2 套请求/应答流程（一个 4 段的握手）来确保 Receiver 收到来自 Sender 的消息，且不重复：

1）Sender 发送 QoS 为 2 的 PUBLISH 数据包，数据包 Packet Identifier 为 P，并在本地保存该 PUBLISH 包；

2）Receiver 收到 PUBLISH 数据包以后，在本地保存 PUBLISH 包的 Packet Identifier P，并回复 Sender 一个 PUBREC 数据包，PUBREC 数据包可变头中的 Packet Identifier 为 P，没有消息体（Payload）；

3）当 Sender 收到 PUBREC，它就可以安全地丢弃掉初始的 Packet Identifier 为 P 的 PUBLISH 数据包，同时保存该 PUBREC 数据包，同时回复 Receiver 一个 PUBREL 数据包，PUBREL 数据包可变头中的 Packet Identifier 为 P，没有消息体；如果 Sender 在一定时间内没有收到 PUBREC，它会把 PUBLISH 包的 DUP 标识设为 1，重新发送该 PUBLISH 数据包（Payload）；

4）当 Receiver 收到 PUBREL 数据包，它可以丢弃掉保存的 PUBLISH 包的 Packet Identifier P，并回复 Sender 一个 PUBCOMP 数据包，PUBCOMP 数据包可变头中的 Packet Identifier 为 P，没有消息体（Payload）；

5）当 Sender 收到 PUBCOMP 包，那么它认为数据包传输已完成，它会丢弃掉对应的 PUBREC 包。如果 Sender 在一定时间内没有收到 PUBCOMP 包，它会重新发送 PUBREL 数据包。

我们可以看到在 QoS2 中，完成一次消息的传递，Sender 和 Reciever 之间至少要发送四个数据包，QoS2 是最安全也是最慢的一种 QoS 等级了。

QoS 和会话（Session）

客户端的会话状态包括：

• 已经发送给服务端，但是还没有完成确认的QoS 1和QoS 2级别的消息
• 已从服务端接收，但是还没有完成确认的QoS 2级别的消息。

服务端的会话状态包括：

• 会话是否存在，即使会话状态的其它部分都是空。
• 客户端的订阅信息。
• 已经发送给客户端，但是还没有完成确认的QoS 1和QoS 2级别的消息。
• 即将传输给客户端的QoS 1和QoS 2级别的消息。
• 已从客户端接收，但是还没有完成确认的QoS 2级别的消息。
• 可选，准备发送给客户端的QoS 0级别的消息。

保留消息不是服务端会话状态的一部分，会话终止时不能删除保留消息。

如果 Client 想接收离线消息，必须使用持久化的会话（CONNECT报文中可变头（byte8[1]）Clean Session = 0）连接到 Broker，这样 Broker 才会存储 Client 在离线期间没有确认接收的 QoS 大于 1 的消息。

QoS 等级的选择

在以下情况下你可以选择 QoS0：

• Client 和 Broker 之间的网络连接非常稳定，例如一个通过有线网络连接到 Broker 的测试用 Client；
• 可以接受丢失部分消息，比如你有一个传感器以非常短的间隔发布状态数据，所以丢一些也可以接受；
• 你不需要离线消息。

在以下情况下你应该选择 QoS1：

• 你需要接收所有的消息，而且你的应用可以接受并处理重复的消息；
• 你无法接受 QoS2 带来的额外开销，QoS1 发送消息的速度比 QoS2 快很多。

在以下情况下你应该选择 QoS2：

• 你的应用必须接收到所有的消息，而且你的应用在重复的消息下无法正常工作，同时你也能接受 QoS2 带来的额外开销。

实际上，QoS1 是应用最广泛的 QoS 等级，QoS1 发送消息的速度很快，而且能够保证消息的可靠性。虽然使用 QoS1 可能会收到重复的消息，但是在应用程序里面处理重复消息，通常并不是件难事。

摘要： MySQL replace into 错误案例 背景 * MySQL5.7 * ROW模式 * 表结构 CREATE TABLE `test` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `col_1` varc

* MySQL5.7  * ROW模式   * 表结构 CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   `col_3` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 

mater:lc> REPLACE INTO test (col_1,col_2,col_3) values('a','a','a'); Query OK, 1 row affected (0.00 sec) --注意，这里是影响了1条记录  master:lc> REPLACE INTO test (col_1,col_2,col_3) values('b','b','b'); Query OK, 1 row affected (0.00 sec) --注意，这里是影响了1条记录  master:lc> REPLACE INTO test (col_1,col_2,col_3) values('c','c','c'); Query OK, 1 row affected (0.00 sec) --注意，这里是影响了1条记录   master > show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   `col_3` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |   mater > select * from test; +----+-------+-------+-------+ | id | col_1 | col_2 | col_3 | +----+-------+-------+-------+ |  1 | a     | a     | a     | |  2 | b     | b     | b     | |  3 | c     | c     | c     | +----+-------+-------+-------+ 3 rows in set (0.00 sec)  

master:lc> replace into test(col_1,col_2) values('c','cc'); Query OK, 2 rows affected (0.00 sec)  dba:lc> select * from test; +----+-------+-------+-------+ | id | col_1 | col_2 | col_3 | +----+-------+-------+-------+ |  1 | a     | a     | a     | |  2 | b     | b     | b     | |  4 | c     | cc    | NULL  | +----+-------+-------+-------+ 3 rows in set (0.00 sec)  

 mater:lc> REPLACE INTO test (col_1,col_2) values('a','a'); Query OK, 1 row affected (0.00 sec) --注意，这里是影响了1条记录  master:lc> REPLACE INTO test (col_1,col_2) values('b','b'); Query OK, 1 row affected (0.00 sec) --注意，这里是影响了1条记录  master:lc> REPLACE INTO test (col_1,col_2) values('c','c'); Query OK, 1 row affected (0.00 sec) --注意，这里是影响了1条记录   master > show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |   slave > show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |

* master  mater:lc> REPLACE INTO test (col_1,col_2) values('c','cc'); Query OK, 2 rows affected (0.00 sec)  --注意，这里是影响了两条记录  mater:lc> show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8 |  master:lc> select * from test +----+-------+-------+ | id | col_1 | col_2 | +----+-------+-------+ |  1 | a     | a     | |  2 | b     | b     | |  4 | c     | cc    | +----+-------+-------+ 3 rows in set (0.00 sec)  * slave  slave:lc> show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |  slave:lc> select * from test +----+-------+-------+ | id | col_1 | col_2 | +----+-------+-------+ |  1 | a     | a     | |  2 | b     | b     | |  4 | c     | cc    | +----+-------+-------+ 3 rows in set (0.00 sec) 

* 假设有一天，master 挂了， 由slave 提升为 new mater  原slave:lc> show create table test  | test  | CREATE TABLE `test` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `col_1` varchar(100) DEFAULT NULL,   `col_2` varchar(100) DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `col_1` (`col_1`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 |  原slave:lc> select * from test +----+-------+-------+ | id | col_1 | col_2 | +----+-------+-------+ |  1 | a     | a     | |  2 | b     | b     | |  4 | c     | cc    | +----+-------+-------+ 3 rows in set (0.00 sec)   ===注意==  root:lc> REPLACE INTO test (col_1,col_2) values('d','d'); ERROR 1062 (23000): Duplicate entry '4' for key 'PRIMARY'  

* Row 模式，主从情况下，replace into 和 INSERT INTO … ON DUPLICATE KEY UPDATE 都会导致以上问题的发生 * 解决方案： 最后可以通过alter table auto_increment值解决，但是这样已经造成mater的表很长时间没有写入了。。。

1. 禁止 replace into (错误一，错误二 都会发生) 2. 禁止 INSERT INTO … ON DUPLICATE KEY UPDATE （错误二 会发生）

1. 禁止 replace into (会发生错误场景一的案例，丢失部分字段数据) 2. 可以使用INSERT INTO … ON DUPLICATE KEY UPDATE 代替 replace into

我这里推荐几本MySQL的好书，应该能够有效避免学习MySQL的弯路，并且达到一个不错的水平。 我这里推荐的书或材料分为两个部分，分别是MySQL的使用和MySQL的源码学习。在介绍的过程中，我会穿插简单的评语或感想。

1.MySQL的使用

1.1 MySQL技术内幕:InnoDB存储引擎

学习MySQL的使用，首推姜承尧的《MySQL技术内幕:InnoDB存储引擎》，当然不是因为姜sir是我的经理才推荐这本书。这本书确实做到了由渐入深、深入浅出，是中国人写的最赞的MySQL技术书籍，符合国人的思维方式和阅读习惯，而且，这本书简直就是面试宝典，对于近期有求职MySQL相关岗位的朋友，可以认真阅读，对找工作有很大的帮助。当然，也有人说这本书入门难度较大，这个就自己取舍了，个人建议就以这本书入门即可，有不懂的地方可以求助官方手册和google。

1.2 MySQL的官方手册

我刚开始学习MySQL的时候误区就是，没有好好阅读MySQL的官方手册。例如，我刚开始很难理解InnoDB的锁，尤其是各个情况下如何加锁，这个问题在我师弟进入百度做DBA时，也困扰了他一阵子，我们两还讨论来讨论去，其实，MySQL官方手册已经写得清清楚楚，什么样的SQL语句加什么样的锁，当然，MySQL的官方手册非常庞大，一时半会很难看完，建议先看InnoDB相关的部分。

http://dev.mysql.com/doc/refman/5.7/en/innodb-storage-engine.html

1.3 MySQL排错指南

《MySQL排错指南》是2015年夏天引入中国的书籍，这本书可以说是DBA速成指南，介绍的内容其实比较简单，但是也非常实用，对于DBA这个讲究经验的工种，这本书就是传授经验的，可能对有较多工作经验的DBA来说，这本书基本没有什么用，但是，对于刚入职场的新人，或学校里的学生，这本书会有较大的帮助，非常推荐。

1.4 高性能MySQL

《高性能MySQL》是MySQL领域的经典之作，拥有广泛的影响力，学习MySQL的朋友都应该有所耳闻，所以我就不作过多介绍，唯一的建议就是仔细看、认真看、多看几遍，我每次看都会有不小的收获。这就是一本虽然书很厚，但是需要一页一页、一行一行都认真看的书。

1.5 数据库索引设计与优化

如果认真学习完前面几本书，基本上都已经对MySQL掌握得不错了，但是，如果不了解如何设计一个好的索引，仍然不能成为牛逼的DBA，牛逼的DBA和不牛逼的DBA，一半就是看对索引的掌握情况，《数据库索引设计与优化》就是从普通DBA走向牛逼DBA的捷径，这本书在淘宝内部非常推崇，但是在中国名气却不是很大，很多人不了解。这本书也是今年夏天刚有中文版本的，非常值得入手以后跟着练习，虽然知道的人不多，豆瓣上也几乎没有什么评价，但是，强烈推荐、吐血推荐！

1.6 Effective MySQL系列

《Effective MySQL系列》是指:

• Effective MySQL Replication Techniques in Depth
• Effective MySQL之SQL语句最优化
• Effective MySQL之备份与恢复

这一系列并不如前面推荐的好，其中，我只看了前两本，这几本书只能算是小册子，如果有时间可以看看，对某一个”模块”进入深入了解。

2.MySQL的源码

关于MySQL源码的书非常少，还好现在市面上有两本不错的书，而且刚好一本讲server层，一本讲innodb存储引擎层，对于学习MySQL源码会很有帮助，至少能够更加快速地了解MySQL的原理和宏观结构，然后再深入细节。此外，还有一些博客或PPT将得也很不错，这里推荐最好的几份材料。

2.1 InnoDB - A journey to the core

《InnoDB - A journey to the core》 是MySQL大牛Jeremy Cole写的PPT，介绍InnoDB的存储模块，即表空间、区、段、页的格式、记录的格式、槽等等。是学习Innodb存储的最好的材料。感谢Jeremy Cole!

2.2 深入MySQL源码

登博的分享《深入MySQL源码》，相信很多想了解MySQL源码的朋友已经知道这份PPT，就不过多介绍，不过，要多说一句，登博的参考资料里列出的几个博客，都要关注一下，干货满满，是学习MySQL必须关注的博客。

2.3 深入理解MySQL核心技术

《深入理解MySQL核心技术》是第一本关于MySQL源码的书，着重介绍了MySQL的Server层，重点介绍了宏观架构，对于刚开始学习MySQL源码的人，相信会有很大的帮助，我在学习MySQL源码的过程中，反复的翻阅了几遍，这本书刚开始看的时候会很痛苦，但是，对于研究MySQL源码，非常有帮助，就看你是否需要，如果没有研究MySQL源码的决心，这本书应该会被唾弃。

2.4 MySQL内核：InnoDB存储引擎

我们组的同事写的《MySQL内核：InnoDB存储引擎》，可能宇宙范围内这本书就数我学得最认真了，虽然书中有很多编辑错误，但是，平心而论，还是写得非常好的，相对于《深入理解MySQL核心技术》，可读性更强一些，建议研究Innodb存储引擎的朋友，可以了解一下，先对Innodb有一个宏观的概念，对大致原理有一个整体的了解，然后再深入细节，肯定会比自己从头开始研究会快很多，这本书可以帮助你事半功倍。

2.5 MySQL Internals Manual

《MySQL Internals Manual》相对于MySQL Manual来说，写的太粗糙，谁让人家是官方文档呢，研究MySQL源码的时候可以简单地参考一下，但是，还是不要指望文档能够回答你的问题，还需要看代码才行。

http://dev.mysql.com/doc/internals/en/

2.6 MariaDB原理与实现

评论里提到的《MariaDB原理与实现》我也买了一本，还不错，MariaDB讲的并不多，重点讲了Group Commit、线程池和复制的实现，都是MySQL Server层的知识，对MySQL Server层感兴趣的可以参考一下。

3. 后记

希望这里推荐的材料对学习MySQL的同学、朋友有所帮助，也欢迎推荐靠谱的学习材料，大家共同进步。

最近做了个Web项目, 架构上使用了 Nginx +tomcat 集群, 且全站HTTPS，用nginx 做负载，nginx和tomcat 使用内网http通信，遇到http css，js静态资源被浏览器拦截问题，网上搜索到的很多文章在描述 Nginx + Tomcat 启用 HTTPS 支持的时候，都必须在 Nginx 和 Tomcat 两边同时配置 SSL 支持，今天做个总结。

遇到问题

1. nginx强制使用https访问(http跳转到https)
2. http的js，css 等静态资源被浏览器拦截（http不被信任）

最后的解决方案

首先解决第一个问题全站https 
参考 
三种方式，跟大家共享一下

nginx的rewrite方法

server {   listen  192.168.1.111:80;   server_name test.com;   rewrite ^(.*)$  https://$host$1 permanent; }   

nginx的497状态码，我选择了这种方式

server {       listen       192.168.1.11:443;  #ssl端口       listen       192.168.1.11:80;   #用户习惯用http访问，加上80，后面通过497状态码让它自动跳到443端口       server_name  test.com;       #为一个server{......}开启ssl支持       ssl                  on;       #指定PEM格式的证书文件        ssl_certificate      /etc/nginx/test.pem;        #指定PEM格式的私钥文件       ssl_certificate_key  /etc/nginx/test.key;        #让http请求重定向到https请求        error_page 497  https://$host$uri?$args;   }   

index.html刷新网页

<html>   <meta http-equiv="refresh" content="0;url=https://test.com/">   </html>  

当http访问到index.html时候自动跳转到https

接下来解决第二个问题 
如果tomcat 和nginx 双方没有配置X-Forwarded-Proto tomcat就不能正确区分实际用户是http 还是https，导致tomcat 里配置的静态资源被认为是http而被浏览器拦截，request.getScheme()总是 http，而不是实际的http或https

分别配置一下 Nginx 和 Tomcat ，果然好了。 
配置 Nginx 的转发选项：

 proxy_set_header       Host $host;       proxy_set_header  X-Real-IP  $remote_addr;       proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;       proxy_set_header X-Forwarded-Proto  $scheme;  
1
2
3
4

配置Tomcat server.xml 的 Engine 模块下配置一个 Valve：

<Valve className="org.apache.catalina.valves.RemoteIpValve"   remoteIpHeader="X-Forwarded-For"   protocolHeader="X-Forwarded-Proto"   protocolHeaderHttpsValue="https"/>  
1
2
3
4

非80端口配置 
Nginx增加以下配置 
proxy_set_header Host $host:$server_port; 非80端口 ，用80端口时 不需要$server_port 
proxy_set_header X-Real-IP $remote_addr; 
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
proxy_set_header X-Forwarded-Proto $scheme; 


Tomcat server.xml配置 
<Engine name="Catalina" defaultHost="localhost"> 
<Valve className="org.apache.catalina.valves.RemoteIpValve" 
remoteIpHeader="X-Forwarded-For" 
protocolHeader="X-Forwarded-Proto" 
protocolHeaderHttpsValue="https" httpsServerPort="7001"/> 非80端口时，必须增加httpsServerPort配置，不然request.getServerPort()方法返回 443. 
</Engine>

关于 RemoteIpValve,可以阅读下 doc

http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html

上周有幸给部门的小伙伴分享了一些JVM相关的知识，在整个做PPT的过程中，也是对一个领域的碎片知识的整理，本文将针对虚拟机GC相关的一些内容进行整理，本文不会涉及到G1收集器。

在Hotspot VM实现中，主要有两大类GC

1. Partial GC：并不会堆整个GC堆进行收集
   • young gc：只收集 young gen 的GC
   • old gc：只收集 old gen 的GC，只有CMS的 concurrent collection
   • mixed GC：收集整个 young gen 以及部分 old gen 的GC，只有G1
2. Full GC：收集整个堆，包括young gen、old gen、perm gen（如果存在的话）等

其实在各种文章或书上还可以看到Minor GC、Major GC的字眼，其中minor GC和young gc对应，而Major GC通常是和Full GC是等价的，由于HotSpot VM发展了这么多年，外界对各种名词的解读已经完全混乱了，所以Major GC有时也可能是指old gc，在下定论之前一定要先问清楚。

单线程、并行、并发

在GC收集器实现中，分为了单线程、并行和并发。
单线程收集器：如 Serial GC，这个比较好理解，即垃圾收集过程中只有单一线程在进行收集工作，实现也最简单。

并行收集器：如Parallel GC，每次运行时，不管是YGC，还是FGC，会 stop-the-world，暂停所有的用户线程，并采用多个线程同时进行垃圾收集。

并发收集器：如CMS GC，在新生代进行垃圾收集时和并行收集器类似，都是并行收集（当然具体算法中，你也可以设置成采用单线程进行收集），而且都会stop-the-world，主要的区别在于老年代的收集上，CMS在老年代进行垃圾收集时，大部分时间可以和用户线程并发执行的，只有小部分的时间stop-the-world，这就是它的优势，可以大大降低应用的暂停时间，当然也是有劣势的。

算法组合

Hotspot VM实现的几种GC算法组合中，其中CMS GC使用最广，因为现在都是大内存时代。

1、Serial GC

Serial generational collector (-XX:+UseSerialGC)
是全局范围的Full GC，这种算法组合是最早出现的，当年的Java堆内存大小都还不大，使用Serial GC进行单线程收集，还感觉不出来GC耗时导致应用暂停的问题

2、Parallel GC

Parallel for young space, serial for old space generational collector (-XX:+UseParallelGC).
Parallel for young and old space generational collector (-XX:+UseParallelOldGC)
当Java堆慢慢变大时，发现已经无法忍受GC耗时带来的应用暂停了，出现了Parallel GC，采用多线程的方式进行垃圾收集，很明显可以提升垃圾收集效率。

3、CMS GC

Concurrent mark sweep with serial young space collector (-XX:+UseConcMarkSweepGC
–XX:-UseParNewGC)
Concurrent mark sweep with parallel young space collector (-XX:+UseConcMarkSweepGC)
当Java堆达到更大时，比如8G，使用Parallel GC带来的应用暂停已经很明显了，所有又出现了 CMS GC，这是目前我看到线上环境使用的比较多的GC策略，在参数中添加-XX:+UseConcMarkSweepGC，对于 young gen，会自动选用 ParNewGC，不需要额外添加 -XX:+UseParNewGC。

CMS虽然好，因为它的特殊算法，大部分的收集过程可以和用户线程并发执行，大大降低应用的暂停时间，不过也会带来负面影响，在收集完 old gen 之后，CMS并不会做整理过程，会产生空间碎片，如果这些碎片空间得不到利用，就会造成空间的浪费，整个过程中可能发生 concurrent mode failure，导致一次真正意义的 full gc，采用单线程对整个堆（young+old+perm） 使用MSC（Mark-Sweep-Compact）进行收集，这个过程意味着很慢很慢很慢，而且这个碎片问题是无法预测的.

4、G1 GC

G1 garbage collector (-XX:+UseG1GC)，本文不对G1进行介绍

触发条件

young gc

对于 young gc，触发条件似乎要简单很多，当 eden 区的内存不够时，就会触发young gc，我们看看在 eden 区给对象分配一块内存是怎样一个过程，画了一个简单的流程图，我一直觉得一个好的示意图可以让一个枯燥的过程变得更有意思。

在 eden 区分配空间内存不足时有两种情况，为对象分配内存、为TLAB分配内存，总之就是内存不够，需要进行一次 young gc 为eden区腾出空间为后续的内存申请做准备，然后由一个用户线程通知VM Thread，接下去要执行一次 young gc。

full gc

1、old gen 空间不足

当创建一个大对象、大数组时，eden 区不足以分配这么大的空间，会尝试在old gen 中分配，如果这时 old gen 空间也不足时，会触发 full gc，为了避免上述导致的 full gc，调优时应尽量让对象在 young gc 时就能够被回收，还有不要创建过大的对象和数组。

2、统计得到的 young gc 晋升到 old gen的对象平均总大小大于old gen 的剩余空间

当准备触发一次 young gc时，会判断这次 young gc 是否安全，这里所谓的安全是当前老年代的剩余空间可以容纳之前 young gc 晋升对象的平均大小，或者可以容纳 young gen 的全部对象，如果结果是不安全的，就不会执行这次 young gc，转而执行一次 full gc

3、perm gen 空间不足

如果有perm gen的话，当系统中要加载的类、反射的类和调用的方法较多，而且perm gen没有足够空间时，也会触发一次 full gc

4、ygc出现 promotion failure

promotion failure 发生在 young gc 阶段，即 cms 的 ParNewGC，当对象的gc年龄达到阈值时，或者 eden 的 to 区放不下时，会把该对象复制到 old gen，如果 old gen 空间不足时，会发生 promotion failure，并接下去触发full gc

在GC日志中，有时会看到 concurrent mode failure 关键字，这是因为什么原因导致的问题呢? 对这一块的理解，很多文章都是说因为 concurrent mode failure 导致触发full gc，其实应该反过来，是full gc 导致的 concurrent mode failure，在cms gc的算法实现中，通常说的cms是由一个后台线程定时触发的，默认每2秒检查一次old gen的内存使用率，当 old gen 的内存使用率达到-XX:CMSInitiatingOccupancyFraction设置的值时，会触发一次 cms gc，对 old gen 进行并发收集，而真正的 full gc 是通过 vm thread线程触发的，而且在判断当前ygc会失败的情况下触发full gc，如上一次ygc出现了promotion failure，如果执行 full gc 时，发现后台线程正在执行 cms gc，就会导致 concurrent mode failure。

对于以上这些情况，CMSInitiatingOccupancyFraction参数的设置就显得尤为重要，设置的太大的话，发生CMS时的剩余空间太小，在ygc的时候容易发生promotion failure，导致 concurrent mode failure 发生的概率就增大，如果设置太小的话，会导致 cms gc 的频率会增加，所以需要根据应用的需求对该参数进行调优。

5、执行 System.gc()、jmap -histo:live <pid>、jmap -dump ...

参考资料
Major GC和Full GC的区别是什么？触发条件呢

个人公众号

from:http://www.cnblogs.com/foohack/p/5627163.html

Cassandra note:

依赖：需要java 8 （http://www.oracle.com/technetwork/java/javase/downloads/index.html）

数据模型: 与Hbase同样是属于列式数据库，Key-Value存储系统。（http://www.ibm.com/developerworks/cn/opensource/os-cn-cassandra/）
http://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling

集群中的数据是靠partion key的hash code均匀映射到不同的节点上去的。partionkey是primary key的第一个元素，所以选一个好的主
key才能使数据更好的均匀存储在不同的节点上。

Cassandra的节点实例叫Cluster，里面可以包含一个或多个键空间(KeysSpace).键空间是存放列族（Column Family）的容器，相当于
关系数据中的database，schema。列族是存放列（column）的容器，类似与关系数据库中的table。超级列（Super column）是一种
特殊的列，它的value值可以包含多个column。 columns是cassandra的最基本单位，有name，value，timestamp构成。

列式数据库的优点: 
1.适合存储大量数据，而不是小量数据。因为数据是是基于列存储的，所以可以忽略不需要的列的数据，提高查找效率。
与之对应的是行数据库。
2.高压缩比。节省存储空间，也节省CPU和内存。
3.高装载速度。

列式数据库的缺点:
1.不适合扫描小量数据。
2.不适合随机更新数据。
3.不适合做含有删除的更新的实时操作。

查询数据:
Cassandra有自己的一套查询语言CQL（类似SQL），在数据访问方式上亦是如此。客户端可以与集群中的任意节点相连，并访问任意的数据。

cassandra在写入数据之前需要记录日志(CommitLog),然后数据开始写入到 Column Family 对应的 Memtable 中，
Memtable 是一种按照 key 排序数据的内存结构，在满足一定条件时，再把 Memtable 的数据批量的刷新到磁盘上，存储为 SSTable 。

存储二进制大文件（不推荐存储）：http://wiki.apache.org/cassandra/FAQ#large_file_and_blob_storage

Cassandra的GUI管理工具整理：http://wiki.apache.org/cassandra/FAQ#gui 也有自带的CLI工具连接Cassandra

Cassandra集群种子的概念（很重要）：http://wiki.apache.org/cassandra/FAQ#seed
类似与Cassandra集群的初始化节点（集线器），各个节点通过种子节点互相学习（交换）各自的数据（状态），所以新加入的Cassandra节点都需要给它
指定种子节点，下次启动的时候就不需要了。

Cassandra 的C++ 接口：
Cassandra的各种编程语言的接口是有Thrift这个开源工具生成的，语言无关的Thrift输入文件（cassandra.thrift）Cassandra已经自带
，安装thrift运行 thrift.exe -gen cpp cassandra.thrift生成就可以了。 cpp的接口依赖thrift的核心库叫libthrift，libthrift依赖boost1.53.0
版本和openssl

Cassandra windows 安装配置:
解压，配置好CASSANDRA_HOME环境变量的路径（也就是你解压的cassandra根目录），然后运行bin下的cassandra.bat，如果发现logs
目录底下的system.log文件中有INFO - Starting up server gossip，那么恭喜你，Cassandra已经在你的本机启动起来了。

*****************************************Cassandra的基本操作************************************************

数据模型：多维的hash表，每行可以有不同的列。每行都有个键. keyspace包含若干列族
(列族和表是同一个概念：http://stackoverflow.com/questions/18824390/whats-the-difference-between-creating-a-table-and-creating-a-columnfamily-in-ca)，
keyspace在逻辑上是容纳列族和某些配置属性的命名空间。列族定义了相关的数据名字和它们的排序方式。

入门必读：http://wiki.apache.org/cassandra/GettingStarted

CQLSH中运行外部创建的cql脚本文件: SOURCE '[file_path]'

键空间的创建: 
CREATE KEYSPACE [keyspace_name] WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};

----键空间的创建要附带副本属性，class可以指定NetworkTopologyStrategy或SimpleStrategy。SimpleStrategy只用于测试评估Cassandra
生产环境使用NetworkTopologyStrategy. 键空间类似关系型数据库中的数据库（database）

键空间的修改：
ALTER KEYSPACE [keyspace_name] WITH REPLICATION = {};

键空间的删除:
DROP KEYSPACE [keyspace_name]

键空间的使用:
USE [keyspace_name]

列出已存在的键空间:
DESCRIBE keyspaces;

列出某个键空间下的所有表：
USE [keyspace_name];
DESCRIBE tables;

列出某个键空间下的所有列族：
USE [keyspace_name];
DESCRIBE columnfamilies;

列出特定的表的基本信息：
DESCRIBE TABLE [keyspace_name].[table_name];

建表：
http://docs.datastax.com/en/cql/3.1/cql/cql_using/create_table_t.html
表的主键可以是复合的，就是多个列组成一个主键：
CREATE TABLE emp (
empID int,
deptID int,
first_name varchar,
last_name varchar,
PRIMARY KEY (empID, deptID)); //主键的第一个键就是分区键（empID），分区键的目的就是把表中的数据均分到集群中的
各个节点中

更改表：
ALERT TABLE [table_name] [some change]
https://docs.datastax.com/en/cql/3.0/cql/cql_reference/alter_table_r.html
没办法更改主键，因为主键涉及到数据的物理储存

给表的某列建立索引：
CREATE INDEX ON [table_name] (column_name);

查表：
SELCT [column_name] FROM [keyspace].[table_name] WHERE [column_name] = [value] //其中column_name必须是主键的其中部分，
如果有多个条件必须其中有一个是分区键

更新表中的值:
UPDATE [keyspace].[table_name] SET [column_name] = [new_value] WHERE [column_name]=[value]

删除表中列或行：
删除列中值：DELETE [column_name] FROM [table_name] WHERE [column_name] = [value] # 同查表
删除一整行：DELETE FROM [table_name] WHERE [column_name] = [value] #同上

自定义数据类型(http://docs.datastax.com/en/cql/3.1/cql/cql_using/cqlUseUDT.html):
CREATE TYPE [keyspace_name].[type_name] (
street text,
city text,
zip_code int,
phones set<text>
);
自定义的数据类型的字面值是json-style的风格。

内建的数据类型(http://docs.datastax.com/en/cql/3.1/cql/cql_reference/cql_data_types_c.html)：
ascii,bigint,blob,boolean,counter,double,float,inet,int,list,map,set,text,uuid,
timestamp,tuple,varchar(UTF-8 encoded string) ,varint

查看集群信息：
SELECT * FROM system.peers;

本地帮助文档的查看:
HELP [COMMAND]
比如：查看创建键空间 HELP CREATE_KEYSPACE;

CQL语句支持多语句提交（Batch）：
可以减少Node之间的流量交换，类似于事务，是原子的。
http://docs.datastax.com/en/cql/3.1/cql/cql_reference/batch_r.html#reference_ds_djf_xdd_xj__batch-conditional
http://docs.datastax.com/en/cql/3.1/cql/cql_using/use-batch-static.html

给数据设置存活期：
超过存活期的数据，将被销毁。
INSERT INTO [table_name]
([column_name1], [column_name2])
VALUES ([column_value1], [column_value2]) USING TTL 86400; # 86400 sec 大概是一天的存活期
是给column_name2设置的

UPDATE [table_name] USING TTL 432000 SET [column_name] = [column_value]
WHERE user_name = 'cbrown';

本文将深入浅出地讲解 JIT 编译器在 JVM 中的运作原理，使读者能够更好的理解 Java 底层机制并且为读者在 Java 性能优化领域打开更广的视野。

JIT 简介

JIT 是 just in time 的缩写, 也就是即时编译编译器。使用即时编译器技术，能够加速 Java 程序的执行速度。下面，就对该编译器技术做个简单的讲解。

首先，我们大家都知道，通常通过 javac 将程序源代码编译，转换成 java 字节码，JVM 通过解释字节码将其翻译成对应的机器指令，逐条读入，逐条解释翻译。很显然，经过解释执行，其执行速度必然会比可执行的二进制字节码程序慢很多。为了提高执行速度，引入了 JIT 技术。

在运行时 JIT 会把翻译过的机器码保存起来，以备下次使用，因此从理论上来说，采用该 JIT 技术可以接近以前纯编译技术。下面我们看看，JIT 的工作过程。

JIT 编译过程

当 JIT 编译启用时（默认是启用的），JVM 读入.class 文件解释后，将其发给 JIT 编译器。JIT 编译器将字节码编译成本机机器代码，下图展示了该过程。

图 1. JIT 工作原理图

回页首

Hot Spot 编译

当 JVM 执行代码时，它并不立即开始编译代码。这主要有两个原因：

首先，如果这段代码本身在将来只会被执行一次，那么从本质上看，编译就是在浪费精力。因为将代码翻译成 java 字节码相对于编译这段代码并执行代码来说，要快很多。

当然，如果一段代码频繁的调用方法，或是一个循环，也就是这段代码被多次执行，那么编译就非常值得了。因此，编译器具有的这种权衡能力会首先执行解释后的代码，然后再去分辨哪些方法会被频繁调用来保证其本身的编译。其实说简单点，就是 JIT 在起作用，我们知道，对于 Java 代码，刚开始都是被编译器编译成字节码文件，然后字节码文件会被交由 JVM 解释执行，所以可以说 Java 本身是一种半编译半解释执行的语言。Hot Spot VM 采用了 JIT compile 技术，将运行频率很高的字节码直接编译为机器指令执行以提高性能，所以当字节码被 JIT 编译为机器码的时候，要说它是编译执行的也可以。也就是说，运行时，部分代码可能由 JIT 翻译为目标机器指令（以 method 为翻译单位，还会保存起来，第二次执行就不用翻译了）直接执行。

第二个原因是最优化，当 JVM 执行某一方法或遍历循环的次数越多，就会更加了解代码结构，那么 JVM 在编译代码的时候就做出相应的优化。

我们将在后面讲解这些优化策略，这里，先举一个简单的例子：我们知道 equals() 这个方法存在于每一个 Java Object 中（因为是从 Object class 继承而来）而且经常被覆写。当解释器遇到 b = obj1.equals(obj2) 这样一句代码，它则会查询 obj1 的类型从而得知到底运行哪一个 equals() 方法。而这个动态查询的过程从某种程度上说是很耗时的。

寄存器和主存

其中一个最重要的优化策略是编译器可以决定何时从主存取值，何时向寄存器存值。考虑下面这段代码：

清单 1. 主存 or 寄存器测试代码

public class RegisterTest {  private int sum;   public void calculateSum(int n) {  for (int i = 0; i < n; ++i) {  sum += i;  }  } }

在某些时刻，sum 变量居于主存之中，但是从主存中检索值是开销很大的操作，需要多次循环才可以完成操作。正如上面的例子，如果循环的每一次都是从主存取值，性能是非常低的。相反，编译器加载一个寄存器给 sum 并赋予其初始值，利用寄存器里的值来执行循环，并将最终的结果从寄存器返回给主存。这样的优化策略则是非常高效的。但是线程的同步对于这种操作来说是至关重要的，因为一个线程无法得知另一个线程所使用的寄存器里变量的值，线程同步可以很好的解决这一问题，有关于线程同步的知识，我们将在后续文章中进行讲解。

寄存器的使用是编译器的一个非常普遍的优化。

回到之前的例子，JVM 注意到每次运行代码时，obj1 都是 java.lang.String 这种类型，那么 JVM 生成的被编译后的代码则是直接调用 String.equals() 方法。这样代码的执行将变得非常快，因为不仅它是被编译过的，而且它会跳过查找该调用哪个方法的步骤。

当然过程并不是上面所述这样简单，如果下次执行代码时，obj1 不再是 String 类型了，JVM 将不得不再生成新的字节码。尽管如此，之后执行的过程中，还是会变的更快，因为同样会跳过查找该调用哪个方法的步骤。这种优化只会在代码被运行和观察一段时间之后发生。这也就是为什么 JIT 编译器不会理解编译代码而是选择等待然后再去编译某些代码片段的第二个原因。

回页首

初级调优：客户模式或服务器模式

JIT 编译器在运行程序时有两种编译模式可以选择，并且其会在运行时决定使用哪一种以达到最优性能。这两种编译模式的命名源自于命令行参数（eg: -client 或者 -server）。JVM Server 模式与 client 模式启动，最主要的差别在于：-server 模式启动时，速度较慢，但是一旦运行起来后，性能将会有很大的提升。原因是：当虚拟机运行在-client 模式的时候，使用的是一个代号为 C1 的轻量级编译器，而-server 模式启动的虚拟机采用相对重量级代号为 C2 的编译器。C2 比 C1 编译器编译的相对彻底，服务起来之后，性能更高。

通过 java -version 命令行可以直接查看当前系统使用的是 client 还是 server 模式。例如：

图 2. 查看编译模式

回页首

中级编译器调优

大多数情况下，优化编译器其实只是选择合适的 JVM 以及为目标主机选择合适的编译器（-cient，-server 或是-xx:+TieredCompilation）。多层编译经常是长时运行应用程序的最佳选择，短暂应用程序则选择毫秒级性能的 client 编译器。

优化代码缓存

当 JVM 编译代码时，它会将汇编指令集保存在代码缓存。代码缓存具有固定的大小，并且一旦它被填满，JVM 则不能再编译更多的代码。

我们可以很容易地看到如果代码缓存很小所具有的潜在问题。有些热点代码将会被编译，而其他的则不会被编译，这个应用程序将会以运行大量的解释代码来结束。

这是当使用 client 编译器模式或分层编译时很频繁的一个问题。当使用普通 server 编译器模式时，编译合格的类的数量将被填入代码缓存，通常只有少量的类会被编译。但是当使用 client 编译器模式时，编译合格的类的数量将会高很多。

在 Java 7 版本，分层编译默认的代码缓存大小经常是不够的，需要经常提高代码缓存大小。大型项目若使用 client 编译器模式，则也需要提高代码缓存大小。

现在并没有一个好的机制可以确定一个特定的应用到底需要多大的代码缓存。因此，当需要提高代码缓存时，这将是一种凑巧的操作，一个通常的做法是将代码缓存变成默认大小的两倍或四倍。

可以通过 –XX:ReservedCodeCacheSize=Nflag（N 就是之前提到的默认大小）来最大化代码缓存大小。代码缓存的管理类似于 JVM 中的内存管理：有一个初始大小（用-XX:InitialCodeCacheSize=N 来声明）。代码缓存的大小从初始大小开始，随着缓存被填满而逐渐扩大。代码缓存的初始大小是基于芯片架构（例如 Intel 系列机器，client 编译器模式下代码缓存大小起始于 160KB，server 编译器模式下代码缓存大小则起始于 2496KB）以及使用的编译器的。重定义代码缓存的大小并不会真正影响性能，所以设置 ReservedCodeCacheSize 的大小一般是必要的。

再者，如果 JVM 是 32 位的，那么运行过程大小不能超过 4GB。这包括了 Java 堆，JVM 自身所有的代码空间（包括其本身的库和线程栈），应用程序分配的任何的本地内存，当然还有代码缓存。

所以说代码缓存并不是无限的，很多时候需要为大型应用程序来调优（或者甚至是使用分层编译的中型应用程序）。比如 64 位机器，为代码缓存设置一个很大的值并不会对应用程序本身造成影响，应用程序并不会内存溢出，这些额外的内存预定一般都是被操作系统所接受的。

编译阈值

在 JVM 中，编译是基于两个计数器的：一个是方法被调用的次数，另一个是方法中循环被回弹执行的次数。回弹可以有效的被认为是循环被执行完成的次数，不仅因为它是循环的结尾，也可能是因为它执行到了一个分支语句，例如 continue。

当 JVM 执行一个 Java 方法，它会检查这两个计数器的总和以决定这个方法是否有资格被编译。如果有，则这个方法将排队等待编译。这种编译形式并没有一个官方的名字，但是一般被叫做标准编译。

但是如果方法里有一个很长的循环或者是一个永远都不会退出并提供了所有逻辑的程序会怎么样呢？这种情况下，JVM 需要编译循环而并不等待方法被调用。所以每执行完一次循环，分支计数器都会自增和自检。如果分支计数器计数超出其自身阈值，那么这个循环（并不是整个方法）将具有被编译资格。

这种编译叫做栈上替换（OSR），因为即使循环被编译了，这也是不够的：JVM 必须有能力当循环正在运行时，开始执行此循环已被编译的版本。换句话说，当循环的代码被编译完成，若 JVM 替换了代码（前栈），那么循环的下个迭代执行最新的被编译版本则会更加快。

标准编译是被-XX:CompileThreshold=Nflag 的值所触发。Client 编译器模式下，N 默认的值 1500，而 Server 编译器模式下，N 默认的值则是 10000。改变 CompileThreshold 标志的值将会使编译器相对正常情况下提前（或推迟）编译代码。在性能领域，改变 CompileThreshold 标志是很被推荐且流行的方法。事实上，您可能知道 Java 基准经常使用此标志（比如：对于很多 server 编译器来说，经常在经过 8000 次迭代后改变次标志）。

我们已经知道 client 编译器和 server 编译器在最终的性能上有很大的差别，很大程度上是因为编译器在编译一个特定的方法时，对于两种编译器可用的信息并不一样。降低编译阈值，尤其是对于 server 编译器，承担着不能使应用程序运行达到最佳性能的风险，但是经过测试应用程序我们也发现，将阈值从 8000 变成 10000，其实有着非常小的区别和影响。

检查编译过程

中级优化的最后一点其实并不是优化本身，而是它们并不能提高应用程序的性能。它们是 JVM（以及其他工具）的各个标志，并可以给出编译工作的可见性。它们中最重要的就是--XX:+PrintCompilation（默认状态下是 false）。

如果 PrintCompilation 被启用，每次一个方法（或循环）被编译，JVM 都会打印出刚刚编译过的相关信息。不同的 Java 版本输出形式不一样，我们这里所说的是基于 Java 7 版本的。

编译日志中大部分的行信息都是下面的形式：

清单 2. 日志形式

timestamp compilation_id attributes (tiered_level) method_name size depot

这里 timestamp 是编译完成时的时间戳，compilation_id 是一个内部的任务 ID，且通常情况下这个数字是单调递增的，但有时候对于 server 编译器（或任何增加编译阈值的时候），您可能会看到失序的编译 ID。这表明编译线程之间有些快有些慢，但请不要随意推断认为是某个编译器任务莫名其妙的非常慢。

用 jstat 命令检查编译

要想看到编译日志，则需要程序以-XX:+PrintCompilation flag 启动。如果程序启动时没有 flag，您可以通过 jstat 命令得到有限的可见性信息。

Jstat 有两个选项可以提供编译器信息。其中，-compile 选项提供总共有多少方法被编译的总结信息（下面 6006 是要被检查的程序的进程 ID）：

清单 3 进程详情

% jstat -compiler 6006 CompiledFailedInvalid TimeFailedTypeFailedMethod 206 0 0 1.97 0

注意，这里也列出了编译失败的方法的个数信息，以及编译失败的最后一个方法的名称。

另一种选择，您可以使用-printcompilation 选项得到最后一个被编译的方法的编译信息。因为 jstat 命令有一个参数选项用来重复其操作，您可以观察每一次方法被编译的情况。举个例子：

Jstat 对 6006 号 ID 进程每 1000 毫秒执行一次： %jstat –printcompilation 6006 1000，具体的输出信息在此不再描述。

回页首

高级编译器调优

这一节我们将介绍编译工作剩下的细节，并且过程中我们会探讨一些额外的调优策略。调优的存在很大程度上帮助了 JVM 工程师诊断 JVM 自身的行为。如果您对编译器的工作原理很感兴趣，这一节您一定会喜欢。

编译线程

从前文中我们知道，当一个方法（或循环）拥有编译资格时，它就会排队并等待编译。这个队列是由一个或很多个后台线程组成。这也就是说编译是一个异步的过程。它允许程序在代码正在编译时被继续执行。如果一个方法被标准编译方式所编译，那么下一个方法调用则会执行已编译的方法。如果一个循环被栈上替换方式所编译，那么下一次循环迭代则会执行新编译的代码。

这些队列并不会严格的遵守先进先出原则：哪一个方法的调用计数器计数更高，哪一个就拥有优先权。所以即使当一个程序开始执行，并且有大量的代码需要编译，这个优先权顺序将帮助并保证最重要的代码被优先编译（这也是为什么编译 ID 在 PrintComilation 的输出结果中有时会失序的另一个原因）。

当使用 client 编译器时，JVM 启动一个编译线程，而 server 编译器有两个这样的线程。当分层编译生效时，JVM 会基于某些复杂方程式默认启动多个 client 和 server 线程，涉及双日志在目标平台上的 CPU 数量。如下图所示：

分层编译下 C1 和 C2 编译器线程默认数量：

图 3. C1 和 C2 编译器默认数量

编译器线程的数量可以通过-XX:CICompilerCount=N flag 进行调节设置。这个数量是 JVM 将要执行队列所用的线程总数。对于分层编译，三分之一的（至少一个）线程被用于执行 client 编译器队列，剩下的（也是至少一个）被用来执行 server 编译器队列。

在何时我们应该考虑调整这个值呢？如果一个程序被运行在单 CPU 机器上，那么只有一个编译线程会更好一些：因为对于某个线程来说，其对 CPU 的使用是有限的，并且在很多情况下越少的线程竞争资源会使其运行性能更高。然而，这个优势仅仅局限于初始预热阶段，之后，这些具有编译资格的方法并不会真的引起 CPU 争用。当一个股票批处理应用程序运行在单 CPU 机器上并且编译器线程被限制成只有一个，那么最初的计算过程将比一般情况下快 10%（因为它没有被其他线程进行 CPU 争用）。迭代运行的次数越多，最初的性能收益就相对越少，直到所有的热点方法被编译完性能收益也随之终止。

回页首

结束语

本文详细介绍了 JIT 编译器的工作原理。从优化的角度讲，最简单的选择就是使用 server 编译器的分层编译技术，这将解决大约 90%左右的与编译器直接相关的性能问题。最后，请保证代码缓存的大小设置的足够大，这样编译器将会提供最高的编译性能。

转载自点击打开链接

from:http://www.cnblogs.com/insistence/p/5901457.html

1. 什么是Just In Time编译器?

Hot Spot 编译

当 JVM 执行代码时，它并不立即开始编译代码。这主要有两个原因：

首先，如果这段代码本身在将来只会被执行一次，那么从本质上看，编译就是在浪费精力。因为将代码翻译成 java 字节码相对于编译这段代码并执行代码来说，要快很多。

当 然，如果一段代码频繁的调用方法，或是一个循环，也就是这段代码被多次执行，那么编译就非常值得了。因此，编译器具有的这种权衡能力会首先执行解释后的代 码，然后再去分辨哪些方法会被频繁调用来保证其本身的编译。其实说简单点，就是 JIT 在起作用，我们知道，对于 Java 代码，刚开始都是被编译器编译成字节码文件，然后字节码文件会被交由 JVM 解释执行，所以可以说 Java 本身是一种半编译半解释执行的语言。Hot Spot VM 采用了 JIT compile 技术，将运行频率很高的字节码直接编译为机器指令执行以提高性能，所以当字节码被 JIT 编译为机器码的时候，要说它是编译执行的也可以。也就是说，运行时，部分代码可能由 JIT 翻译为目标机器指令（以 method 为翻译单位，还会保存起来，第二次执行就不用翻译了）直接执行。

第二个原因是最优化，当 JVM 执行某一方法或遍历循环的次数越多，就会更加了解代码结构，那么 JVM 在编译代码的时候就做出相应的优化。

我 们将在后面讲解这些优化策略，这里，先举一个简单的例子：我们知道 equals() 这个方法存在于每一个 Java Object 中（因为是从 Object class 继承而来）而且经常被覆写。当解释器遇到 b = obj1.equals(obj2) 这样一句代码，它则会查询 obj1 的类型从而得知到底运行哪一个 equals() 方法。而这个动态查询的过程从某种程度上说是很耗时的。

在主流商用JVM（HotSpot、J9）中，Java程序一开始是通过解释器（Interpreter）进行解释执行的。当JVM发现某个方法或代码块运行特别频繁时，就会把这些代码认定为“热点代码（Hot Spot Code）”，然后JVM会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为：即时编译器（Just In Time Compiler，JIT）

JIT编译器是“动态编译器”的一种，相对的“静态编译器”则是指的比如：C/C++的编译器

JIT并不是JVM的必须部分，JVM规范并没有规定JIT必须存在，更没有限定和指导JIT。但是，JIT性能的好坏、代码优化程度的高低却是衡量一款JVM是否优秀的最关键指标之一，也是虚拟机中最核心且最能体现虚拟机技术水平的部分。

2. 编译器与解释器

首先，不是所有JVM都采用编译器和解释器并存的架构，但主流商用虚拟机，都同时包含这两部分。

2.1 配合过程

1. 当程序需要迅速启动然后执行的时候，解释器可以首先发挥作用，编译器不运行从而省去编译时间，立即执行程序

2. 在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获得更高的执行效率

3. 当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行来节约内存；反之，则可以使用编译执行来提升效率。

4. 同时，解释器还可以作为编译器（C2才会激进优化）激进优化时的一个“逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化假设不成立。如：加载了新类后，类型继承结构出现变化，出现“罕见陷阱（Uncommon Trap）”时，可以通过逆优化（Deoptimization）退回到解释状态继续执行 
   (部分没有解释器的虚拟机，也会采用不进行激进优化的C1编译器担任“逃生门”的角色)

   

2.2 解释器 - Interpreter

Interpreter解释执行class文件，好像JavaScript执行引擎一样

特殊的例子：

• 最早的Sun Classic VM只有Interpreter
• BEA JRockit VM则只有Compiler，但它主要面向服务端应用，部署在其上的应用不重点关注启动时间

2.3 编译器 - Compiler

只说HotSpot JVM

1. C1和C2：

HotSpot虚拟机内置了两个即时编译器，分别称为Client Compiler和Server Compiler，习惯上将前者称为C1，后者称为C2

2. 使用C1还是C2？

HotSpot默认采用解释器和其中一个编译器直接配合的方式工作，使用那个编译器取决于虚拟机运行的模式，HotSpot会根据自身版本和宿主机器硬件性能自动选择模式，用户也可以使用“-client”或”-server”参数去指定

1. 混合模式（Mixed Mode） 
   默认的模式，如上面描述的这种方式就是mixed mode

2. 解释模式（Interpreted Mode） 
   可以使用参数“-Xint”，在此模式下全部代码解释执行

3. 编译模式（Compiled Mode） 
   参数“-Xcomp”，此模式优先采用编译，但是无法编译时也会解释（在最新的HotSpot中此参数被取消）

   可以看到，我的JVM现在是mixed mode 
   

重要：↓

在JDK1.7（1.7仅包括Server模式）之后，HotSpot就不是默认“采用解释器和其中一个编译器”配合的方式了，而是采用了分层编译，分层编译时C1和C2有可能同时工作

3. 分层编译

3.1 为什么要分层编译？

由于编译器compile本地代码需要占用程序时间，要编译出优化程度更高的代码所花费的时间可能更长，且此时解释器还要替编译器收集性能监控信息，这对解释执行的速度也有影响

所以，为了在程序启动响应时间与运行效率之间达到最佳平衡，HotSpot在JDK1.6中出现了分层编译（Tiered Compilation）的概念并在JDK1.7的Server模式JVM中作为默认策略被开启

3.2 编译层 tier（或者叫级别）

分层编译根据编译器编译、优化的规模与耗时，划分了不同的编译层次（不只以下3种），包括：

• 第0层，程序解释执行（没有编译），解释器不开启性能监控功能，可触发第1层编译。

• 第1层，也称C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑

• 第2层（或2层以上），也称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化

实施分层编译后，C1和C2将会同时工作，许多代码会被多次编译，用C1获取更高的编译速度，用C2来获取更好的编译质量，且在解释执行的时候解释器也无须再承担收集性能监控信息的任务

4. 编译对象与触发条件

1. 谁被编译了？

编译对象就是之前说的“热点代码”，它有两类：

1. 被多次调用的方法 
   
   • 一个方法被多次调用，理应称为热点代码，这种编译也是虚拟机中标准的JIT编译方式
2. 被多次执行的循环体 
   
   • 编译动作由循环体出发，但编译对象依然会以整个方法为对象；
   • 这种编译方式由于编译发生在方法执行过程中，因此形象的称为：栈上替换（On Stack Replacement- OSR编译，即方法栈帧还在栈上，方法就被替换了）

2. 触发条件

1. 综述

上面的方法和循环体都说“多次”，那么多少算多？换个说法就是编译的触发条件。

判断一段代码是不是热点代码，是不是需要触发JIT编译，这样的行为称为：热点探测（Hot Spot Detection），有几种主流的探测方式：

1. 基于计数器的热点探测（Counter Based Hot Spot Detection） 
   虚拟机会为每个方法（或每个代码块）建立计数器，统计执行次数，如果超过阀值那么就是热点代码。缺点是维护计数器开销。

2. 基于采样的热点探测（Sample Based Hot Spot Detection） 
   虚拟机会周期性检查各个线程的栈顶，如果某个方法经常出现在栈顶，那么就是热点代码。缺点是不精确。

3. 基于踪迹的热点探测（Trace Based Hot Spot Detection） 
   Dalvik中的JIT编译器使用这种方式

2. HotSpot

HotSpot使用的是第1种，因此它为每个方法准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）

1. 方法计数器

   • 默认阀值，在Client模式下是1500次，Server是10000次，可以通过参数“-XX:CompileThreshold”来设定

   • 当一个方法被调用时会首先检查是否存在被JIT编译过得版本，如果存在则使用此本地代码来执行；如果不存在，则将方法计数器+1，然后判断“方法计数器和回边计数器之和”是否超过阀值，如果是则会向编译器提交一个方法编译请求

   • 默认情况下，执行引擎并不会同步等待上面的编译完成，而是会继续解释执行。当编译完成后，此方法的调用入口地址会被系统自动改写为新的本地代码地址

   • 还有一点，热度是会衰减的，也就是说不是仅仅+，也会-，热度衰减动作是在虚拟机的GC执行时顺便进行的

2. 回边计数器

   • 回边，顾名思义，只有执行到大括号”}”时才算+1

   • 默认阀值，Client下13995，Server下10700

   • 它的调用逻辑和方法计数器差不多，只不过遇到回边指令时+1、超过阀值时会提交OSR编译请求以及这里没有热度衰减

5. 编译过程

编译过程是在后台线程（daemon）中完成的，可以通过参数“-XX:-BackgroundCompilation”来禁止后台编译，但此时执行线程就会同步等待编译完成才会执行程序

1. Client Compiler 
   C1编译器是一个简单快速的三段式编译器，主要关注“局部性能优化”，放弃许多耗时较长的全局优化手段 
   过程：class -> 1. 高级中间代码 -> 2. 低级中间代码 -> 3. 机器代码
2. Server Compiler 
   C2是专门面向服务器应用的编译器，是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度。

使用参数“-XX:+PrintCompilation”会让虚拟机在JIT时把方法名称打印出来，如图： 

6. Java和C/C++的编译器对比

这里不是比Java和C/C++谁快这种大坑问题，只是比较编译器（我认为开发效率上Java快，执行效率上C/C++快）

这种对比代表了经典的即时编译器与静态编译期的对比，其实总体来说Java编译器有优有劣。主要就是动态编译时间压力大能做的优化少，还要做一些动态校验。而静态编译器无法实现一些开发上很有用的动态特性

JVM自动监控这所有方法的执行，如果某个方法是热点方法，JVM就计划把该方法的字节码代码编译成本地机器代码，编译成机器代码的过程是在独立线程中执行的，不会影响程序的执行，这个过程就是JIT（just in time）。

JIT针对下面的几种方式进行优化

• 把bytecode编译成本地代码
• 单态调度（monomorphic dispatch），当个对象的类和其父类间有方法重写时，JVM调用对象的方法可以通过对象的类型路径来判断应该调用父类的方法还是子类的方法，对此JIT进行优化，这种优化是C++所不具备的，C++中需要查找虚函数表。
• 循环展开（loop unrolling）
• 类型锐化
• 逃逸分析（escape analysis）
• 移除无用代码（这个现在IDE会提示我们的，比如：intellij idea）
• Intrinsics
• 分支预测
• 方法内联（inlining，对性能的提升很大），默认情况，<= 35字节码的方法可以进行内联，通过这个来修改内联方法的最大值：-XX:MaxInlineSize=，通过-XX:FreqInlineSize=来设置频繁调用方法的临界值

这些优化方法通常是层层依赖的，所以当JIT优化后的代码被JVM应用，就会开始尝试进行更上一层次的优化。因此我们写代码的时候，应该尽量往这些优化方式上面靠。

输出JIT编译过的方法

在JVM启动参数中添加如下的启动参数：

-XX:+PrintCompilation 

输出内容类似这样：

31    23 s!    sun.misc.URLClassPath::getLoader (136 bytes) 

• 第1列  31：为JVM启动后到该方法被编译相隔的时间，单位为毫秒
• 第2列  23：编译ID，用来跟踪一个方法的编译、优化、深度优化
• 第3列  s!：s是指该方法是synchronized，感叹号是指该方法有对异常的处理
• 第4列  sun.misc.URLClassPath::getLoader：被编译的方法
• 第5列  (136 bytes)：方法的字节大小

输出JIT编译的细节信息

通过添加参数-XX:+PrintCompilation，可以看到的信息其实并不具体，比如：那些方法进行了内联，内联后的二进制代码是怎么样的都没有。而要输出JIT编译的细节信息，就需要在JVM启动参数中添加这个参数：

-XX:+LogCompilation -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+PrintAssembly 

输出的编译信息，默认情况是在启动JVM的目录下一个名为：hotspot_pid<PID>.log的文件

如果想指定文件路径和文件名的话，可以再添加一个启动参数：

-XX:LogFile=<pathto file> 

输出的是一个很大的xml文件，可能有几百兆，内容大致如下：

<nmethodcompile_id='2' compiler='C1' level='3'  entry='0x00000001023fe240' size='1224'  address='0x00000001023fe0d0' relocation_offset='288'  insts_offset='368' stub_offset='880' scopes_data_offset='1032'  scopes_pcs_offset='1104' dependencies_offset='1200'  nul_chk_table_offset='1208'  method='java/lang/String hashCode ()I' bytes='55' count='512'  backedge_count='8218' iicount='512' stamp='0.350'/> 

而且内容很难读懂，建议使用JITWatch（ https://github.com/AdoptOpenJDK/jitwatch/ ）的可视化界面来查看JIT编译的细节信息。同时JITWatch还可以给出很多优化建议，给我们有效的优化代码提供参考，详见下文。

JIT编译模式

C1: 通常用于那种快速启动的GUI应用，对应启动参数：－client

C2: 通常用于长时间允许的服务端应用，对应启动参数：－server

分层编译模式（tiered compilation）：这是自从Java SE 7以后的新特性，可通过添加启动参数来开启：

-XX:+TieredCompilation 

这个特性在应用启动阶段使用C1模式以达到快速启动的效果，一旦应用程序运行起来以后，C2模式将取代C1模式，以进行更深度的优化。在Java SE 8中，这个特性是默认的。

JITWatch

前面也提到了，JITWatch可以通过可视化界面来帮助我们分析JVM输出的JIT编译输出日志，还可以帮助我们静态分析jar中的代码是否符合JIT编译优化的条件，还可以以曲线图形的方式展示JIT编译的整个过程中的一些指标，非常好用的工具。

下载

JITWatch需要在github上把代码clone下来，然后用maven来运行，地址为： https://github.com/AdoptOpenJDK/jitwatch/

运行JITWwatch

在代码根目录下执行 launchUI.sh（ Linux/Mac）或则 launchUI.bat（windows）

如果你使用maven，也可以在代码根目录下这样运行（其他运行方式，请参考JITWatch的github首页）

mvncleancompileexec:java 

如果你使用的是mac，而且idk版本是jdk7，且运行mvn clean compile exec:java时出现下面的错误和异常时： 

Causedby: java.lang.NullPointerException  atcom.sun.t2k.MacFontFinder.initPSFontNameToPathMap(MacFontFinder.java:339)  atcom.sun.t2k.MacFontFinder.getFontNamesOfFontFamily(MacFontFinder.java:390)  atcom.sun.t2k.T2KFontFactory.getFontResource(T2KFontFactory.java:233)  atcom.sun.t2k.LogicalFont.getSlot0Resource(LogicalFont.java:184)  atcom.sun.t2k.LogicalFont.getSlotResource(LogicalFont.java:228)  atcom.sun.t2k.CompositeStrike.getStrikeSlot(CompositeStrike.java:86)  atcom.sun.t2k.CompositeStrike.getMetrics(CompositeStrike.java:132)  atcom.sun.javafx.font.PrismFontUtils.getFontMetrics(PrismFontUtils.java:31)  atcom.sun.javafx.font.PrismFontLoader.getFontMetrics(PrismFontLoader.java:466)  atjavafx.scene.text.Text.<init>(Text.java:153)  atcom.sun.javafx.scene.control.skin.Utils.<clinit>(Utils.java:52)  ... 13 more   [ERROR] Failedto executegoalorg.codehaus.mojo:exec-maven-plugin:1.5.0:java (default-cli) onprojectjitwatch-ui: Anexceptionoccuredwhile executingtheJavaclass. null: InvocationTargetException: Exceptionin Applicationstartmethod: ExceptionInInitializerError: NullPointerException -> [Help 1] 

请在org.adoptopenjdk.jitwatch.launch.LaunchUI类的main函数开头处添加下面的代码（或者直接使用我fork修改好的 JITWatch ）：

final Class<?> macFontFinderClass = Class.forName("com.sun.t2k.MacFontFinder"); final java.lang.reflect.FieldpsNameToPathMap = macFontFinderClass.getDeclaredField("psNameToPathMap"); psNameToPathMap.setAccessible(true); if (psNameToPathMap.get(null) == null) {     psNameToPathMap.set(         null, new java.util.HashMap<String, String>()); } final java.lang.reflect.FieldallAvailableFontFamilies = macFontFinderClass.getDeclaredField("allAvailableFontFamilies"); allAvailableFontFamilies.setAccessible(true); if (allAvailableFontFamilies.get(null) == null) {     allAvailableFontFamilies.set(         null, new String[] {}); } 

然后重新运行即可看到JITWatch的界面。

Reference

http://www.oracle.com/technetwork/articles/java/architect-evans-pt1-2266278.html

https://www.chrisnewland.com/images/jitwatch/HotSpot_Profiling_Using_JITWatch.pdf

摘要

HashMap是Java程序员使用频率最高的用于映射(键值对)处理的数据类型。随着JDK（Java Developmet Kit）版本的更新，JDK1.8对HashMap底层的实现进行了优化，例如引入红黑树的数据结构和扩容的优化等。本文结合JDK1.7和JDK1.8的区别，深入探讨HashMap的结构实现和功能原理。

简介

Java为数据结构中的映射定义了一个接口java.util.Map，此接口主要有四个常用的实现类，分别是HashMap、Hashtable、LinkedHashMap和TreeMap，类继承关系如下图所示：

下面针对各个实现类的特点做一些说明：

(1) HashMap：它根据键的hashCode值存储数据，大多数情况下可以直接定位到它的值，因而具有很快的访问速度，但遍历顺序却是不确定的。 HashMap最多只允许一条记录的键为null，允许多条记录的值为null。HashMap非线程安全，即任一时刻可以有多个线程同时写HashMap，可能会导致数据的不一致。如果需要满足线程安全，可以用 Collections的synchronizedMap方法使HashMap具有线程安全的能力，或者使用ConcurrentHashMap。

(2) Hashtable：Hashtable是遗留类，很多映射的常用功能与HashMap类似，不同的是它承自Dictionary类，并且是线程安全的，任一时间只有一个线程能写Hashtable，并发性不如ConcurrentHashMap，因为ConcurrentHashMap引入了分段锁。Hashtable不建议在新代码中使用，不需要线程安全的场合可以用HashMap替换，需要线程安全的场合可以用ConcurrentHashMap替换。

(3) LinkedHashMap：LinkedHashMap是HashMap的一个子类，保存了记录的插入顺序，在用Iterator遍历LinkedHashMap时，先得到的记录肯定是先插入的，也可以在构造时带参数，按照访问次序排序。

(4) TreeMap：TreeMap实现SortedMap接口，能够把它保存的记录根据键排序，默认是按键值的升序排序，也可以指定排序的比较器，当用Iterator遍历TreeMap时，得到的记录是排过序的。如果使用排序的映射，建议使用TreeMap。在使用TreeMap时，key必须实现Comparable接口或者在构造TreeMap传入自定义的Comparator，否则会在运行时抛出java.lang.ClassCastException类型的异常。

对于上述四种Map类型的类，要求映射中的key是不可变对象。不可变对象是该对象在创建后它的哈希值不会被改变。如果对象的哈希值发生变化，Map对象很可能就定位不到映射的位置了。

通过上面的比较，我们知道了HashMap是Java的Map家族中一个普通成员，鉴于它可以满足大多数场景的使用条件，所以是使用频度最高的一个。下文我们主要结合源码，从存储结构、常用方法分析、扩容以及安全性等方面深入讲解HashMap的工作原理。

内部实现

搞清楚HashMap，首先需要知道HashMap是什么，即它的存储结构-字段；其次弄明白它能干什么，即它的功能实现-方法。下面我们针对这两个方面详细展开讲解。

存储结构-字段

从结构实现来讲，HashMap是数组+链表+红黑树（JDK1.8增加了红黑树部分）实现的，如下如所示。

这里需要讲明白两个问题：数据底层具体存储的是什么？这样的存储方式有什么优点呢？

(1) 从源码可知，HashMap类中有一个非常重要的字段，就是 Node[] table，即哈希桶数组，明显它是一个Node的数组。我们来看Node[JDK1.8]是何物。

static class Node<K,V> implements Map.Entry<K,V> {         final int hash;    //用来定位数组索引位置         final K key;         V value;         Node<K,V> next;   //链表的下一个node          Node(int hash, K key, V value, Node<K,V> next) { ... }         public final K getKey(){ ... }         public final V getValue() { ... }         public final String toString() { ... }         public final int hashCode() { ... }         public final V setValue(V newValue) { ... }         public final boolean equals(Object o) { ... } } 

Node是HashMap的一个内部类，实现了Map.Entry接口，本质是就是一个映射(键值对)。上图中的每个黑色圆点就是一个Node对象。

(2) HashMap就是使用哈希表来存储的。哈希表为解决冲突，可以采用开放地址法和链地址法等来解决问题，Java中HashMap采用了链地址法。链地址法，简单来说，就是数组加链表的结合。在每个数组元素上都一个链表结构，当数据被Hash后，得到数组下标，把数据放在对应下标元素的链表上。例如程序执行下面代码：

    map.put("美团","小美"); 

系统将调用"美团"这个key的hashCode()方法得到其hashCode 值（该方法适用于每个Java对象），然后再通过Hash算法的后两步运算（高位运算和取模运算，下文有介绍）来定位该键值对的存储位置，有时两个key会定位到相同的位置，表示发生了Hash碰撞。当然Hash算法计算结果越分散均匀，Hash碰撞的概率就越小，map的存取效率就会越高。

如果哈希桶数组很大，即使较差的Hash算法也会比较分散，如果哈希桶数组数组很小，即使好的Hash算法也会出现较多碰撞，所以就需要在空间成本和时间成本之间权衡，其实就是在根据实际情况确定哈希桶数组的大小，并在此基础上设计好的hash算法减少Hash碰撞。那么通过什么方式来控制map使得Hash碰撞的概率又小，哈希桶数组（Node[] table）占用空间又少呢？答案就是好的Hash算法和扩容机制。

在理解Hash和扩容流程之前，我们得先了解下HashMap的几个字段。从HashMap的默认构造函数源码可知，构造函数就是对下面几个字段进行初始化，源码如下：

     int threshold;             // 所能容纳的key-value对极限       final float loadFactor;    // 负载因子      int modCount;        int size; 

首先，Node[] table的初始化长度length(默认值是16)，Load factor为负载因子(默认值是0.75)，threshold是HashMap所能容纳的最大数据量的Node(键值对)个数。threshold = length * Load factor。也就是说，在数组定义好长度之后，负载因子越大，所能容纳的键值对个数越多。

结合负载因子的定义公式可知，threshold就是在此Load factor和length(数组长度)对应下允许的最大元素数目，超过这个数目就重新resize(扩容)，扩容后的HashMap容量是之前容量的两倍。默认的负载因子0.75是对空间和时间效率的一个平衡选择，建议大家不要修改，除非在时间和空间比较特殊的情况下，如果内存空间很多而又对时间效率要求很高，可以降低负载因子Load factor的值；相反，如果内存空间紧张而对时间效率要求不高，可以增加负载因子loadFactor的值，这个值可以大于1。

size这个字段其实很好理解，就是HashMap中实际存在的键值对数量。注意和table的长度length、容纳最大键值对数量threshold的区别。而modCount字段主要用来记录HashMap内部结构发生变化的次数，主要用于迭代的快速失败。强调一点，内部结构发生变化指的是结构发生变化，例如put新键值对，但是某个key对应的value值被覆盖不属于结构变化。

在HashMap中，哈希桶数组table的长度length大小必须为2的n次方(一定是合数)，这是一种非常规的设计，常规的设计是把桶的大小设计为素数。相对来说素数导致冲突的概率要小于合数，具体证明可以参考http://blog.csdn.net/liuqiyao_01/article/details/14475159，Hashtable初始化桶大小为11，就是桶大小设计为素数的应用（Hashtable扩容后不能保证还是素数）。HashMap采用这种非常规设计，主要是为了在取模和扩容时做优化，同时为了减少冲突，HashMap定位哈希桶索引位置时，也加入了高位参与运算的过程。

这里存在一个问题，即使负载因子和Hash算法设计的再合理，也免不了会出现拉链过长的情况，一旦出现拉链过长，则会严重影响HashMap的性能。于是，在JDK1.8版本中，对数据结构做了进一步的优化，引入了红黑树。而当链表长度太长（默认超过8）时，链表就转换为红黑树，利用红黑树快速增删改查的特点提高HashMap的性能，其中会用到红黑树的插入、删除、查找等算法。本文不再对红黑树展开讨论，想了解更多红黑树数据结构的工作原理可以参考http://blog.csdn.net/v_july_v/article/details/6105630。

功能实现-方法

HashMap的内部功能实现很多，本文主要从根据key获取哈希桶数组索引位置、put方法的详细执行、扩容过程三个具有代表性的点深入展开讲解。

1. 确定哈希桶数组索引位置

不管增加、删除、查找键值对，定位到哈希桶数组的位置都是很关键的第一步。前面说过HashMap的数据结构是数组和链表的结合，所以我们当然希望这个HashMap里面的元素位置尽量分布均匀些，尽量使得每个位置上的元素数量只有一个，那么当我们用hash算法求得这个位置的时候，马上就可以知道对应位置的元素就是我们要的，不用遍历链表，大大优化了查询的效率。HashMap定位数组索引位置，直接决定了hash方法的离散性能。先看看源码的实现(方法一+方法二):

方法一： static final int hash(Object key) {   //jdk1.8 & jdk1.7      int h;      // h = key.hashCode() 为第一步 取hashCode值      // h ^ (h >>> 16)  为第二步 高位参与运算      return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); } 方法二： static int indexFor(int h, int length) {  //jdk1.7的源码，jdk1.8没有这个方法，但是实现原理一样的      return h & (length-1);  //第三步 取模运算 } 

这里的Hash算法本质上就是三步：取key的hashCode值、高位运算、取模运算。

对于任意给定的对象，只要它的hashCode()返回值相同，那么程序调用方法一所计算得到的Hash码值总是相同的。我们首先想到的就是把hash值对数组长度取模运算，这样一来，元素的分布相对来说是比较均匀的。但是，模运算的消耗还是比较大的，在HashMap中是这样做的：调用方法二来计算该对象应该保存在table数组的哪个索引处。

这个方法非常巧妙，它通过h & (table.length -1)来得到该对象的保存位，而HashMap底层数组的长度总是2的n次方，这是HashMap在速度上的优化。当length总是2的n次方时，h& (length-1)运算等价于对length取模，也就是h%length，但是&比%具有更高的效率。

在JDK1.8的实现中，优化了高位运算的算法，通过hashCode()的高16位异或低16位实现的：(h = k.hashCode()) ^ (h >>> 16)，主要是从速度、功效、质量来考虑的，这么做可以在数组table的length比较小的时候，也能保证考虑到高低Bit都参与到Hash的计算中，同时不会有太大的开销。

下面举例说明下，n为table的长度。

2. 分析HashMap的put方法

HashMap的put方法执行过程可以通过下图来理解，自己有兴趣可以去对比源码更清楚地研究学习。

①.判断键值对数组table[i]是否为空或为null，否则执行resize()进行扩容；

②.根据键值key计算hash值得到插入的数组索引i，如果table[i]==null，直接新建节点添加，转向⑥，如果table[i]不为空，转向③；

③.判断table[i]的首个元素是否和key一样，如果相同直接覆盖value，否则转向④，这里的相同指的是hashCode以及equals；

④.判断table[i] 是否为treeNode，即table[i] 是否是红黑树，如果是红黑树，则直接在树中插入键值对，否则转向⑤；

⑤.遍历table[i]，判断链表长度是否大于8，大于8的话把链表转换为红黑树，在红黑树中执行插入操作，否则进行链表的插入操作；遍历过程中若发现key已经存在直接覆盖value即可；

⑥.插入成功后，判断实际存在的键值对数量size是否超多了最大容量threshold，如果超过，进行扩容。

JDK1.8HashMap的put方法源码如下:

 1 public V put(K key, V value) {  2     // 对key的hashCode()做hash  3     return putVal(hash(key), key, value, false, true);  4 }  5   6 final V putVal(int hash, K key, V value, boolean onlyIfAbsent,  7                boolean evict) {  8     Node<K,V>[] tab; Node<K,V> p; int n, i;  9     // 步骤①：tab为空则创建 10     if ((tab = table) == null || (n = tab.length) == 0) 11         n = (tab = resize()).length; 12     // 步骤②：计算index，并对null做处理  13     if ((p = tab[i = (n - 1) & hash]) == null)  14         tab[i] = newNode(hash, key, value, null); 15     else { 16         Node<K,V> e; K k; 17         // 步骤③：节点key存在，直接覆盖value 18         if (p.hash == hash && 19             ((k = p.key) == key || (key != null && key.equals(k)))) 20             e = p; 21         // 步骤④：判断该链为红黑树 22         else if (p instanceof TreeNode) 23             e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value); 24         // 步骤⑤：该链为链表 25         else { 26             for (int binCount = 0; ; ++binCount) { 27                 if ((e = p.next) == null) { 28                     p.next = newNode(hash, key,value,null);                         //链表长度大于8转换为红黑树进行处理 29                     if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st   30                         treeifyBin(tab, hash); 31                     break; 32                 }                     // key已经存在直接覆盖value 33                 if (e.hash == hash && 34                     ((k = e.key) == key || (key != null && key.equals(k))))  35                            break; 36                 p = e; 37             } 38         } 39          40         if (e != null) { // existing mapping for key 41             V oldValue = e.value; 42             if (!onlyIfAbsent || oldValue == null) 43                 e.value = value; 44             afterNodeAccess(e); 45             return oldValue; 46         } 47     }  48     ++modCount; 49     // 步骤⑥：超过最大容量 就扩容 50     if (++size > threshold) 51         resize(); 52     afterNodeInsertion(evict); 53     return null; 54 } 

3. 扩容机制

扩容(resize)就是重新计算容量，向HashMap对象里不停的添加元素，而HashMap对象内部的数组无法装载更多的元素时，对象就需要扩大数组的长度，以便能装入更多的元素。当然Java里的数组是无法自动扩容的，方法是使用一个新的数组代替已有的容量小的数组，就像我们用一个小桶装水，如果想装更多的水，就得换大水桶。

我们分析下resize的源码，鉴于JDK1.8融入了红黑树，较复杂，为了便于理解我们仍然使用JDK1.7的代码，好理解一些，本质上区别不大，具体区别后文再说。

 1 void resize(int newCapacity) {   //传入新的容量  2     Entry[] oldTable = table;    //引用扩容前的Entry数组  3     int oldCapacity = oldTable.length;           4     if (oldCapacity == MAXIMUM_CAPACITY) {  //扩容前的数组大小如果已经达到最大(2^30)了  5         threshold = Integer.MAX_VALUE; //修改阈值为int的最大值(2^31-1)，这样以后就不会扩容了  6         return;  7     }  8    9     Entry[] newTable = new Entry[newCapacity];  //初始化一个新的Entry数组 10     transfer(newTable);                         //！！将数据转移到新的Entry数组里 11     table = newTable;                           //HashMap的table属性引用新的Entry数组 12     threshold = (int)(newCapacity * loadFactor);//修改阈值 13 } 

这里就是使用一个容量更大的数组来代替已有的容量小的数组，transfer()方法将原有Entry数组的元素拷贝到新的Entry数组里。

 1 void transfer(Entry[] newTable) {  2     Entry[] src = table;                   //src引用了旧的Entry数组  3     int newCapacity = newTable.length;  4     for (int j = 0; j < src.length; j++) { //遍历旧的Entry数组  5         Entry<K,V> e = src[j];             //取得旧Entry数组的每个元素  6         if (e != null) {  7             src[j] = null;//释放旧Entry数组的对象引用（for循环后，旧的Entry数组不再引用任何对象）  8             do {  9                 Entry<K,V> next = e.next; 10                 int i = indexFor(e.hash, newCapacity); //！！重新计算每个元素在数组中的位置 11                 e.next = newTable[i]; //标记[1] 12                 newTable[i] = e;      //将元素放在数组上 13                 e = next;             //访问下一个Entry链上的元素 14             } while (e != null); 15         } 16     } 17 } 

newTable[i]的引用赋给了e.next，也就是使用了单链表的头插入方式，同一位置上新元素总会被放在链表的头部位置；这样先放在一个索引上的元素终会被放到Entry链的尾部(如果发生了hash冲突的话），这一点和Jdk1.8有区别，下文详解。在旧数组中同一条Entry链上的元素，通过重新计算索引位置后，有可能被放到了新数组的不同位置上。

下面举个例子说明下扩容过程。假设了我们的hash算法就是简单的用key mod 一下表的大小（也就是数组的长度）。其中的哈希桶数组table的size=2， 所以key = 3、7、5，put顺序依次为 5、7、3。在mod 2以后都冲突在table[1]这里了。这里假设负载因子 loadFactor=1，即当键值对的实际大小size 大于 table的实际大小时进行扩容。接下来的三个步骤是哈希桶数组 resize成4，然后所有的Node重新rehash的过程。

下面我们讲解下JDK1.8做了哪些优化。经过观测可以发现，我们使用的是2次幂的扩展(指长度扩为原来2倍)，所以，元素的位置要么是在原位置，要么是在原位置再移动2次幂的位置。看下图可以明白这句话的意思，n为table的长度，图（a）表示扩容前的key1和key2两种key确定索引位置的示例，图（b）表示扩容后key1和key2两种key确定索引位置的示例，其中hash1是key1对应的哈希与高位运算结果。

元素在重新计算hash之后，因为n变为2倍，那么n-1的mask范围在高位多1bit(红色)，因此新的index就会发生这样的变化：

因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap”，可以看看下图为16扩充为32的resize示意图：

这个设计确实非常的巧妙，既省去了重新计算hash值的时间，而且同时，由于新增的1bit是0还是1可以认为是随机的，因此resize的过程，均匀的把之前的冲突的节点分散到新的bucket了。这一块就是JDK1.8新增的优化点。有一点注意区别，JDK1.7中rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，但是从上图可以看出，JDK1.8不会倒置。有兴趣的同学可以研究下JDK1.8的resize源码，写的很赞，如下:

 1 final Node<K,V>[] resize() {  2     Node<K,V>[] oldTab = table;  3     int oldCap = (oldTab == null) ? 0 : oldTab.length;  4     int oldThr = threshold;  5     int newCap, newThr = 0;  6     if (oldCap > 0) {  7         // 超过最大值就不再扩充了，就只好随你碰撞去吧  8         if (oldCap >= MAXIMUM_CAPACITY) {  9             threshold = Integer.MAX_VALUE; 10             return oldTab; 11         } 12         // 没超过最大值，就扩充为原来的2倍 13         else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY && 14                  oldCap >= DEFAULT_INITIAL_CAPACITY) 15             newThr = oldThr << 1; // double threshold 16     } 17     else if (oldThr > 0) // initial capacity was placed in threshold 18         newCap = oldThr; 19     else {               // zero initial threshold signifies using defaults 20         newCap = DEFAULT_INITIAL_CAPACITY; 21         newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY); 22     } 23     // 计算新的resize上限 24     if (newThr == 0) { 25  26         float ft = (float)newCap * loadFactor; 27         newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ? 28                   (int)ft : Integer.MAX_VALUE); 29     } 30     threshold = newThr; 31     @SuppressWarnings({"rawtypes"，"unchecked"}) 32         Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap]; 33     table = newTab; 34     if (oldTab != null) { 35         // 把每个bucket都移动到新的buckets中 36         for (int j = 0; j < oldCap; ++j) { 37             Node<K,V> e; 38             if ((e = oldTab[j]) != null) { 39                 oldTab[j] = null; 40                 if (e.next == null) 41                     newTab[e.hash & (newCap - 1)] = e; 42                 else if (e instanceof TreeNode) 43                     ((TreeNode<K,V>)e).split(this, newTab, j, oldCap); 44                 else { // 链表优化重hash的代码块 45                     Node<K,V> loHead = null, loTail = null; 46                     Node<K,V> hiHead = null, hiTail = null; 47                     Node<K,V> next; 48                     do { 49                         next = e.next; 50                         // 原索引 51                         if ((e.hash & oldCap) == 0) { 52                             if (loTail == null) 53                                 loHead = e; 54                             else 55                                 loTail.next = e; 56                             loTail = e; 57                         } 58                         // 原索引+oldCap 59                         else { 60                             if (hiTail == null) 61                                 hiHead = e; 62                             else 63                                 hiTail.next = e; 64                             hiTail = e; 65                         } 66                     } while ((e = next) != null); 67                     // 原索引放到bucket里 68                     if (loTail != null) { 69                         loTail.next = null; 70                         newTab[j] = loHead; 71                     } 72                     // 原索引+oldCap放到bucket里 73                     if (hiTail != null) { 74                         hiTail.next = null; 75                         newTab[j + oldCap] = hiHead; 76                     } 77                 } 78             } 79         } 80     } 81     return newTab; 82 } 

线程安全性

在多线程使用场景中，应该尽量避免使用线程不安全的HashMap，而使用线程安全的ConcurrentHashMap。那么为什么说HashMap是线程不安全的，下面举例子说明在并发的多线程使用场景中使用HashMap可能造成死循环。代码例子如下(便于理解，仍然使用JDK1.7的环境)：

public class HashMapInfiniteLoop {        private static HashMap<Integer,String> map = new HashMap<Integer,String>(2，0.75f);       public static void main(String[] args) {           map.put(5， "C");            new Thread("Thread1") {               public void run() {                   map.put(7, "B");                   System.out.println(map);               };           }.start();           new Thread("Thread2") {               public void run() {                   map.put(3, "A);                   System.out.println(map);               };           }.start();             }   } 

其中，map初始化为一个长度为2的数组，loadFactor=0.75，threshold=2*0.75=1，也就是说当put第二个key的时候，map就需要进行resize。

通过设置断点让线程1和线程2同时debug到transfer方法(3.3小节代码块)的首行。注意此时两个线程已经成功添加数据。放开thread1的断点至transfer方法的“Entry next = e.next;” 这一行；然后放开线程2的的断点，让线程2进行resize。结果如下图。

注意，Thread1的 e 指向了key(3)，而next指向了key(7)，其在线程二rehash后，指向了线程二重组后的链表。

线程一被调度回来执行，先是执行 newTalbe[i] = e， 然后是e = next，导致了e指向了key(7)，而下一次循环的next = e.next导致了next指向了key(3)。

e.next = newTable[i] 导致 key(3).next 指向了 key(7)。注意：此时的key(7).next 已经指向了key(3)， 环形链表就这样出现了。

于是，当我们用线程一调用map.get(11)时，悲剧就出现了——Infinite Loop。

JDK1.8与JDK1.7的性能对比

HashMap中，如果key经过hash算法得出的数组索引位置全部不相同，即Hash算法非常好，那样的话，getKey方法的时间复杂度就是O(1)，如果Hash算法技术的结果碰撞非常多，假如Hash算极其差，所有的Hash算法结果得出的索引位置一样，那样所有的键值对都集中到一个桶中，或者在一个链表中，或者在一个红黑树中，时间复杂度分别为O(n)和O(lgn)。 鉴于JDK1.8做了多方面的优化，总体性能优于JDK1.7，下面我们从两个方面用例子证明这一点。

Hash较均匀的情况

为了便于测试，我们先写一个类Key，如下：

class Key implements Comparable<Key> {      private final int value;      Key(int value) {         this.value = value;     }      @Override     public int compareTo(Key o) {         return Integer.compare(this.value, o.value);     }      @Override     public boolean equals(Object o) {         if (this == o) return true;         if (o == null || getClass() != o.getClass())             return false;         Key key = (Key) o;         return value == key.value;     }      @Override     public int hashCode() {         return value;     } } 

这个类复写了equals方法，并且提供了相当好的hashCode函数，任何一个值的hashCode都不会相同，因为直接使用value当做hashcode。为了避免频繁的GC，我将不变的Key实例缓存了起来，而不是一遍一遍的创建它们。代码如下：

public class Keys {      public static final int MAX_KEY = 10_000_000;     private static final Key[] KEYS_CACHE = new Key[MAX_KEY];      static {         for (int i = 0; i < MAX_KEY; ++i) {             KEYS_CACHE[i] = new Key(i);         }     }      public static Key of(int value) {         return KEYS_CACHE[value];     } } 

现在开始我们的试验，测试需要做的仅仅是，创建不同size的HashMap（1、10、100、......10000000），屏蔽了扩容的情况，代码如下：

   static void test(int mapSize) {          HashMap<Key, Integer> map = new HashMap<Key,Integer>(mapSize);         for (int i = 0; i < mapSize; ++i) {             map.put(Keys.of(i), i);         }          long beginTime = System.nanoTime(); //获取纳秒         for (int i = 0; i < mapSize; i++) {             map.get(Keys.of(i));         }         long endTime = System.nanoTime();         System.out.println(endTime - beginTime);     }      public static void main(String[] args) {         for(int i=10;i<= 1000 0000;i*= 10){             test(i);         }     } 

在测试中会查找不同的值，然后度量花费的时间，为了计算getKey的平均时间，我们遍历所有的get方法，计算总的时间，除以key的数量，计算一个平均值，主要用来比较，绝对值可能会受很多环境因素的影响。结果如下：

通过观测测试结果可知，JDK1.8的性能要高于JDK1.7 15%以上，在某些size的区域上，甚至高于100%。由于Hash算法较均匀，JDK1.8引入的红黑树效果不明显，下面我们看看Hash不均匀的的情况。

Hash极不均匀的情况

假设我们又一个非常差的Key，它们所有的实例都返回相同的hashCode值。这是使用HashMap最坏的情况。代码修改如下：

class Key implements Comparable<Key> {      //...      @Override     public int hashCode() {         return 1;     } } 

仍然执行main方法，得出的结果如下表所示：

从表中结果中可知，随着size的变大，JDK1.7的花费时间是增长的趋势，而JDK1.8是明显的降低趋势，并且呈现对数增长稳定。当一个链表太长的时候，HashMap会动态的将它替换成一个红黑树，这话的话会将时间复杂度从O(n)降为O(logn)。hash算法均匀和不均匀所花费的时间明显也不相同，这两种情况的相对比较，可以说明一个好的hash算法的重要性。

小结

(1) 扩容是一个特别耗性能的操作，所以当程序员在使用HashMap的时候，估算map的大小，初始化的时候给一个大致的数值，避免map进行频繁的扩容。

(2) 负载因子是可以修改的，也可以大于1，但是建议不要轻易修改，除非情况非常特殊。

(3) HashMap是线程不安全的，不要在并发的环境中同时操作HashMap，建议使用ConcurrentHashMap。

(4) JDK1.8引入红黑树大程度优化了HashMap的性能。

(5) 还没升级JDK1.8的，现在开始升级吧。HashMap的性能提升仅仅是JDK1.8的冰山一角。

参考

1. JDK1.7&JDK1.8 源码。
2. CSDN博客频道，HashMap多线程死循环问题，2014。
3. 红黑联盟，Java类集框架之HashMap(JDK1.8)源码剖析，2015。
4. CSDN博客频道， 教你初步了解红黑树，2010。
5. Java Code Geeks，HashMap performance improvements in Java 8，2014。
6. Importnew，危险！在HashMap中将可变对象用作Key，2014。
7. CSDN博客频道，为什么一般hashtable的桶数会取一个素数，2013。

背景：除去大名鼎鼎的QQ这款即时聊天工具，还有许多细分行业的IM，比如淘宝阿里旺旺、网易泡泡、YY语音......。恰巧公司产品也要开发一款基于我 们自己行业的类IM系统，很有幸我担当了这个产品的架构师，核心代码编写、实现者。下面把我近年来从技术上我对IM系统（即时消息的传输，不包括语音，视频，文件的传输）的理解和设计分享出来，浅薄之见，望大家别见笑，欢迎给出批评意见。

一.网络传输协议的选择

目前我知晓的所有IM系统传输即时消息无外乎使用UDP、TCP、基于TCP的http这几种协议中的一种或几种。比如QQ主要采用UDP协议，MSN主要采用TCP协议，而且他们也都支持HTTP协议的代理模式。更多资料，请参加这篇文章《一些常用软件的网络端口协议分类介绍》。

我们该如何选择呢？

• UDP协议实时性更好，但是如何处理安全可靠的传输并且处理不同客户端之间的消息交互是个难题，实现起来过于复杂；

• HTTP协议属于扩展支持，我们在产品的初始阶段可以不用支持；

• 那就非TCP协议莫属了，要考虑的同样也有很多，特别是如果有海量用户的需求。如何保证单机服务器高并发量，如何做到灵活，扩展的架构。

Tips: QQ 为什么采用 UDP 协议，而不采用 TCP 协议实现？

二.应该选择什么格式的数据协议

二进制格式？文本格式？这个话题转到我的这篇文章《网络传输数据格式的选择》，从我们当前的需求和产品周期上我觉得选择JSON形式的数据协议是最好的。

三.架构设计

首先我们来提炼一下一个IM系统的主要需求，包括账号，关系链，在线状态显示，消息交互......。

架构考量：

• 由于采用可靠传输协议TCP，考虑到负载问题（短连接实现账号、关系链相关业务，长连接实现上线、信息推送）；

• 后台架构的灵活性、可扩展性，支持分布式部署——把网络层、业务逻辑层、数据层分离，网络层和业务层支持负载均衡策略、数据层支持分布式存储；

• 客户端SDK的易用性：把网络层、数据层分离、业务逻辑层分离；

后台架构简化图

架构示意图

架构细化图

说明

• 从< 架构细化图>中可以看出对于上线服务由于建立的是TCP长连接，对于单台服务器往往由于硬件资源、系统资源、网络资源的限制无法做到海量用户的同时 在线，所以设计为根据服务器负载支持多服务器上线，同时由于多服务器上线造成了对整个系统交互（不同的客户端的交互，协作部门应用服务和客户的交互）的分 割，引入消息转发服务器作为粘合点。另外对于多服务器上线造成的统一账户信息（在线状态，消息）数据的分割，引入统一的数据层（内存存储 层：session、状态信息存储、消息队列存储；数据库：账号信息存储）做到业务和数据的分离，也就做到了支持分布式部署。参见我的这篇文章《构建高性能服务的考量》

• 对于部分业务服务：做到网络层、业务层、数据层的完全分离。首先对于TCP短连接来说不会如长连接那般消耗资源，即使后期遇到海量的并发访问请求依然可以从容的通过负载均衡策略和数据分布式部署策略进行解决。参见我的这篇文章《服务端架构中的“网关服务器”》

服务端平台及技术选型

• 系统开发平台： CentOS——Linux发行版的一种，稳定可靠、可定制优化、支持丰富；

• 网络支撑层： libevent——减小开发成本，增强稳定性；

• 缓存存储层： Redis——支持丰富的存储结构，支持分布式存储；

• 数据库： MySQL——最适合互联网的数据库，免授权、高效稳定、可控性高；

• 开发语言： C/C++；

部分热点问题考量

• 系统性能考量：

  • 编码角度：采用高效的网络模型，线程模型，I/O处理模型，合理的数据库设计和操作语句的优化；

  • 垂直扩展：通过提高单服务器的硬件资源或者网络资源来提高性能；

  • 水平扩展：通过合理的架构设计和运维方面的负载均衡策略将负载分担，有效提高性能；后期甚至可以考虑加入数据缓存层，突破IO瓶颈；

• 系统的高可用性：（防止单点故障）

  • 在架构设计时做到业务处理和数据的分离，从而依赖分布式的部署使得在单点故障时能保证系统可用。

  • 对于关键独立节点可以采用双机热备技术进行切换。

  • 数据库数据的安全性可以通过磁盘阵列的冗余配置和主备数据库来解决。

主要学习资料： 请自行google。

• 《1.4亿在线背后的故事》；

• 《BasicDB的架构演变》；

• 《微信之道－至简》；

本文出自51博客 “永远的朋友” ，转载请务必保留此出处http://yaocoder.blog.51cto.com/2668309/1412029

来自： http://tonybai.com/2016/02/26/deploy-a-private-docker-registry/

安装部署一个私有的Docker Registry是引入、学习和使用 Docker 这门技术的必经之路之一。尤其是当Docker被所在组织接受，更多人、项目和产品开始接触和使用Docker时，存储和分发自制的Docker image便成了刚需。Docker Registry一如既往的继承了“Docker坑多”的特点，为此这里将自己搭建”各类”Registry过程中执行的步骤、遇到的问题记录下来，为己备忘，为他参考。

Docker在2015年推出了 distribution 项目，即Docker Registry 2。相比于 old registry ，Registry 2使用Go实现，在安全性、性能方面均有大幅改进。Registry设计了全新的Rest API，并且在image存储格式等方面不再兼容于old Registry。去年8月份，docker官方hub使用Registriy 2.1替代了原先的old Registry。如果你要与Registry2交互，你的Docker版本至少要是Docker 1.6。

Docker的开发者也一直在致力于改善Registry安装和使用的体验，通过提供 官方Registry Image以及 Docker Compose工具 等来简化Registry的配置。不过在本文中，我们只是利用Docker以及Registry的官方Image来部署Registry，这样更便于全面了解Registry的部署配置细节。

Registry2在镜像存储方面不仅支持本地盘，还支持诸多主流第三方存储方案。通过分布式存储系统你还可以实现一个分布式Docker Registry服务。这里仅以本地盘以及single node registry2为例。

一、环境

这里还是复用以往文章中的Docker环境：

Docker Registry Server: 10.10.105.71 Ubuntu 14.04 3.16.0-57-generic；docker 1.9.1

其他两个工作Server：
10.10.105.72 Ubuntu 14.04 3.19.0-25-generic; docker 1.9.1
10.10.126.101 Ubuntu 12.04 3.16.7-013607-generic; docker 1.9.1

本次Registry使用当前最新stable版本:Registry 2.3.0。由于镜像采用本地磁盘存储，root分区较小，需要映射使用其他volume。

二、初次搭建

本以为Docker Registry的搭建是何其简单的，甚至简单到通过一行命令就可以完成的。比如我们在Registry Server上执行：

在~/dockerregistry下，执行：

$sudo docker run -d -p 5000:5000 -v `pwd`/data:/var/lib/registry --restart=always --name registry registry:2
Unable to find image 'registry:2' locally
2: Pulling from library/registry
f32095d4ba8a: Pull complete
9b607719a62a: Pull complete
973de4038269: Pull complete
2867140211c1: Pull complete
8da16446f5ca: Pull complete
fd8c38b8b68d: Pull complete
136640b01f02: Pull complete
e039ba1c0008: Pull complete
c457c689c328: Pull complete
Digest: sha256:339d702cf9a4b0aa665269cc36255ee7ce424412d56bee9ad8a247afe8c49ef1
Status: Downloaded newer image for registry:2
e9088ef901cb00546c59f89defa4625230f4b36b0a44b3713f38ab3d2a5a2b44

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
registry            2                   c457c689c328        9 days ago          165.7 MB

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                    NAMES
e9088ef901cb        registry:2          "/bin/registry /etc/d"   About a minute ago   Up About a minute   0.0.0.0:5000->5000/tcp   registry

Registry container已经跑起来了，其启动日志可以通过：docker logs registry查看。

我们在71本地给busybox:latest打一个tag，并尝试将新tag下的image push到Registry中去：

$ docker tag busybox:latest 10.10.105.71:5000/tonybai/busybox:latest
$ docker images
REPOSITORY                          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
registry                            2                   c457c689c328        9 days ago          165.7 MB
busybox                             latest              65e4158d9625        9 days ago          1.114 MB
10.10.105.71:5000/tonybai/busybox   latest              65e4158d9625        9 days ago          1.114 MB
... ...

push到Registry中：

$ docker push 10.10.105.71:5000/tonybai/busybox
The push refers to a repository [10.10.105.71:5000/tonybai/busybox] (len: 1)
unable to ping registry endpoint https://10.10.105.71:5000/v0/
v2 ping attempt failed with error: Get https://10.10.105.71:5000/v2/: Tunnel or SSL Forbidden
 v1 ping attempt failed with error: Get https://10.10.105.71:5000/v1/_ping: Tunnel or SSL Forbidden

出错了！简单分析了一下，可能是71上docker daemon配置中加了http代理的缘故，导致无法ping通registry endpoint。于是在/etc/default/docker中注释掉export http_proxy=”xxx”的设置，并重启docker daemon。

再次尝试push：

$ docker push 10.10.105.71:5000/tonybai/busybox
The push refers to a repository [10.10.105.71:5000/tonybai/busybox] (len: 1)
unable to ping registry endpoint https://10.10.105.71:5000/v0/
v2 ping attempt failed with error: Get https://10.10.105.71:5000/v2/: tls: oversized record received with length 20527
 v1 ping attempt failed with error: Get https://10.10.105.71:5000/v1/_ping: tls: oversized record received with length 20527

虽然还是失败，但错误信息已有所不同了。这次看来连接是可以建立的，但client端通过https访问server端，似乎想tls通信，但这一过程并未完成。

在其他机器上尝试push image到registry也遇到了同样的错误输出，如下：

10.10.105.72:

$ docker push 10.10.105.71:5000/tonybai/ubuntu
The push refers to a repository [10.10.105.71:5000/tonybai/ubuntu] (len: 1)
unable to ping registry endpoint https://10.10.105.71:5000/v0/
v2 ping attempt failed with error: Get https://10.10.105.71:5000/v2/: tls: oversized record received with length 20527
 v1 ping attempt failed with error: Get https://10.10.105.71:5000/v1/_ping: tls: oversized record received with length 20527

从错误信息来看，client与Registry交互，默认将采用https访问，但我们在install Registry时并未配置指定任何tls相关的key和crt文件，https访问定然失败。要想弄清这个问题，只能查看 Registry Manual 。

三、Insecure Registry

Registry的文档还是相对详尽的。在文档中，我们找到了 Insecure Registry ，即接收plain http访问的Registry的配置和使用方法，虽然这不是官方推荐的。

实际上对于我们内部网络而言，Insecure Registry基本能满足需求，部署过程也避免了secure registry的那些繁琐步骤，比如制作和部署证书等。

为了搭建一个Insecure Registry，我们需要先清理一下上面已经启动的Registry容器。

$ docker stop registry
registry
$ docker rm registry
registry

修改Registry server上的Docker daemon的配置，为DOCKER_OPTS增加–insecure-registry：

DOCKER_OPTS="--insecure-registry 10.10.105.71:5000 ....

重启Docker Daemon，启动Registry容器：

$ sudo service docker restart
docker stop/waiting
docker start/running, process 6712
$ sudo docker run -d -p 5000:5000 -v `pwd`/data:/var/lib/registry --restart=always --name registry registry:2
5966e92fce9c34705050e19368d19574e021a272ede1575385ef35ecf5cea019

尝试再次Push image:

$ docker push 10.10.105.71:5000/tonybai/busybox
The push refers to a repository [10.10.105.71:5000/tonybai/busybox] (len: 1)
65e4158d9625: Pushed
5506dda26018: Pushed
latest: digest: sha256:800f2d4558acd67f52262fbe170c9fc2e67efaa6f230a74b41b555e6fcca2892 size: 2739

这回push ok！

我们将本地的tag做untag处理，再从Registry pull相关image：

$ docker images
REPOSITORY                          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
registry                            2                   c457c689c328        9 days ago          165.7 MB
10.10.105.71:5000/tonybai/busybox   latest              65e4158d9625        9 days ago          1.114 MB
busybox                             latest              65e4158d9625        9 days ago          1.114 MB
ubuntu                              14.04               6cc0fc2a5ee3        5 weeks ago         187.9 MB

$ docker rmi 10.10.105.71:5000/tonybai/busybox
Untagged: 10.10.105.71:5000/tonybai/busybox:latest

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
registry            2                   c457c689c328        9 days ago          165.7 MB
busybox             latest              65e4158d9625        9 days ago          1.114 MB
ubuntu              14.04               6cc0fc2a5ee3        5 weeks ago         187.9 MB

$ docker pull 10.10.105.71:5000/tonybai/busybox
Using default tag: latest
latest: Pulling from tonybai/busybox
Digest: sha256:800f2d4558acd67f52262fbe170c9fc2e67efaa6f230a74b41b555e6fcca2892
Status: Downloaded newer image for 10.10.105.71:5000/tonybai/busybox:latest

$ docker images
REPOSITORY                          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
registry                            2                   c457c689c328        9 days ago          165.7 MB
10.10.105.71:5000/tonybai/busybox   latest              65e4158d9625        9 days ago          1.114 MB
busybox                             latest              65e4158d9625        9 days ago          1.114 MB
ubuntu                              14.04               6cc0fc2a5ee3        5 weeks ago         187.9 MB

可以看到：Pull过程也很顺利。

在Private Registry2中查看或检索Repository或images， 将不能用docker search ：

$ docker search 10.10.105.71:5000/tonybai/busybox/
Error response from daemon: Unexpected status code 404

但通过v2版本的API，我们可以实现相同目的：

$curl  http://10.10.105.71:5000/v2/_catalog
{"repositories":["tonybai/busybox"]}

$ curl  http://10.10.105.71:5000/v2/tonybai/busybox/tags/list
{"name":"tonybai/busybox","tags":["latest"]}

在其他主机上，我们尝试pull busybox：

10.10.105.72:

$docker pull 10.10.105.71:5000/tonybai/busybox
Using default tag: latest
Error response from daemon: unable to ping registry endpoint https://10.10.105.71:5000/v0/
v2 ping attempt failed with error: Get https://10.10.105.71:5000/v2/: tls: oversized record received with length 20527
 v1 ping attempt failed with error: Get https://10.10.105.71:5000/v1/_ping: tls: oversized record received with length 20527

我们发现依旧不能pull和push！在Registry手册中讲到，如果采用insecure registry的模式，那么所有与Registry交互的主机上的Docker Daemon都要配置：–insecure-registry选项。

我们按照上面的配置方法，修改105.72上的/etc/default/docker，重启Docker daemon，再执行pull/push就会得到正确的结果：

$ sudo vi /etc/default/docker
$ sudo service docker restart
docker stop/waiting
docker start/running, process 10614
$ docker pull 10.10.105.71:5000/tonybai/busybox
Using default tag: latest
latest: Pulling from tonybai/busybox
5506dda26018: Pull complete
65e4158d9625: Pull complete
Digest: sha256:800f2d4558acd67f52262fbe170c9fc2e67efaa6f230a74b41b555e6fcca2892
Status: Downloaded newer image for 10.10.105.71:5000/tonybai/busybox:latest

$ docker images
REPOSITORY                          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
ubuntu                              14.04               36248ae4a9ac        8 days ago          187.9 MB
10.10.105.71:5000/tonybai/ubuntu    14.04               36248ae4a9ac        8 days ago          187.9 MB
10.10.105.71:5000/tonybai/busybox   latest              65e4158d9625        9 days ago          1.114 MB

$ docker push 10.10.105.71:5000/tonybai/ubuntu
The push refers to a repository [10.10.105.71:5000/tonybai/ubuntu] (len: 1)
36248ae4a9ac: Pushed
8ea5373bf5a6: Pushed
2e0188208e83: Pushed
e3c70beaa378: Pushed
14.04: digest: sha256:72e56686cb9fb38438f0fd68fecf02ef592ce2ef7069bbf97802d959d568c5cc size: 6781

四、Secure Registry

Docker官方是推荐你采用Secure Registry的工作模式的，即transport采用tls。这样我们就需要为Registry配置tls所需的key和crt文件了。

我们首先清理一下环境，将上面的Insecure Registry停掉并rm掉；将各台主机上Docker Daemon的DOCKER_OPTS配置中的–insecure-registry去掉，并重启Docker Daemon。

如果你拥有一个域名，域名下主机提供Registry服务，并且你拥有某知名CA签署的证书文件，那么你可以建立起一个Secure Registry。不过我这里没有现成的证书，只能使用自签署的证书。严格来讲，使用自签署的证书在Docker官方眼中依旧属于Insecure，不过这里只是借助自签署的证书来说明一下Secure Registry的部署步骤罢了。

1、制作自签署证书

如果你有知名CA签署的证书，那么这步可直接忽略。

$ openssl req -newkey rsa:2048 -nodes -sha256 -keyout certs/domain.key -x509 -days 365 -out certs/domain.crt
Generating a 2048 bit RSA private key
..............+++
............................................+++
writing new private key to 'certs/domain.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:Liaoning
Locality Name (eg, city) []:shenyang
Organization Name (eg, company) [Internet Widgits Pty Ltd]:foo
Organizational Unit Name (eg, section) []:bar
Common Name (e.g. server FQDN or YOUR name) []:mydockerhub.com
Email Address []:bigwhite.cn@gmail.com

2、启动Secure Registry

启动带证书的Registry：

$ docker run -d -p 5000:5000 --restart=always --name registry \
  -v `pwd`/data:/var/lib/registry \
  -v `pwd`/certs:/certs \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
  -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
  registry:2
35e8ce77dd455f2bd50854e4581cd52be8a137f4aaea717239b6d676c5ea5777

由于证书的CN是mydockerhub.com，我们需要修改一下/etc/hosts文件:

10.10.105.71 mydockerhub.com

重新为busybox制作一个tag:

$docker tag busybox:latest mydockerhub.com:5000/tonybai/busybox:latest

Push到Registry:

$ docker push mydockerhub.com:5000/tonybai/busybox
The push refers to a repository [mydockerhub.com:5000/tonybai/busybox] (len: 1)
unable to ping registry endpoint https://mydockerhub.com:5000/v0/
v2 ping attempt failed with error: Get https://mydockerhub.com:5000/v2/: x509: certificate signed by unknown authority
 v1 ping attempt failed with error: Get https://mydockerhub.com:5000/v1/_ping: x509: certificate signed by unknown authority

push失败了！从错误日志来看，docker client认为server传输过来的证书的签署方是一个unknown authority（未知的CA），因此验证失败。我们需要让docker client安装我们的CA证书：

$ sudo mkdir -p /etc/docker/certs.d/mydockerhub.com:5000
$ sudo cp certs/domain.crt /etc/docker/certs.d/mydockerhub.com:5000/ca.crt
$ sudo service docker restart //安装证书后，重启Docker Daemon

再执行Push，我们看到了成功的输出日志。由于data目录下之前已经被push了tonybai/busybox repository，因此提示“已存在”：

$docker push mydockerhub.com:5000/tonybai/busybox
The push refers to a repository [mydockerhub.com:5000/tonybai/busybox] (len: 1)
65e4158d9625: Image already exists
5506dda26018: Image already exists
latest: digest: sha256:800f2d4558acd67f52262fbe170c9fc2e67efaa6f230a74b41b555e6fcca2892 size: 2739

3、外部访问Registry

我们换其他机器试试访问这个secure registry。根据之前的要求，我们照猫画虎的修改一下hosts文件，安装ca.cert，去除–insecure-registry选项，并重启Docker daemon。之后尝试从registry pull image：

$ docker pull mydockerhub.com:5000/tonybai/busybox
Using default tag: latest
latest: Pulling from tonybai/busybox

Digest: sha256:800f2d4558acd67f52262fbe170c9fc2e67efaa6f230a74b41b555e6fcca2892
Status: Downloaded newer image for mydockerhub.com:5000/tonybai/busybox:latest

$ docker images
REPOSITORY                             TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
10.10.105.71:5000/tonybai/ubuntu       14.04               36248ae4a9ac        9 days ago          187.9 MB
ubuntu                                 14.04               36248ae4a9ac        9 days ago          187.9 MB
10.10.105.71:5000/tonybai/busybox      latest              65e4158d9625        9 days ago          1.114 MB
mydockerhub.com:5000/tonybai/busybox   latest              65e4158d9625        9 days ago          1.114 MB

这样来看，如果使用自签署的证书，那么所有要与Registry交互的Docker主机都需要安装mydockerhub.com的ca.crt(domain.crt)。但如果你使用知名CA，这一步也就可以忽略。

五、Registry的鉴权管理

Registry提供了一种基础的鉴权方式。我们通过下面步骤即可为Registry加上基础鉴权：

在Register server上，为Registry增加foo用户，密码foo123：（之前需要停掉已有的Registry，并删除之）

//生成鉴权密码文件
$ mkdir auth
$ docker run --entrypoint htpasswd registry:2 -Bbn foo foo123  > auth/htpasswd
$ ls auth
htpasswd

//启动带鉴权功能的Registry：
$ docker run -d -p 5000:5000 --restart=always --name registry \
   -v `pwd`/auth:/auth \
   -e "REGISTRY_AUTH=htpasswd" \
   -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
   -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
   -v `pwd`/data:/var/lib/registry \
   -v `pwd`/certs:/certs \
   -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
   -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
   registry:2
199ad0b3591fb9613b21b1c96f017267f3c39661a7025d30df636c6805e7ab50

在105.72上，我们尝试push image到Registry：

$ docker push mydockerhub.com:5000/tonybai/busybox
The push refers to a repository [mydockerhub.com:5000/tonybai/busybox] (len: 1)
65e4158d9625: Image push failed
Head https://mydockerhub.com:5000/v2/tonybai/busybox/blobs/sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4: no basic auth credentials

错误信息提示：鉴权失败。

在72上执行docker login:

$docker login mydockerhub.com:5000
Username: foo
Password:
Email: bigwhite.cn@gmail.com
WARNING: login credentials saved in /home/baiming/.docker/config.json
Login Succeeded

login成功后，再行Push：

$ docker push mydockerhub.com:5000/tonybai/busybox
The push refers to a repository [mydockerhub.com:5000/tonybai/busybox] (len: 1)
65e4158d9625: Image already exists
5506dda26018: Image already exists
latest: digest: sha256:800f2d4558acd67f52262fbe170c9fc2e67efaa6f230a74b41b555e6fcca2892 size: 2739

Push ok！

六、Registry中images的管理

前面提到过，通过V2版Rest API可以查询Repository和images：

$ curl --cacert domain.crt  --basic --user foo:foo123 https://mydockerhub.com:5000/v2/_catalog
{"repositories":["tonybai/busybox","tonybai/ubuntu"]}

但如果要删除Registry中的Repository或某个tag的Image，目前v2还不支持，原因见 Registry的roadmap中的说明 。

不过如果你的Registry的存储引擎使用的是本地盘，倒是有一些第三方脚本可供使用，比如：delete-docker-registry-image 。

七、小结

Registry2发布不到1年，目前还有许多问题待解决，就比如delete image的问题，相信在2.4以及后续版本这些问题会被逐个解决掉或能找到一个相对理想的方案。

. 前言

上一节我们阐述了Kubernetes的系统架构，让大家对Kubernetes有一定的初步了解，但是就如何使用Kubernetes， 也许大家还不知如何下手。本文作者将带领大家如何在本地部署、配置Kubernetes集群网络环境以及通过实例演示跨机器服务间的通信，主要包括如下内容：

• 部署环境介绍
• Kubernetes集群逻辑架构
• 部署Open vSwitch、Kubernetes、Etcd组件
• 演示Kubernetes管理容器

2. 部署环境

• VMware Workstation：10.0.3
• VMware Workstation网络模式：NAT
• 操作系统信息：CentOS 7 64位
• Open vSwitch版本信息：2.3.0
• Kubernetes版本信息：0.5.2
• Etcd版本信息：0.4.6
• Docker版本信息：1.3.1

• 服务器信息:

          | Role      | Hostname   | IP Address  | 	|:---------:|:----------:|:----------: | 	|APIServer  |kubernetes  |192.168.230.3| 	|Minion     | minion1    |192.168.230.4| 	|Minion     | minion2    |192.168.230.5|

3. Kubernetes集群逻辑架构

在详细介绍部署Kubernetes集群前，先给大家展示下集群的逻辑架构。从下图可知，整个系统分为两部分，第一部分是Kubernetes APIServer，是整个系统的核心，承担集群中所有容器的管理工作；第二部分是minion，运行Container Daemon，是所有容器栖息之地，同时在minion上运行Open vSwitch程序，通过GRE Tunnel负责minion之间Pod的网络通信工作。

4. 部署Open vSwitch、Kubernetes、Etcd组件

4.1 安装Open vSwitch及配置GRE

为了解决跨minion之间Pod的通信问题，我们在每个minion上安装Open vSwtich，并使用GRE或者VxLAN使得跨机器之间Pod能相互通信，本文使用GRE，而VxLAN通常用在需要隔离的大规模网络中。对于Open vSwitch的具体安装步骤，可参考这篇博客，我们在这里就不再详细介绍安装步骤了。安装完Open vSwitch后，接下来便建立minion1和minion2之间的隧道。首先在minion1和minion2上建立OVS Bridge,

[root@minion1 ~]# ovs-vsctl add-br obr0 

接下来建立gre，并将新建的gre0添加到obr0，在minion1上执行如下命令，

[root@minion1 ~]# ovs-vsctl add-port obr0 gre0 -- set Interface gre0 type=gre options:remote_ip=192.168.230.5 

在minion2上执行,

[root@minion2 ~]# ovs-vsctl add-port obr0 gre0 -- set Interface gre0 type=gre options:remote_ip=192.168.230.4 

至此，minion1和minion2之间的隧道已经建立。然后我们在minion1和minion2上创建Linux网桥kbr0替代Docker默认的docker0（我们假设minion1和minion2都已安装Docker），设置minion1的kbr0的地址为172.17.1.1/24， minion2的kbr0的地址为172.17.2.1/24，并添加obr0为kbr0的接口，以下命令在minion1和minion2上执行。

[root@minion1 ~]# brctl addbr kbr0               //创建linux bridge [root@minion1 ~]# brctl addif kbr0 obr0          //添加obr0为kbr0的接口 [root@minion1 ~]# ip link set dev docker0 down   //设置docker0为down状态 [root@minion1 ~]# ip link del dev docker0        //删除docker0 

为了使新建的kbr0在每次系统重启后任然有效，我们在/etc/sysconfig/network-scripts/目录下新建minion1的ifcfg-kbr0如下：

DEVICE=kbr0 ONBOOT=yes BOOTPROTO=static IPADDR=172.17.1.1 NETMASK=255.255.255.0 GATEWAY=172.17.1.0 USERCTL=no TYPE=Bridge IPV6INIT=no 

同样在minion2上新建ifcfg-kbr0，只需修改ipaddr为172.17.2.1和gateway为172.17.2.0即可，然后执行systemctl restart network重启系统网络服务，你能在minion1和minion2上发现kbr0都设置了相应的IP地址。为了验证我们创建的隧道是否能通信，我们在minion1和minion2上相互ping对方kbr0的IP地址，从下面的结果发现是不通的，经查找这是因为在minion1和minion2上缺少访问172.17.1.1和172.17.2.1的路由，因此我们需要添加路由保证彼此之间能通信。

[root@minion1 network-scripts]# ping 172.17.2.1 PING 172.17.2.1 (172.17.2.1) 56(84) bytes of data. ^C --- 172.17.2.1 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1000ms  [root@minion2 ~]#  ping 172.17.1.1 PING 172.17.1.1 (172.17.1.1) 56(84) bytes of data. ^C --- 172.17.1.1 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1000ms 

由于通过ip route add添加的路由会在下次系统重启后失效，为此我们在/etc/sysconfig/network-scripts目录下新建一个文件route-eth0存储路由，这里需要注意的是route-eth0和ifcfg-eth0的黑体部分必须保持一致，否则不能工作，这样添加的路由在下次重启后不会失效。为了保证两台minion的kbr0能相互通信，我们在minion1的route-eth0里添加路由172.17.2.0/24 via 192.168.230.5 dev eno16777736，eno16777736是minion1的网卡，同样在minion2的route-eth0里添加路由172.17.1.0/24 via 192.168.230.4 dev eno16777736。重启网络服务后再次验证，彼此kbr0的地址可以ping通，如：

[root@minion2 network-scripts]# ping 172.17.1.1 PING 172.17.1.1 (172.17.1.1) 56(84) bytes of data. 64 bytes from 172.17.1.1: icmp_seq=1 ttl=64 time=2.49 ms 64 bytes from 172.17.1.1: icmp_seq=2 ttl=64 time=0.512 ms ^C --- 172.17.1.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 0.512/1.505/2.498/0.993 ms 

到现在我们已经建立了两minion之间的隧道，而且能正确的工作。下面我们将介绍如何安装Kubernetes APIServer及kubelet、proxy等服务。

4.2 安装Kubernetes APIServer

在安装APIServer之前，我们先下载Kubernetes及Etcd，做一些准备工作。在kubernetes上的具体操作如下：

[root@kubernetes ~]# mkdir /tmp/kubernetes [root@kubernetes ~]# cd /tmp/kubernetes/ [root@kubernetes kubernetes]# wget https://github.com/GoogleCloudPlatform/kubernetes/releases/download/v0.5.2/kubernetes.tar.gz [root@kubernetes kubernetes]# wget https://github.com/coreos/etcd/releases/download/v0.4.6/etcd-v0.4.6-linux-amd64.tar.gz 

然后解压下载的kubernetes和etcd包，并在kubernetes、minion1、minion2上创建目录/opt/kubernetes/bin，

[root@kubernetes kubernetes]# mkdir -p /opt/kubernetes/bin [root@kubernetes kubernetes]# tar xf kubernetes.tar.gz [root@kubernetes kubernetes]# tar xf etcd-v0.4.6-linux-amd64.tar.gz [root@kubernetes kubernetes]# cd ~/kubernetes/server [root@kubernetes server]# tar xf kubernetes-server-linux-amd64.tar.gz [root@kubernetes kubernetes]# /tmp/kubernetes/kubernetes/server/kubernetes/server/bin 

复制kube-apiserver，kube-controller-manager，kube-scheduler，kubecfg到kubernetes的/opt/kubernetes/bin目录下，而kubelet，kube-proxy则复制到minion1和minion2的/opt/kubernetes/bin，并确保都是可执行的。

[root@kubernetes amd64]# cp kube-apiserver kube-controller-manager kubecfg kube-scheduler /opt/kubernetes/bin [root@kubernetes amd64]# scp kube-proxy kubelet root@192.168.230.4:/opt/kubernetes/bin [root@kubernetes amd64]# scp kube-proxy kubelet root@192.168.230.5:/opt/kubernetes/bin 

为了简单我们只部署一台etcd服务器，如果需要部署etcd的集群，请参考官方文档，在本文中将其跟Kubernetes APIServer部署同一台机器上，而且将etcd放置在/opt/kubernetes/bin下，etcdctl跟ectd同一目录。

[root@kubernetes kubernetes]# cd /tmp/kubernetes/etcd-v0.4.6-linux-amd64 [root@kubernetes etcd-v0.4.6-linux-amd64]# cp etcd etcdctl /opt/kubernetes/bin 

需注意的是kubernetes和minion上/opt/kubernetes/bin目录下的文件都必须是可执行的。到目前，我们准备工作已经差不多，现在开始给apiserver，controller-manager，scheduler，etcd配置unit文件。首先我们用如下脚本etcd.sh配置etcd的unit文件，

#!/bin/sh  ETCD_PEER_ADDR=192.168.230.3:7001 ETCD_ADDR=192.168.230.3:4001 ETCD_DATA_DIR=/var/lib/etcd ETCD_NAME=kubernetes  ! test -d $ETCD_DATA_DIR && mkdir -p $ETCD_DATA_DIR cat <<EOF >/usr/lib/systemd/system/etcd.service [Unit] Description=Etcd Server  [Service] ExecStart=/opt/kubernetes/bin/etcd \\     -peer-addr=$ETCD_PEER_ADDR \\     -addr=$ETCD_ADDR \\     -data-dir=$ETCD_DATA_DIR \\     -name=$ETCD_NAME \\     -bind-addr=0.0.0.0  [Install] WantedBy=multi-user.target EOF  systemctl daemon-reload systemctl enable etcd systemctl start etcd 

对剩下的apiserver,controller-manager,scheduler的unit文件配置的脚本，可以在github 上GetStartingKubernetes找到，在此就不一一列举。运行相应的脚本后，在APIServer上etcd, apiserver, controller-manager, scheduler服务就能正常运行。

4.3 安装Kubernetes Kubelet及Proxy

根据Kubernetes的设计架构，需要在minion上部署docker, kubelet, kube-proxy，在4.2节部署APIServer时，我们已经将kubelet和kube-proxy已经分发到两minion上，所以只需配置docker,kubelet,proxy的unit文件，然后启动服务就即可，具体配置见GetStartingKubernetes。

5. 演示Kubernetes管理容器

为了方便，我们使用Kubernetes提供的例子Guestbook来演示Kubernetes管理跨机器运行的容器，下面我们根据Guestbook的步骤创建容器及服务。在下面的过程中如果是第一次操作，可能会有一定的等待时间，状态处于pending，这是因为第一次下载images需要一段时间。

5.1 创建redis-master Pod和redis-master服务

[root@kubernetes ~]# cd /tmp/kubernetes/kubernetes/examples/guestbook [root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 -c redis-master.json create pods [root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 -c redis-master-service.json create services 

完成上面的操作后，我们可以看到如下redis-master Pod被调度到192.168.230.4。

[root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 list pods Name                                   Image(s)                   Host                Labels                                       Status ----------                             ----------                 ----------          ----------                                   ---------- redis-master                           dockerfile/redis           192.168.230.4/      name=redis-master                            Running 

但除了发现redis-master的服务之外，还有两个Kubernetes系统默认的服务kubernetes-ro和kubernetes。而且我们可以看到每个服务都有一个服务IP及相应的端口，对于服务IP，是一个虚拟地址，根据apiserver的portal_net选项设置的CIDR表示的IP地址段来选取，在我们的集群中设置为10.10.10.0/24。为此每新创建一个服务，apiserver都会在这个地址段中随机选择一个IP作为该服务的IP地址，而端口是事先确定的。对redis-master服务，其服务地址为10.10.10.206，端口为6379。

[root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 list services Name                Labels              Selector                                  IP                  Port ----------          ----------          ----------                                ----------          ---------- kubernetes-ro                           component=apiserver,provider=kubernetes   10.10.10.207        80 redis-master        name=redis-master   name=redis-master                         10.10.10.206        6379 kubernetes                              component=apiserver,provider=kubernetes   10.10.10.161        443 

5.2 创建redis-slave Pod和redis-slave服务

[root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 -c redis-slave-controller.json create replicationControllers [root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 -c redis-slave-service.json create services 

然后通过list命令可知新建的redis-slave Pod根据调度算法调度到两台minion上，服务IP为10.10.10.92，端口为6379

[root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 list pods Name                                   Image(s)                   Host                Labels                                       Status ----------                             ----------                 ----------          ----------                                   ---------- redis-master                           dockerfile/redis           192.168.230.4/      name=redis-master                            Running 8c0ddbda-728c-11e4-8233-000c297db206   brendanburns/redis-slave   192.168.230.5/      name=redisslave,uses=redis-master            Running 8c0e1430-728c-11e4-8233-000c297db206   brendanburns/redis-slave   192.168.230.4/      name=redisslave,uses=redis-master            Running  [root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 list services Name                Labels              Selector                                  IP                  Port ----------          ----------          ----------                                ----------          ---------- redisslave          name=redisslave     name=redisslave                           10.10.10.92         6379 kubernetes                              component=apiserver,provider=kubernetes   10.10.10.161        443 kubernetes-ro                           component=apiserver,provider=kubernetes   10.10.10.207        80 redis-master        name=redis-master   name=redis-master                         10.10.10.206        6379 

5.3 创建Frontend Pod和Frontend服务

在创建之前修改frontend-controller.json的Replicas数量为2，这是因为我们的集群中只有2台minion，如果按照frontend-controller.json的Replicas默认值3，那会导致有2个Pod会调度到同一台minion上，产生端口冲突，有一个Pod会一直处于pending状态，不能被调度。

[root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 -c frontend-controller.json create replicationControllers [root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 -c frontend-service.json create services 

通过查看可知Frontend Pod也被调度到两台minion，服务IP为10.10.10.220，端口是80。

[root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 list pods Name                                   Image(s)                   Host                Labels                                       Status ----------                             ----------                 ----------          ----------                                   ---------- redis-master                           dockerfile/redis           192.168.230.4/      name=redis-master                            Running 8c0ddbda-728c-11e4-8233-000c297db206   brendanburns/redis-slave   192.168.230.5/      name=redisslave,uses=redis-master            Running 8c0e1430-728c-11e4-8233-000c297db206   brendanburns/redis-slave   192.168.230.4/      name=redisslave,uses=redis-master            Running a880b119-7295-11e4-8233-000c297db206   brendanburns/php-redis     192.168.230.4/      name=frontend,uses=redisslave,redis-master   Running a881674d-7295-11e4-8233-000c297db206   brendanburns/php-redis     192.168.230.5/      name=frontend,uses=redisslave,redis-master   Running  [root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 list services Name                Labels              Selector                                  IP                  Port ----------          ----------          ----------                                ----------          ---------- kubernetes-ro                           component=apiserver,provider=kubernetes   10.10.10.207        80 redis-master        name=redis-master   name=redis-master                         10.10.10.206        6379 redisslave          name=redisslave     name=redisslave                           10.10.10.92         6379 frontend            name=frontend       name=frontend                             10.10.10.220        80 kubernetes                              component=apiserver,provider=kubernetes   10.10.10.161        443 

除此之外，你可以删除Pod、Service及更新ReplicationController的Replicas数量等操作，如删除Frontend服务：

[root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 delete services/frontend Status ---------- Success 

还可以更新ReplicationController的Replicas的数量，下面是更新Replicas之前ReplicationController的信息。

[root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 list replicationControllers Name                   Image(s)                   Selector            Replicas ----------             ----------                 ----------          ---------- redisSlaveController   brendanburns/redis-slave   name=redisslave     2 frontendController     brendanburns/php-redis     name=frontend       2 

现在我们想把frontendController的Replicas更新为1，则这行如下命令，然后再通过上面的命令查看frontendController信息，发现Replicas已变为1。

[root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 resize frontendController 1  [root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 list replicationControllers Name                   Image(s)                   Selector            Replicas ----------             ----------                 ----------          ---------- redisSlaveController   brendanburns/redis-slave   name=redisslave     2 frontendController     brendanburns/php-redis     name=frontend       1 

5.4 演示跨机器服务通信

完成上面的操作后，我们来看当前Kubernetes集群中运行着的Pod信息。

[root@kubernetes guestbook]# kubecfg -h http://192.168.230.3:8080 list pods Name                                   Image(s)                   Host                Labels                                       Status ----------                             ----------                 ----------          ----------                                   ---------- a881674d-7295-11e4-8233-000c297db206   brendanburns/php-redis     192.168.230.5/      name=frontend,uses=redisslave,redis-master   Running redis-master                           dockerfile/redis           192.168.230.4/      name=redis-master                            Running 8c0ddbda-728c-11e4-8233-000c297db206   brendanburns/redis-slave   192.168.230.5/      name=redisslave,uses=redis-master            Running 8c0e1430-728c-11e4-8233-000c297db206   brendanburns/redis-slave   192.168.230.4/      name=redisslave,uses=redis-master            Running 

通过上面的结果可知当前提供前端服务的PHP和提供数据存储的后端服务Redis master的Pod分别运行在192.168.230.5和192.168.230.4上，即容器运行在不同主机上，还有Redis slave也运行在两台不同的主机上，它会从Redis master同步前端写入Redis master的数据。下面我们从两方面验证Kubernetes能提供跨机器间容器的通信：

• 在浏览器打开http://${IPAddress}:8000，IPAddress为PHP容器运行的minion的IP地址，其暴漏的端口为8000，这里IP_Address为192.168.230.5。打开浏览器会显示如下信息：

  

  你可以输入信息并提交，如"Hello Kubernetes"、"Container"，然后Submit按钮下方会显示你输入的信息。

  

  由于前端PHP容器和后端Redis master容器分别在两台minion上，因此PHP在访问Redis master服务时一定得跨机器通信，可见Kubernetes的实现方式避免了用link只能在同一主机上实现容器间通信的缺陷，对于Kubernetes跨机器通信的实现方法，以后我会详细介绍。

   

• 从上面的结果，可得知已经实现了跨机器的通信，现在我们从后端数据层验证不同机器容器间的通信。根据上面的输出结果发现Redis slave和Redis master分别调度到两台不同的minion上，在192.168.230.4主机上执行docker exec -ti c41711cc8971 /bin/sh，c41711cc8971是Redis master的容器ID，进入容器后通过redis-cli命令查看从浏览器输入的信息如下：

  

  如果我们在192.168.230.5上运行的Redis slave容器里查到跟Redis master容器里相同的信息，那说明Redis master和Redis slave之间的数据同步正常工作，下面是从192.168.230.5上运行的Redis slave容器查询到的信息：

  

  由此可见Redis master和Redis slave之间数据同步正常，OVS GRE隧道技术使得跨机器间容器正常通信。

6. 结论

本文主要介绍如何在本地环境部署Kubernetes集群和演示如何通过Kubernetes管理集群中运行的容器，并通过OVS管理集群不同minion的Pod之间的网络通信。接下来会对Kubernetes各个组件源码进行详细分析，阐述Kubernetes的工作原理。

7. 个人简介

杨章显，现就职于Cisco，主要从事WebEx SaaS服务运维，系统性能分析等工作。特别关注云计算，自动化运维，部署等技术，尤其是Go、OpenvSwitch、Docker及其生态圈技术，如Kubernetes、Flocker等Docker相关开源项目。Email: yangzhangxian@gmail.com

8. 参考资料

1. https://n40lab.wordpress.com/2014/09/04/openvswitch-2-3-0-lts-and-centos-7/
2. https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/guestbook

感谢郭蕾对本文的策划和审校。

加快Kubernetes编译速度

除了Linux/amd64，默认还会为其他平台做交叉编译。为了减少编译时间，可以修改hack/lib/golang.sh，把KUBE_SERVER_PLATFORMS， KUBE_CLIENT_PLATFORMS和KUBE_TEST_PLATFORMS中除linux/amd64以外的其他平台注释掉

gcr.io无法访问

Kubernetes在创建Pod的时候，需要从gcr.io下载一个helper镜像（目前是 gcr.io/google_containers/pause-amd64:3.0 ）。

但是目前国内无法访问gcr.io，这个问题会导致无法下载该镜像，然后Pod一直处于ContainerCreating状态。

解决办法

Note

不通过私有registry中转，而是使用Docker save/load应该也可以，只是要把save导出的文件复制到所有节点.

如何从集群外访问Service和Pod

这里说的集群外是指K8s集群以外的主机，比如使用nginx/HAProxy搭建的负载均衡主机。这些主机跟K8s集群部署在一起，到K8s网络可达。

对于不是部署在GCE以及AWS等云平台的K8s，我们一般需要自己搭建负载均衡，然后分发请求到到Service。

使用NodePort方式发布服务，那么负载均衡主机上不需要额外配置；使用ClusterIP方式，为了能够访问Service的ClusterIP， 需要在这些主机上安装Flanneld和kube-proxy

如果你想在命令行界面监控网络吞吐量，nload 应用程序是个不错的选择。它是一个实时监控网络流量和带宽使用的控制台应用程序，使用两个图表可视化地展示接收和发送的流量，并提供诸如数据交换总量、最小/最大网络带宽使用量等附加信息。

安装

在 CentOS/RHEL/Red Hat/Fedora Linux 上安装 nload

首先在 CentOS 或者基于 RHEL 的操作系统上启用 EPEL 仓库，然后键入 yum 命令安装 nload：

# yum install nload

在 Debian 或者 Ubuntu Linux 上安装 nload

键入 apt-get 命令：

$ sudo apt-get install nload

在 FreeBSD 操作系统上安装 nload

通过 port 安装 nload，键入：

# cd /usr/ports/net/nload/ && make install clean

或者添加包

# pkg install net/nload

在 OpenBSD 操作系统上安装 nload

键入下列命令：

$ sudo pkg_add -i nload

在类 Unix 操作系统上从源代码安装 nload

首先，使用 wget 或者 curl 命令获取源代码：

$ cd /tmp
$ wget http://www.roland-riegel.de/nload/nload-0.7.4.tar.gz

使用 tar 命令解压缩名为 nload-0.7.4.tar.gz 的 tar 包，键入：

$ tar xvf nload-0.7.4.tar.gz

使用 cd 命令进入 nload 源代码所在目录：

$ cd nload*

然后键入 ./configure 为你的操作系统配置安装包：

$ sh ./configure

或者

$ ./configure

运行 configure 命令需要一点时间。完成后，使用 make 命令编译 nload：

$ make

最后，键入 make install 命令以 root 用户身份安装 nload 应用程序和相关文件：

$ sudo make install

或者

# make install

使用

如何使用 nload 显示当前网络使用量呢？

基本语法是：

nload
nload device
nload [options] device1 device2

键入下列命令：

$ nload
$ nload eth0
$ nload em0 em2

会得到输出：

图01: 使用 nload 命令

操控 nload 应用程序

nload 命令一旦执行就会开始监控网络设备，你可以使用下列快捷键操控 nload 应用程序。

1. 你可以按键盘上的 ← → 或者 Enter/Tab 键在设备间切换。
2. 按 F2 显示选项窗口。
3. 按 F5 将当前设置保存到用户配置文件。
4. 按 F6 从配置文件重新加载设置。
5. 按 q 或者 Ctrl+C 退出 nload。

设置显示刷新间隔

默认每 100 毫秒刷新一次显示数值，下面的例子将时间间隔设置成 500 毫秒：

$ nload -t {interval_number_in_millisec}
$ nload -t 500

输出：

Animated gif 01 - nload command in action

GIF 动画 01 - 使用 nload 命令

设置流量数值显示的单位

语法如下：

$ nload -u h|H|b|B|k|K|m|M|g|G
$ nload -U h|H|b|B|k|K|m|M|g|G
$ nload -u h
$ nload -u G
$ nload -U G

释义：

• 小写选项 -u: h 意为自动格式化为人类易读的单位，b 意为 Bit/s，k 意为 kBit/s，m 意为 MBit/s，g 意为 GBit/s。大写字母意为使用 Byte 替代 Bit。默认为 k。
• 大写选项 -U 与小写选项 -u 非常相似，不同之处在于它展示的是数据量，比如 Bit, kByte, GBit 等等。（没有 "/s"）。默认值是 M。

结论

我觉得 nload 是一个稳定可靠的应用程序，如果你喜欢 nload，你可能也想试试 Linux 和其他类 Unix 操作系统环境下的 vnstat 与 iftop 工具。

译自: http://www.cyberciti.biz/networking/nload-linux-command-to-monitor-network-traffic-bandwidth-usage/

Today, we’re excited to announce the general availability of Apache Spark 2.0 on Databricks. This release builds on what the community has learned in the past two years, doubling down on what users love and fixing the pain points. This post summarizes the three major themes—easier, faster, and smarter—that comprise Spark 2.0. We also explore many of them in more detail in our anthology of Spark 2.0 content.

Two months ago, we launched a preview release of Apache Spark 2.0 on Databricks. As you can see in the chart below, 10% of our clusters are already using this release, as customers experiment with the new features and give us feedback. Thanks to this experience, we are excited to be the first commercial vendor to support Spark 2.0.

Apache Spark Usage over Time by Version

Now, let’s dive into what’s new in Apache Spark 2.0.

Easier: ANSI SQL and Streamlined APIs

One thing we are proud of in Spark is APIs that are simple, intuitive, and expressive. Spark 2.0 continues this tradition, focusing on two areas: (1) standard SQL support and (2) unifying DataFrame/Dataset API.

On the SQL side, we have significantly expanded Spark’s SQL support, with the introduction of a new ANSI SQL parser and subqueries. Spark 2.0 can run all the 99 TPC-DS queries, which require many of the SQL:2003 features. Because SQL has been one of the primary interfaces to Spark, these extended capabilities drastically reduce the effort of porting legacy applications.

On the programmatic API side, we have streamlined Spark’s APIs:

• Unifying DataFrames and Datasets in Scala/Java: Starting in Spark 2.0, DataFrame is just a type alias for Dataset of Row. Both the typed methods (e.g. map, filter, groupByKey) and the untyped methods (e.g. select, groupBy) are available on the Dataset class. Also, this new combined Dataset interface is the abstraction used for Structured Streaming. Since compile-time type-safety is not a feature in Python and R, the concept of Dataset does not apply to these language APIs. Instead, DataFrame remains the primary interface there, and is analogous to the single-node data frame notion in these languages. Get a peek fromthis notebook and this blog for the stories behind these APIs.
• SparkSession: a new entry point that supersedes SQLContext and HiveContext. For users of the DataFrame API, a common source of confusion for Spark is which “context” to use. Now you can use SparkSession, which subsumes both, as a single entry point, asdemonstrated in this notebook. Note that the old SQLContext and HiveContext classes are still kept for backward compatibility.
• Simpler, more performant Accumulator API: We have designed a new Accumulator APIthat has a simpler type hierarchy and support specialization for primitive types. The old Accumulator API has been deprecated but retained for backward compatibility
• DataFrame-based Machine Learning API emerges as the primary ML API: With Spark 2.0, the spark.ml package, with its “pipeline” APIs, will emerge as the primary machine learning API. While the original spark.mllib package is preserved, future development will focus on the DataFrame-based API.
• Machine learning pipeline persistence: Users can now save and load machine learning pipelines and models across all programming languages supported by Spark. See this blog post for more details and this notebook for examples.
• Distributed algorithms in R: Added support for Generalized Linear Models (GLM), Naive Bayes, Survival Regression, and K-Means in R.
• User-defined functions (UDFs) in R: Added support for running partition level UDFs (dapply and gapply) and hyper-parameter tuning (lapply).

Faster: Apache Spark as a Compiler

According to our 2015 Spark Survey, 91% of users consider performance as the most important aspect of Apache Spark. As a result, performance optimizations have always been a focus in our Spark development. Before we started planning our contributions to Spark 2.0, we asked ourselves a question: Spark is already pretty fast, but can we push the boundary and make Spark 10X faster?

This question led us to fundamentally rethink the way we build Spark’s physical execution layer. When you look into a modern data engine (e.g. Spark or other MPP databases), majority of the CPU cycles are spent in useless work, such as making virtual function calls or reading/writing intermediate data to CPU cache or memory. Optimizing performance by reducing the amount of CPU cycles wasted in these useless work has been a long time focus of modern compilers.

Spark 2.0 ships with the second generation Tungsten engine. This engine builds upon ideas from modern compilers and MPP databases and applies them to Spark workloads. The main idea is to emit optimized code at runtime that collapses the entire query into a single function, eliminating virtual function calls and leveraging CPU registers for intermediate data. We call this technique “whole-stage code generation.”

To give you a teaser, we have measured the time (in nanoseconds) it takes to process a row on one core for some of the operators in Spark 1.6 vs. Spark 2.0. The table below shows the improvements in Spark 2.0. Spark 1.6 also included an expression code generation technique that is used in some state-of-the-art commercial databases, but as you can see, many operators became an order of magnitude faster with whole-stage code generation.

You can see the power of whole-stage code generation in action in this notebook, in which we perform aggregations and joins on 1 billion records on a single machine.

How does this new engine work on end-to-end queries? We did some preliminary analysis using TPC-DS queries to compare Spark 1.6 and Spark 2.0:

Beyond whole-stage code generation to improve performance, a lot of work has also gone into improving the Catalyst optimizer for general query optimizations such as nullability propagation, as well as a new vectorized Parquet decoder that improved Parquet scan throughput by 3X. Read this blog post for more detail on the optimizations in Spark 2.0.

Smarter: Structured Streaming

Spark Streaming has long led the big data space as one of the first systems unifying batch and streaming computation. When its streaming API, called DStreams, was introduced in Spark 0.7, it offered developers with several powerful properties: exactly-once semantics, fault-tolerance at scale, strong consistency guarantees and high throughput.

However, after working with hundreds of real-world deployments of Spark Streaming, we found that applications that need to make decisions in real-time often require more than just a streaming engine. They require deep integration of the batch stack and the streaming stack, interaction with external storage systems, as well as the ability to cope with changes in business logic. As a result, enterprises want more than just a streaming engine; instead they need a full stack that enables them to develop end-to-end “continuous applications.”

Spark 2.0 tackles these use cases through a new API called Structured Streaming. Compared to existing streaming systems, Structured Streaming makes three key improvements:

1. Integrated API with batch jobs. To run a streaming computation, developers simply write a batch computation against the DataFrame / Dataset API, and Spark automaticallyincrementalizes the computation to run it in a streaming fashion (i.e. update the result as data comes in). This powerful design means that developers don’t have to manually manage state, failures, or keeping the application in sync with batch jobs. Instead, the streaming job always gives the same answer as a batch job on the same data.
2. Transactional interaction with storage systems. Structured Streaming handles fault tolerance and consistency holistically across the engine and storage systems, making it easy to write applications that update a live database used for serving, join in static data, or move data reliably between storage systems.
3. Rich integration with the rest of Spark. Structured Streaming supports interactive queries on streaming data through Spark SQL, joins against static data, and many libraries that already use DataFrames, letting developers build complete applications instead of just streaming pipelines. In the future, expect more integrations with MLlib and other libraries.

Spark 2.0 ships with an initial, alpha version of Structured Streaming, as a (surprisingly small!) extension to the DataFrame/Dataset API. This makes it easy to adopt for existing Spark users that want to answer new questions in real-time. Other key features include support for event-time based processing, out-of-order/delayed data, interactive queries, and interaction with non-streaming data sources and sinks.

We also updated the Databricks workspace to support Structured Streaming. For example, when launching a streaming query, the notebook UI will automatically display its status.

Streaming is clearly a broad topic, so stay tuned for a series of blog posts with more details on Structured Streaming in Apache Spark 2.0.

Conclusion

Spark users initially came to Apache Spark for its ease-of-use and performance. Spark 2.0 doubles down on these while extending it to support an even wider range of workloads. Enjoy the new release on Databricks.

Read More

You can also import the following notebooks and try them on Databricks Community Editionwith Spark 2.0.

• SparkSession: A new entry point
• Datasets: A more streamlined API
• Performance of whole-stage code generation
• Machine learning pipeline persistence

Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，旨在快速处理大规模的数据，并能够实现快速查询和分析。尤其是当发生代码部署、机器故障以及其他产品系统遇到宕机等情况时，Druid仍能够保持100%正常运行。创建Druid的最初意图主要是为了解决查询延迟问题，当时试图使用Hadoop来实现交互式查询分析，但是很难满足实时分析的需要。而Druid提供了以交互方式访问数据的能力，并权衡了查询的灵活性和性能而采取了特殊的存储格式。

Druid功能介于PowerDrill和Dremel之间，它几乎实现了Dremel的所有功能，并且从PowerDrill吸收一些有趣的数据格式。Druid允许以类似Dremel和PowerDrill的方式进行单表查询，同时还增加了一些新特性，如为局部嵌套数据结构提供列式存储格式、为快速过滤做索引、实时摄取和查询、高容错的分布式体系架构等。从官方得知，Druid的具有以下主要特征：

• 为分析而设计——Druid是为OLAP工作流的探索性分析而构建，它支持各种过滤、聚合和查询等类；
• 快速的交互式查询——Druid的低延迟数据摄取架构允许事件在它们创建后毫秒内可被查询到；
• 高可用性——Druid的数据在系统更新时依然可用，规模的扩大和缩小都不会造成数据丢失；
• 可扩展——Druid已实现每天能够处理数十亿事件和TB级数据。

Druid应用最多的是类似于广告分析创业公司Metamarkets中的应用场景，如广告分析、互联网广告系统监控以及网络监控等。当业务中出现以下情况时，Druid是一个很好的技术方案选择：

• 需要交互式聚合和快速探究大量数据时；
• 需要实时查询分析时；
• 具有大量数据时，如每天数亿事件的新增、每天数10T数据的增加；
• 对数据尤其是大数据进行实时分析时；
• 需要一个高可用、高容错、高性能数据库时。

一个Druid集群有各种类型的节点（Node）组成，每个节点都可以很好的处理一些的事情，这些节点包括对非实时数据进行处理存储和查询的Historical节点、实时摄取数据、监听输入数据流的Realtime节、监控Historical节点的Coordinator节点、接收来自外部客户端的查询和将查询转发到Realtime和Historical节点的Broker节点、负责索引服务的Indexer节点。

查询操作中数据流和各个节点的关系如下图所示：

如下图是Druid集群的管理层架构，该图展示了相关节点和集群管理所依赖的其他组件（如负责服务发现的ZooKeeper集群）的关系：

Druid已基于Apache License 2.0协议开源，代码托管在GitHub，其当前最新稳定版本是0.7.1.1。当前，Druid已有63个代码贡献者和将近2000个关注。Druid的主要贡献者包括广告分析创业公司Metamarkets、电影流媒体网站Netflix、Yahoo等公司。Druid官方还对Druid同Shark、Vertica、Cassandra、Hadoop、Spark、Elasticsearch等在容错能力、灵活性、查询性能等方便进行了对比说明。更多关于Druid的信息，大家还可以参考官方提供的入门教程、白皮书、设计文档等。

作者：祝威廉

• 工程数据，譬如工单数量，SLA可用性，基础资源，故障率，报警统计
• 业务数据，譬如业务DashBoard,Trace调用链，业务拓扑切换，业务指标，业务基准数据，业务日志挖掘
• 数据可视化

当然，这篇文章谈的是运维都有哪些数据，哪些指标，以及数据呈现。并没有谈及如何和大数据相关的架构做整合，从而能让这些数据真的变得活起来。

比较凑巧的是，原先百度的桑文峰的分享也讲到日志的多维度分析，吃完饭的时候，一位优酷的朋友也和我探讨了关于业务监控的的问题。而我之前发表在肉饼铺子里的一篇文章《 大数据给公司带来了什么 》也特地提到了大数据对于整个运维的帮助，当时因为这篇内容的主旨是罗列大数据的用处，自然没法细讲运维和大数据的整合这一块。

上面的文字算引子，在步入正式的探讨前，有一点我觉得值得强调：

虽然这里讲的是如何将大数据思维/架构应用于运维，平台化运维工作，但是和大数据本质上没有关系，我们只是将大数据处理的方式和思想应用在运维工作上。所以，即使你现在所在的公司没有数据团队支撑，也是完全可以通过现有团队完成这件事情的。

1 运维监控现状

很多公司的运维的监控具有如下特质：

只能监控基础运维层次，通过zabbix等工具提供服务器,CPU,内存等相关的监控。这部分重要，但确实不是运维的核心。

对业务的监控是最复杂的，而现在很多公司的要么还处于Shell脚本的刀耕火种阶段，要么开发能力较强，但是还是东一榔头西一棒子，不同的业务需要不同的监控系统，人人都可以根据的自己的想法开发一个监控的工具也好，系统也好，平台也好。总之是比较凌乱的。

使用第三方的监控平台。这个似乎在Rails/NodeJS/Pythone相关语系开发的产品中比较常见。我不做过多评价，使用后冷暖自知。

当然也有抽象得很好的，比如点评网的运维监控据说就做得相当好，运维很闲，天天没事就根据自己的监控找开发的茬，让开发持续改进。不过他们的指导思想主要有两个：

运维自动化。怎么能够实现这个目标就怎么搞，这严重依赖于搞的人的规划能力和经验。

抽象化，根据实际面临的问题做出抽象，得到对应的系统，比如需要发布，于是又发布系统，需要管理配置文件，所以有配管系统，需要日志分析所以有了有日志分析系统。然而这样是比较零散的。

有点扯远，我们还是focus在监控上。

如果以大数据的思维去思考，我们应该如何做好监控这件事情?

2 罗列出你的数据源

《大数据对于运维的意义》这篇文章也讲了，主要有工程数据，业务数据。所有的数据源都有一个共性，就是 日志 。无论文本的也好，二进制的也好。所以日志是整个信息的源头。日志包含的信息足以让我们追查到下面几件事情：

• 系统健康状况监控
• 查找故障根源
• 系统瓶颈诊断和调优
• 追踪安全相关问题
• 从日志我们可以挖掘出什么?

我觉得抽象起来就一个： 指标 。

指标可以再进行分类：

业务层面，如团购业务每秒访问数，团购券每秒验券数，每分钟支付、创建订单等

应用层面，每个应用的错误数，调用过程，访问的平均耗时，最大耗时，95线等

系统资源层面：如cpu、内存、swap、磁盘、load、主进程存活等

网络层面： 如丢包、ping存活、流量、tcp连接数等

每个分类里的每个小点其实都是一个指标。

3 如何统一实现

千万不要针对具体问题进行解决，大数据架构上的一个思维就是：我能够提供一个平台让大家方便解决这些问题么? 而不是，这个问题我能解决么?

先来看看架构图：

• 推荐
• 搜索
• 统一查询引擎

所以监控的架构设计略简单些。如果你希望进行日志存储以及事后批量分析，则可以采用淘宝的这套架构方式：

将日志过滤，格式化，或存储起来

进行实时计算，将指标数据存储到HBase里去

到目前为止，我们没有做任何的开发，全部使用大数据里通用的一些组件。至于这些组件需要多少服务器，就看对应的日志量规模了，三五台到几百台都是可以的。

需要开发的地方只有两个点，有一个是一次性的，有一个则是长期。

先说说一次性的，其实就是大盘展示系统。这个就是从HBase里取出数据做展示。这个貌似也有开源的一套，ELK。不过底层不是用的HBase存储，而是ES。这里就不详细讨论。

长期的则是SparkStreaming(淘宝是使用Storm，我建议用SparkStreaming,因为SparkStreaming可以按时间窗口，也可以按量统一做计算)，这里你需要定义日志的处理逻辑，生成我上面提到的各项指标。

这里有一个什么好处呢，就是平台化了，对新的监控需求响应更快了，开发到上线可能只要几个小时的功夫。如果某个系统某天需要一个新的监控指标，我们只要开发个SparkStreaming程序，丢到平台里去，这事就算完了。

第一幅图的平台我是已经实现了的。我目前在SparkStreaming上只做了三个方面比较基础的监控，不过应该够用了。

状态码大盘。 HTTP响应码的URL(去掉query参数)排行榜。比如你打开页面就可以看到发生500错误的top100的URL，以及该URL所归属的系统。

响应耗时大盘。 URL请求耗时排行榜。比如你打开页面就可以看到5分钟内平均响应耗时top100的URL(去掉query参数)。

还有就是Trace系统。 类似Google的Dapper,淘宝的EagleEye。给出一个唯一的UUID,可以追踪到特定一个Request的请求链路。每个依赖服务的响应情况，比如响应时间。对于一个由几个甚至几百个服务组成的大系统，意义非常大，可以方便的定位出到底是那个系统的哪个API的问题。这个最大的难点是需要统一底层的RPC/HTTP调用框架，进行埋点。因为我使用的是自研的ServiceFramework框架，通讯埋点就比较简单。如果是在一个业务线复杂，各个系统使用不同技术开发，想要做这块就要做好心理准备了。

现在，如果你想要监控一个系统是不是存活，你不在需要取写脚本去找他的pid看进程是不是存在，系统发现在一定的周期内没有日志，就可以认为它死了。而系统如果有异常，比如有大量的慢查询，大盘一定能展示出来。

描述到这，我们可以看到，这套架构的优势在哪：

基本上没有需要自己开发的系统。从日志收集，到日志存储，到结果存储等，统统都是现成的组件。

可扩展性好。每个组件都是集群模式的，没有单点故障。每个组件都是可水平扩展的，日志量大了，加机器就好。

开发更集中了。你只要关注日志实际的分析处理，提炼指标即可。

4 大数据思维

对于运维的监控，利用大数据思维，需要分三步走：

• 找到数据
• 分析定义从数据里中我能得到什么
• 从大数据平台中挑选你要的组件完成搭积木式开发

所有系统最可靠的就是日志输出，系统是不是正常，发生了什么情况，我们以前是出了问题去查日志，或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上，我们唯一要做的就是 定义处理日志的的逻辑 。

这里有几点注意的：

如果你拥有复杂的产品线，那么日志格式会是一个很痛苦的事情。以为这中间Storm(或者SparkStreaming)的处理环节你需要做大量的兼容适配。我个人的意见是，第一，没有其他更好的办理，去兼容适配吧，第二，推动大家统一日志格式。两件事情一起做。我一个月做不完，那我用两年时间行么?总有一天大家都会有统一的日志格式的。

如果你的研发能力有富余,或者有大数据团队支撑，那么可以将进入到SparkStreaming中的数据存储起来，然后通过SparkSQL等做即席查询。这样，有的时候原先没有考虑的指标，你可以直接基于日志做多维度分析。分析完了，你觉得好了，需要固化下来，那再去更新你的SparkStreaming程序。

后话

我做上面第一幅图架构实现时，从搭建到完成SparkStreaming程序开发，到数据最后进入HBase存储，大概只花了一天多的时间。当然为了完成那个Trace的指标分析，我修改ServiceFramework框架大约改了两三天。因为Trace分析确实比较复杂。当然还有一个比较消耗工作量的，是页面可视化，我这块自己还没有能力做，等招个Web开发工程师再说了。

End.

华为宣布开源了CarbonData项目，该项目于6月3日通过Apache社区投票，成功进入Apache孵化器。CarbonData是一种低时延查询、存储和计算分离的轻量化文件存储格式。那么相比SQL on Hadoop方案、传统NoSQL或相对ElasticSearch等搜索系统，CarbonData具有什么样的优势呢？CarbonData的技术架构是什么样子的？未来有什么样的规划？我们采访了CarbonData项目的技术负责人为大家解惑。

InfoQ：请问CarbonData是什么时候开始进行的项目？为什么现在向Apache孵化器开源呢？开源发展历程和项目目前状态是怎么样的？

CarbonData：CarbonData项目是华为公司从多年数据处理经验和行业理解中逐步积累起来的，2015年我们对系统进行了一次架构重构，使其演化为HDFS上的一套通用的列式存储，支持和Spark引擎对接后形成一套分布式OLAP分析的解决方案。

华为一直是面向电信、金融、IT企业等用户提供大数据平台解决方案的供应商，从众多客户场景中我们不断提炼数据特征，总结出了一些典型的对大数据分析的诉求，逐步形成了CarbonData这个架构。

因为在IT领域，只有开源开放，才能最终让更多的客户和合作伙伴的数据连接在一起，产生更大商业价值。开源是为了构建E2E生态，CarbonData是数据存储层技术，要发挥价值，需要与计算层、查询层有效集成在一起，形成完成真正的生态发挥价值。

又因为Apache是目前大数据领域最权威的开源组织，其中的Hadoop，Spark已成为大数据开源的事实标准，我们也非常认可Apache以Community驱动技术进步的理念，所以我们选择进入Apache，与社区一同构建能力，使CarbonData融入大数据生态。

目前CarbonData开源项目已经在6月3日通过Apache社区投票，成功进入Apache孵化器。github地址：https://github.com/apache/incubator-carbondata。欢迎大家参与到Apache CarbonData社区： https://github.com/apache/incubator-carbondata/blob/master/docs/How-to-contribute-to-Apache-CarbonData.md。

InfoQ：请问是什么原因或机遇促使您们产生做CarbonData这个项目的想法的？之前的项目中遇到什么样的困难？

CarbonData：我们一直面临着很多高性能数据分析诉求，在传统的做法里，一般是使用数据库加BI工具实现报表、DashBoard和交互式查询等业务，但随着企业数据日益增大，业务驱动的分析灵活性要求逐渐增大，也有部分客户希望有除SQL外更强大的分析功能，所以传统的方式渐渐满足不了客户需求，让我们产生了做CarbonData这个项目的想法。

需求一般来源于几方面。

第一，在部署上，区别于以往的单机系统，企业客户希望有一套分布式方案来应对日益增多的数据，随时可以通过增加通用服务器的方式scale out横向扩展。

第二，在业务功能上，很多企业的业务都处在从传统数据库逐渐转移到大数据平台的迁移过程中，这就要求大数据平台要有较高兼容老业务的能力，这里面主要包含的是对完整的标准SQL支持，以及多种分析场景的支持。同时为了节约成本，企业希望“一份数据支持多种使用场景”，例如大规模扫描和计算的批处理场景，OLAP多维交互式分析场景，明细数据即席查询，主键低时延点查，以及对实时数据的实时查询等场景，都希望平台能给予支持，且达到秒级查询响应。

第三，在易用性上，企业客户以往使用BI工具，业务分析的OLAP模型是需要在BI工具中建立的，这就会导致有的场景下数据模型的灵活性和分析手段受到限制，而在大数据时代，大数据开源领域已经形成了一个生态系统，社区随时都在进步，经常会冒出一些新型的分析工具，所以企业客户都希望能跟随社区不断改进自己的系统，在自己的数据里快速用上新型的分析工具，得到更大的商业价值。

要同时达到上诉要求，无疑对大数据平台是一个很大的挑战。为了满足这些要求，我们开始不断在实际项目中积累经验，也尝试了很多不同的解决方案，但都没有发现能用一套方案解决所有问题。

大家首先会想到的是，在涉及到低时延查询的分布式存储中，一般常用的是KV型NoSQL数据库（如HBase，Cassandra），可以解决主键低时延查询的问题，但如果业务的查询模式稍作改变，例如对多维度灵活组合的查询，就会使点查变为全表扫描，使性能急剧下降。有的场景下，这时可以通过加入二级索引来缓解该问题，但这又带来了二级索引的维护和同步等管理问题，所以KV型存储并不是解决企业问题的通用方案。

那么，如果要解决通用的多维查询问题，有时我们会想到用多维时序数据库的方案（如Linkedin Pinot），他们的特点是数据都以时间序列的方式进入系统并经过数据预聚合和建立索引，因为是预计算，所以应对多维查询时非常快，数据也非常及时，同时具备多维分析和实时处理的优点，在性能监控、实时指标分析的场景里应用较多。但它在支持的查询类型上也有一定限制，因为做了数据预计算，所以这种架构一般无法应对明细数据查询，以及不支持Join多表关联分析，这无疑给企业使用场景带来了一定的限制。

另外一类是搜索系统（如Apache Solr，ElasticSearch），搜索系统可以做多维汇总也可以查询明细数据，它也具备基于倒排索引的快速布尔查询，并发也较高，似乎正是我们希望寻找的方案。但在实际应用中我们发现两个问题：一是由于搜索系统一般是针对非结构化数据而设计的，系统的数据膨胀率一般都比较高，在企业关系型数据模型下数据存储不够紧凑，造成数据量较大，二是搜索系统的数据组织方式和计算引擎密切相关，这就导致了数据入库后只能用相应的搜索引擎处理，这又一定程度打破了企业客户希望应用多种社区分析工具的初衷，所以搜索系统也有他自己的适用场景。

最后一类系统，就是目前社区里大量涌现的SQL on Hadoop方案，以Hive, SparkSQL, Flink为代表，这类系统的特点是计算和存储相分离，针对存储在HDFS上的文件提供标准SQL功能，他们在部署性和易用性上可以满足企业客户需求，业务场景上也能覆盖扫描，汇聚，详单等各类场景，可见可以将他们视为一类通用的解决方案。为了提高性能，Spark，Flink等开源项目通过不断优化自身架构提升计算性能，但提升重点都放在计算引擎和SQL优化器的增强上，在存储和数据组织上改进并不是重点。

所以，可以看出当前的很多大数据系统虽然都能支持各类查询场景，但他们都是偏向某一类场景设计的，在不是其目标场景的情况下要么不支持要么退化为全表扫描，所以导致企业为了应对批处理，多维分析，明细数据查询等场景，客户常常需要通过复制多份数据，每种场景要维护一套数据。

CarbonData的设计初衷正是为了打破这种限制，做到只保存一份数据，最优化地支撑多种使用场景。

InfoQ:能否具体谈谈CarbonData的技术架构？有何特征和优势呢？

CarbonData：整个大数据时代的开启，可以说是源自于Google的MapReduce论文，他引发了Hadoop开源项目以及后续一系列的生态发展。他的“伟大”之处在于计算和存储解耦的架构，使企业的部分业务（主要是批处理）从传统的垂直方案中解放出来，计算和存储可以按需扩展极大提升了业务发展的敏捷性，让众多企业普及了这一计算模式，从中受益。

虽然MapReduce开启了大数据时代，但它是通过纯粹的暴力扫描+分布式计算来提升批处理性能，所以并不能解决客户对所有查询场景的低时延查询要求。

在目前的生态中，最接近于客户要求的其实是搜索引擎类方案。通过良好的数据组织和索引，搜索引擎能提供多种快速的查询功能，但偏偏搜索引擎的存储层又和计算引擎是紧耦合的，并不符合企业对”一份数据，多种场景”的期望。

这给了我们启发，我们何不为通用计算引擎打造更一个高效的数据组织来满足客户需求呢，做到既利用计算和存储解耦架构又能提供高性能查询。抱着这个想法，我们启动了CarbonData项目。针对更多的业务，使计算和存储相分离，这也成了CarbonData的架构设计理念。

确立了这个理念后，我们很自然地选择了基于HDFS+通用计算引擎的架构，因为这个架构可以很好地提供Scale out能力。下一步我们问自己这个架构里还缺什么？这个架构中，HDFS提供文件的复制和读写能力，计算引擎负责读取文件和分布式计算，分工很明确，可以说他们分别定位于解决存储管理和计算的问题。但不难看出，为了适应更多场景，HDFS做了很大的“牺牲”，它牺牲了对文件内容的理解，正是由于放弃了对文件内容的理解，导致计算只能通过全扫描的方式来进行，可以说最终导致的是存储和计算都无法很好的利用数据特征来做优化。

所以针对这个问题，我们把CarbonData的发力重点放在对数据组织的优化上，通过数据组织最终是要提升IO性能和计算性能。为此，CarbonData做了如下工作。

CarbonData基础特性

1. 多维数据聚集：在入库时对数据按多个维度进行重新组织，使数据在“多维空间上更内聚”，在存储上获得更好的压缩率，在计算上获得更好的数据过滤效率。

2. 带索引的列存文件结构：首先，CarbonData为多类场景设计了多个级别的索引，并融入了一些搜索的特性，有跨文件的多维索引，文件内的多维索引，每列的minmax索引，以及列内的倒排索引等。其次，为了适应HDFS的存储特点，CarbonData的索引和数据文件存放在一起，一部分索引本身就是数据，另一部分索引存放在文件的元数据结构中，他们都能随HDFS提供本地化的访问能力。

3. 列组：整体上，CarbonData是一种列存结构，但相对于行存来说，列存结构在应对明细数据查询时会有数据还原代价高的问题，所以为了提升明显数据查询性能，CarbonData支持列组的存储方式，用户可以把某些不常作为过滤条件但又需要作为结果集返回的字段作为列组来存储，经过CarbonData编码后会将这些字段使用行存的方式来存储以提升查询性能。

4. 数据类型：目前CarbonData支持所有数据库的常用基本类型，以及Array，Struct复杂嵌套类型。同时社区也有人提出支持Map数据类型，我们计划未来添加Map数据类型。

5. 压缩：目前CarbonData支持Snappy压缩，压缩是针对每列分别进行的，因为列存的特点使得压缩非常高效。数据压缩率基于应用场景不同一般在2到8之间。

6. Hadoop集成：通过支持InputFormat/OutputFormat接口，CarbonData可以利用Hadoop的分布式优点，也能在所有以Hadoop为基础的生态系统中使用。

CarbonData高级特性

1. 可计算的编码方式：除了常见的Delta，RLE，Dictionary，BitPacking等编码方式外，CarbonData还支持将多列进行联合编码，以及应用了全局字典编码来实现免解码的计算，计算框架可以直接使用经过编码的数据来做聚合，排序等计算，这对需要大量shuffle的查询来说性能提升非常明显。

2. 与计算引擎联合优化：为了高效利用CarbonData经过优化后的数据组织，CarbonData提供了有针对性的优化策略，目前CarbonData社区首先做了和Spark的深度集成，其中基于SparkSQL框架增强了过滤下压，延迟物化，增量入库等特性，同时支持所有DataFrame API。相信未来通过社区的努力，会有更多的计算框架与CarbonData集成，发挥数据组织的价值。

目前这些特性都已经合入Apache CarbonData主干，欢迎大家使用。

InfoQ：在哪些场景推荐使用呢？性能测试结果如何？有没有应用案例，目前在国内的使用情况和用户规模？

CarbonData：推荐场景：希望一份存储同时满足快速扫描，多维分析，明细数据查询的场景。在华为的客户使用案例中，对比业界已有的列存方案，CarbonData可以带来5~30倍性能提升。

性能测试数据及应用案例等更多信息，请关注微信公众号ApacheCarbonData，及社区https://github.com/apache/incubator-carbondata。

InfoQ：CarbonData能和当前正火的Spark完美结合吗？还能兼容哪些主流框架呢？

CarbonData：目前CarbonData已与Spark做了深度集成，具体见上述高级特性。

InfoQ：您们的项目在未来有什么样的发展规划？还会增加什么功能吗？如何保证开源之后的项目的持续维护工作呢？

CarbonData：接下来社区重点工作是，提升系统易用性、完善生态集成（如：与Flink,Kafka等集成，实现数据实时导入CarbonData）。

CarbonData开源的第一个月，就有几百个commits提交，和20多个贡献者参与，所以后续这个项目会持续的活跃。10多个核心贡献者也将会持续参与社区建设。

InfoQ：在CarbonData设计研发并进入Apache孵化器的过程中，经历了哪些阶段，经历过的最大困难是什么？有什么样的感受或经验可以和大家分享的吗？

CarbonData：CarbonData团队大多数人都有参与Apache Hadoop、Spark等社区开发的经验，我们对社区流程和工作方式都很熟悉。最大的困难是进入孵化器阶段，去说服Apache社区接纳大数据生态新的高性能数据格式CarbonData。我们通过5月份在美国奥斯丁的开源盛会OSCON上，做CarbonData技术主题演讲和现场DEMO演示，展示了CarbonData优秀的架构和良好的性能效果。

InfoQ：您们是一个团队吗？如何保证您们团队的优秀成长？

CarbonData：CarbonData团队是一个全球化的（工程师来自中国、美国、印度）团队，这种全球化工作模式的经验积累，让我们能快速的适应Apache开源社区工作模式。

采访嘉宾：Apache CarbonData的PMC、Committers李昆、陈亮。

FlameGraph

火焰图 ，简单通过x轴横条宽度来度量时间指标，y轴代表线程栈的层次，简单明了， 容易找出具体的可有化点，非常方便，当然前提是我们通过profiler工具获取到profiler 数据。

make BITS=64 all

-agentpath:path/to/liblagent.so[:file=name]

在技术方面，我自己热衷于 Open Source，写了很多 Open Source 的东西，擅长的是 Infrastructure 领域。Infrastructure 领域现在范围很广，比如说很典型的分布式 Scheduler、Mesos、Kubernetes，另外它和 Microservices 所结合的东西也特别多。Infrastructure 领域还有比如 Database 有分 AP（分析型）和 TP（事务型），比如说很典型的大家知道的 Spark、Greenplum、Apache Phoenix 等等，这些都属于在 AP 的，它们也会去尝试支持有限的 TP。另外，还有一个比较有意思的就是 Kudu——Cloudera Open Source 的那个项目，它的目标很有意思：我不做最强的 AP 系统，也不做最强的 TP 系统，我选择一个相对折中的方案。从文化哲学上看，它比较符合中国的中庸思想。

另外，我先后创建了 Codis、TiDB。去年12月份创建了 TiKV 这个 project，TiKV 在所有的 rust 项目里目前排名前三。

首先我们聊聊 Database 的历史，在已经有这么多种数据库的背景下我们为什么要创建另外一个数据库；以及说一下现在方案遇到的困境，说一下 Google Spanner 和 F1、TiKV 和 TiDB，说一下架构的事情，在这里我们会重点聊一下 TiKV。因为我们产品的很多特性是 TiKV 提供的，比如说跨数据中心的复制、Transaction、auto-scale。

接下来聊一下为什么 TiKV 用 Raft 能实现所有这些重要的特性，以及 scale、MVCC 和事务模型。东西非常多，我今天不太可能把里面的技术细节都描述得特别细，因为几乎每一个话题都可以找到一篇或者是多篇论文，所以详细的技术问题大家可以单独来找我聊。

后面再说一下我们现在遇到的窘境，就是大家常规遇到的分布式方案有哪些问题，比如 MySQL Sharding。我们创建了无数 MySQL Proxy，比如官方的 MySQL proxy、Youtube 的 Vitess、淘宝的 Cobar、TDDL以及基于 Cobar 的 MyCAT、金山的 Kingshard、360 的 Atlas、京东的 JProxy，我在豌豆荚也写了一个。可以说，随便一个大公司都会造一个 MySQL Sharding 的方案。

为什么我们要创建另外一个数据库？

昨天晚上我还跟一个同学聊到，基于 MySQL 的方案它的天花板在哪里，它的天花板特别明显。有一个思路是能不能通过 MySQL 的 server 把 InnoDB 变成一个分布式数据库，听起来这个方案很完美，但是很快就会遇到天花板。因为 MySQL 生成的执行计划是个单机的，它认为整个计划的 cost 也是单机的，我读取一行和读取下一行之间的开销是很小的，比如迭代 next row 可以立刻拿到下一行。实际上在一个分布式系统里面，这是不一定的。

另外，你把数据都拿回来计算这个太慢了，很多时候我们需要把我们的 expression 或者计算过程等等运算推下去，向上返回一个最终的计算结果，这个一定要用分布式的 plan，前面控制执行计划的节点，它必须要理解下面是分布式的东西，才能生成最好的 plan，这样才能实现最高的执行效率。

比如说你做一个 sum，你是一条条拿回来加，还是让一堆机器一起算，最后给我一个结果。 例如我有 100 亿条数据分布在 10 台机器上，并行在这 10台机器我可能只拿到 10 个结果，如果把所有的数据每一条都拿回来，这就太慢了，完全丧失了分布式的价值。聊到 MySQL 想实现分布式，另外一个实现分布式的方案就是 Proxy。但是 Proxy 本身的天花板在那里，就是它不支持分布式的 transaction，它不支持跨节点的 join，它无法理解复杂的 plan，一个复杂的 plan 打到 Proxy 上面，Proxy 就傻了，我到底应该往哪一个节点上转发呢，如果我涉及到 subquery sql 怎么办？所以这个天花板是瞬间会到，在传统模型下面的修改，很快会达不到我们的要求。

另外一个很重要的是，MySQL 支持的复制方式是半同步或者是异步，但是半同步可以降级成异步，也就是说任何时候数据出了问题你不敢切换，因为有可能是异步复制，有一部分数据还没有同步过来，这时候切换数据就不一致了。前一阵子出现过某公司突然不能支付了这种事件，今年有很多这种类似的 case，所以微博上大家都在说“说好的异地多活呢？”……

为什么传统的方案在这上面解决起来特别的困难，天花板马上到了，基本上不可能解决这个问题。另外是多数据中心的复制和数据中心的容灾，MySQL 在这上面是做不好的。

在前面三十年基本上是关系数据库的时代，那个时代创建了很多伟大的公司，比如说 IBM、Oracle、微软也有自己的数据库，早期还有一个公司叫 Sybase，有一部分特别老的程序员同学在当年的教程里面还可以找到这些东西，但是现在基本上看不到了。

另外是 NoSQL。NoSQL 也是一度非常火，像 Cassandra、MongoDB 等等，这些都属于在互联网快速发展的时候创建这些能够 scale 的方案，但 Redis scale 出来比较晚，所以很多时候大家把 Redis 当成一个 Cache，现在慢慢大家把它当成存储不那么重要的数据的数据库。因为它有了 scale 支持以后，大家会把更多的数据放在里面。

然后到了 2015，严格来讲是到 2014 年到 2015 年之间，Raft 论文发表以后，真正的 NewSQL 的理论基础终于完成了。我觉得 NewSQL 这个理论基础，最重要的划时代的几篇论文，一个是谷歌的 Spanner，是在 2013 年初发布的；再就是 Raft 是在 2014 年上半年发布的。这几篇相当于打下了分布式数据库 NewSQL 的理论基础，这个模型是非常重要的，如果没有模型在上面是堆不起来东西的。说到现在，大家可能对于模型还是可以理解的，但是对于它的实现难度很难想象。

前面我大概提到了我们为什么需要另外一个数据库，说到 Scalability 数据的伸缩，然后我们讲到需要 SQL，比如你给我一个纯粹的 key-velue 系统的 API，比如我要查找年龄在 10 岁到 20 岁之间的 email 要满足一个什么要求的。如果只有 KV 的 API 这是会写死人的，要写很多代码，但是实际上用 SQL 写一句话就可以了，而且 SQL 的优化器对整个数据的分布是知道的，它可以很快理解你这个 SQL，然后会得到一个最优的 plan，他得到这个最优的 plan 基本上等价于一个真正理解 KV 每一步操作的人写出来的程序。通常情况下，SQL 的优化器是为了更加了解或者做出更好的选择。

另外一个就是 ACID 的事务，这是传统数据库必须要提供的基础。以前你不提供 ACID 就不能叫数据库，但是近些年大家写一个内存的 map 也可以叫自己是数据库。大家写一个 append-only 文件，我们也可以叫只读数据库，数据库的概念比以前极大的泛化了。

另外就是高可用和自动恢复，他们的概念是什么呢？有些人会有一些误解，因为今天还有朋友在现场问到，出了故障，比如说一个机房挂掉以后我应该怎么做切换，怎么操作。这个实际上相当于还是上一代的概念，还需要人去干预，这种不算是高可用。

未来的高可用一定是系统出了问题马上可以自动恢复，马上可以变成可用。比如说一个机房挂掉了，十秒钟不能支付，十秒钟之后系统自动恢复了变得可以支付，即使这个数据中心再也不起来我整个系统仍然是可以支付的。Auto-Failover 的重要性就在这里。大家不希望在睡觉的时候被一个报警给拉起来，我相信大家以后具备这样一个能力，5 分钟以内的报警不用理会，挂掉一个机房，又挂掉一个机房，这种连续报警才会理。我们内部开玩笑说，希望大家都能睡个好觉，很重要的事情就是这个。

说完应用层的事情，现在很有很多业务，在应用层自己去分片，比如说我按照 user ID在代码里面分片，还有一部分是更高级一点我会用到一致性哈希。问题在于它的复杂度，到一定程度之后我自动的分库，自动的分表，我觉得下一代数据库是不需要理解这些东西的，不需要了解什么叫做分库，不需要了解什么叫做分表，因为系统是全部自动搞定的。同时复杂度，如果一个应用不支持事务，那么在应用层去做，通常的做法是引入一个外部队列，引入大量的程序机制和状态转换，A 状态的时候允许转换到 B 状态，B 状态允许转换到 C 状态。

举一个简单的例子，比如说在京东上买东西，先下订单，支付状态之后这个商品才能出库，如果不是支付状态一定不能出库，每一步都有严格的流程。

Google Spanner / F1

说一下 Google 的 Spanner 和 F1，这是我非常喜欢的论文，也是我最近几年看过很多遍的论文。 Google Spanner 已经强大到什么程度呢？Google Spanner 是全球分布的数据库，在国内目前普遍做法叫做同城两地三中心，它们的差别是什么呢？以 Google 的数据来讲，谷歌比较高的级别是他们有 7 个副本，通常是美国保存 3 个副本，再在另外 2 个国家可以保存 2 个副本，这样的好处是万一美国两个数据中心出了问题，那整个系统还能继续可用，这个概念就是比如美国 3 个副本全挂了，整个数据都还在，这个数据安全级别比很多国家的安全级别还要高，这是 Google 目前做到的，这是全球分布的好处。

现在国内主流的做法是两地三中心，但现在基本上都不能自动切换。大家可以看到很多号称实现了两地三中心或者异地多活，但是一出现问题都说不好意思这段时间我不能提供服务了。大家无数次的见到这种 case， 我就不列举了。

Spanner 现在也提供一部分 SQL 特性。在以前，大部分 SQL 特性是在 F1 里面提供的，现在 Spanner 也在逐步丰富它的功能，Google 是全球第一个做到这个规模或者是做到这个级别的数据库。事务支持里面 Google 有点黑科技（其实也没有那么黑），就是它有GPS 时钟和原子钟。大家知道在分布式系统里面，比如说数千台机器，两个事务启动先后顺序，这个顺序怎么界定(事务外部一致性)。这个时候 Google 内部使用了 GPS 时钟和原子钟，正常情况下它会使用一个GPS 时钟的一个集群，就是说我拿的一个时间戳，并不是从一个 GPS 上来拿的时间戳，因为大家知道所有的硬件都会有误差。如果这时候我从一个上拿到的 GPS 本身有点问题，那么你拿到的这个时钟是不精确的。而 Google 它实际上是在一批 GPS 时钟上去拿了能够满足 majority 的精度，再用时间的算法，得到一个比较精确的时间。大家知道 GPS 也不太安全，因为它是美国军方的，对于 Google 来讲要实现比国家安全级别更高的数据库，而 GPS 是可能受到干扰的，因为 GPS 信号是可以调整的，这在军事用途上面很典型的，大家知道导弹的制导需要依赖 GPS，如果调整了 GPS 精度，那么导弹精度就废了。所以他们还用原子钟去校正 GPS，如果 GPS 突然跳跃了，原子钟上是可以检测到 GPS 跳跃的，这部分相对有一点黑科技，但是从原理上来讲还是比较简单，比较好理解的。

最开始它 Spanner 最大的用户就是 Google 的 Adwords，这是 Google 最赚钱的业务，Google 就是靠广告生存的，我们一直觉得 Google 是科技公司，但是他的钱是从广告那来的，所以一定程度来讲 Google 是一个广告公司。Google 内部的方向先有了 Big table ，然后有了 MegaStore ，MegaStore 的下一代是 Spanner ，F1 是在 Spanner 上面构建的。

TiDB and TiKV

TiKV 和 TiDB 基本上对应 Google Spanner 和 Google F1，用 Open Source 方式重建。目前这两个项目都开放在 GitHub 上面，两个项目都比较火爆，TiDB 是更早一点开源的， 目前 TiDB 在 GitHub 上 有 4300 多个 Star，每天都在增长。

另外，对于现在的社会来讲，我们觉得 Infrastructure 领域闭源的东西是没有任何生存机会的。没有任何一家公司，愿意把自己的身家性命压在一个闭源的项目上。举一个很典型的例子，在美国有一个数据库叫 FoundationDB，去年被苹果收购了。FoundationDB 之前和用户签的合约都是一年的合约。比如说，我给你服务周期是一年，现在我被另外一个公司收购了，我今年服务到期之后，我是满足合约的。但是其他公司再也不能找它服务了，因为它现在不叫 FoundationDB 了，它叫 Apple了，你不能找 Apple 给你提供一个 Enterprise service。

TiDB 和 TiKV 为什么是两个项目，因为它和 Google 的内部架构对比差不多是这样的：TiKV 对应的是 Spanner，TiDB 对应的是 F1 。F1 里面更强调上层的分布式的 SQL 层到底怎么做，分布式的 Plan 应该怎么做，分布式的 Plan 应该怎么去做优化。同时 TiDB 有一点做的比较好的是，它兼容了 MySQL 协议，当你出现了一个新型的数据库的时候，用户使用它是有成本的。大家都知道作为开发很讨厌的一个事情就是，我要每个语言都写一个 Driver，比如说你要支持 C++、你要支持 Java、你要支持 Go 等等，这个太累了，而且用户还得改他的程序，所以我们选择了一个更加好的东西兼容 MySQL 协议，让用户可以不用改。一会我会用一个视频来演示一下，为什么一行代码不改就可以用，用户就能体会到 TiDB 带来的所有的好处。

这个图实际上是整个协议栈或者是整个软件栈的实现。大家可以看到整个系统是高度分层的，从最底下开始是 RocksDB ，然后再上面用 Raft 构建一层可以被复制的 RocksDB ，在这一层的时候它还没有 Transaction，但是整个系统现在的状态是所有写入的数据一定要保证它复制到了足够多的副本。也就是说只要我写进来的数据一定有足够多的副本去 cover 它，这样才比较安全，在一个比较安全的 Key-value store 上面， 再去构建它的多版本，再去构建它的分布式事务，然后在分布式事务构建完成之后，就可以轻松的加上 SQL 层，再轻松的加上MySQL 协议的支持。然后，这两天我比较好奇，自己写了 MongoDB 协议的支持，然后我们可以用 MongoDB 的客户端来玩，就是说协议这一层是高度可插拔的。TiDB 上可以在上面构建一个 MongoDB 的协议，相当于这个是构建一个 SQL 的协议，可以构建一个 NoSQL 的协议。这一点主要是用来验证 TiKV 在模型上面的支持能力。

这是整个 TiKV 的架构图，从这个看来，整个集群里面有很多 Node，比如这里画了四个 Node ，分别对应了四个机器。每一个 Node 上可以有多个 Store，每个 Store 里面又会有很多小的 Region，就是说一小片数据，就是一个 Region 。从全局来看所有的数据被划分成很多小片，每个小片默认配置是 64M，它已经足够小，可以很轻松的从一个节点移到另外一个节点，Region 1 有三个副本，它分别在 Node1、Node 2 和 Node4 上面， 类似的Region 2，Region 3 也是有三个副本。每个 Region 的所有副本组成一个 Raft Group，整个系统可以看到很多这样的 Raft groups。

Raft 细节我不展开了，大家有兴趣可以找我私聊或者看一下相应的资料。

因为整个系统里面我们可以看到上一张图里面有很多 Raft group 给我们，不同 Raft group 之间的通讯都是有开销的。所以我们有一个类似于 MySQL 的 group commit 机制 ，你发消息的时候实际上可以 share 同一个 connection ， 然后 pipeline + batch 发送，很大程度上可以省掉大量 syscall 的开销。

另外，其实在一定程度上后面我们在支持压缩的时候，也有非常大的帮助，就是可以减少数据的传输。对于整个系统而言，可能有数百万的 Region，它的大小可以调整，比如说 64M、128M、256M，这个实际上依赖于整个系统里面当前的状况。

比如说我们曾经在有一个用户的机房里面做过测试，这个测试有一个香港机房和新加坡的机房。结果我们在做复制的时候，新加坡的机房大于 256M 就复制不过去，因为机房很不稳定，必须要保证数据切的足够小，这样才能复制过去。

如果一个 Region 太大以后我们会自动做 SPLIT，这是非常好玩的过程，有点像细胞的分裂。

然后 TiKV 的 Raft 实现，是从 etcd 里面 port 过来的，为什么要从 etcd 里面 port 过来呢？首先 TiKV 的 Raft 实现是用 Rust 写的。作为第一个做到生产级别的 Raft 实现，所以我们从 etcd 里面把它用 Go 语言写的 port 到这边。

这个是 Raft 官网上面列出来的 TiKV在里面的状态，大家可以看到 TiKV 把所有 Raft 的 feature 都实现了。 比如说 Leader Election、Membership Changes，这个是非常重要的，整个系统的 scale 过程高度依赖 Membership Changes，后面我用一个图来讲这个过程。后面这个是 Log Compaction，这个用户不太关心。

这是很典型的细胞分裂的图，实际上 Region 的分裂过程和这个是类似的。

我们看一下扩容是怎么做的。

比如说以现在的系统假设，我们刚开始说只有三个节点，有 Region1 分别是在 1 、2、4，我用虚线连接起来代表它是一个 Raft group ，大家可以看到整个系统里面有三个 Raft group ，在每一个 Node 上面数据的分布是比较均匀的，在这个假设每一个 Region 是 64M ，相当于只有一个 Node 上面负载比其他的稍微大一点点。

一个在线视频默认我们都是推荐 3 个副本或者 5 个副本的配置。Raft 本身有一个特点，如果一个 leader down 掉之后，其它的节点会选一个新的 leader ，那么这个新的 leader 会把它还没有 commit 但已经 reply 过去的 log 做一个 commit ，然后会再做 apply ，这个有点偏 Raft 协议，细节我不讲了。

复制数据的小的 Region，它实际上是跨多个数据中心做的复制。这里面最重要的一点是永远不丢失数据，无论如何我保证我的复制一定是复制到 majority ，任何时候我只要对外提供服务，允许外面写入数据一定要复制到 majority 。很重要的一点就是恢复的过程一定要是自动化的，我前面已经强调过，如果不能自动化恢复，那么中间的宕机时间或者对外不可服务的时间，便不是由整个系统决定的，这是相对回到了几十年前的状态。

MVCC

MVCC 我稍微仔细讲一下这一块。MVCC 的好处，它很好支持 Lock-free 的 snapshot read ，一会儿我有一个图会展示 MVCC 是怎么做的。isolation level 就不讲了， MySQL 里面的级别是可以调的，我们的 TiKV 有 SI，还有 SI+lock，默认是支持 SI 的这种隔离级别，然后你写一个 select for update 语句，这个会自动的调整到 SI 加上 lock 这个隔离级别。这个隔离级别基本上和 SSI 是一致的。还有一个就是 GC 的问题，如果你的系统里面的数据产生了很多版本，你需要把这个比较老的数据给 GC 掉，比如说正常情况下我们是不删除数据的， 你写入一行，然后再写入一行，不断去 update 同一行的时候，每一次 update 会产生新的版本，新的版本就会在系统里存在，所以我们需要一个 GC 的模块把比较老的数据给 GC 掉，实际上这个 GC 不是 Go 里面的GC，不是 Java 的 GC，而是数据的 GC。

这是一个数据版本，大家可以看到我们的数据分成两块，一个是 meta，一个是 data。meta 相对于描述我的数据当前有多少个版本。大家可以看到绿色的部分，比如说我们的 meta key 是 A ，keyA 有三个版本，是 A1 、A2、A3，我们把 key 自己和 version 拼到一起。那我们用 A1、A2、A3 分别描述 A 的三个版本，那么就是 version 1/2/3。meta 里面描述，就是我的整个 key 相对应哪个版本，我想找到那个版本。比如说我现在要读取 key A 的版本10，但显然现在版本 10 是没有的，那么小于版本 10 最大的版本是 3，所以这时我就能读取到 3，这是它的隔离级别决定的。关于 data，我刚才已经讲过了。

分布式事务模型

接下来是分布式事务模型，其实是基于 Google Percolator，这是 Google 在 2006 发表的一篇论文，是 Google 在做内部增量处理的时候发现了这个方法，本质上还是二阶段提交的。这使用的是一个乐观锁，比如说我提供一个 transaction ，我去改一个东西，改的时候是发布在本地的，并没有马上 commit 到数据存储那一端，这个模型就是说，我修改的东西我马上去 Lock 住，这个基本就是一个悲观锁。但如果到最后一刻我才提交出去，那么锁住的这一小段的时间，这个时候实现的是乐观锁。乐观锁的好处就是当你冲突很小的时候可以得到非常好的性能，因为冲突特别小，所以我本地修改通常都是有效的，所以我不需要去 Lock ，不需要去 roll back 。本质上分布式事务就是 2PC (两阶段提交) 或者是 2+x PC，基本上没有 1PC，除非你在别人的级别上做弱化。比如说我允许你读到当前最新的版本，也允许你读到前面的版本，书里面把这个叫做幻读。如果你调到这个程度是比较容易做 1PC 的，这个实际上还是依赖用户设定的隔离级别的，如果用户需要更高的隔离级别，这个 1PC就不太好做了。

这是一个路由，正常来讲，大家可能会好奇一个 SQL 语句怎么最后会落到存储层，然后能很好的运行，最后怎么能映射到 KV 上面，又怎么能路由到正确的节点，因为整个系统可能有上千个节点，你怎么能正确路由到那一个的节点。我们在 TiDB 有一个 TiKV driver ， 另外 TiKV 对外使用的是 Google Protocol Buffer 来作为通讯的编码格式。

Placement Driver

来说一下 Placement Driver 。Placement Driver 是什么呢？整个系统里面有一个节点，它会时刻知道现在整个系统的状态。比如说每个机器的负载，每个机器的容量，是否有新加的机器，新加机器的容量到底是怎么样的，是不是可以把一部分数据挪过去，是不是也是一样下线， 如果一个节点在十分钟之内无法被其他节点探测到，我认为它已经挂了，不管它实际上是不是真的挂了，但是我也认为它挂了。因为这个时候是有风险的，如果这个机器万一真的挂了，意味着你现在机器的副本数只有两个，有一部分数据的副本数只有两个。那么现在你必须马上要在系统里面重新选一台机器出来，它上面有足够的空间，让我现在只有两个副本的数据重新再做一份新的复制，系统始终维持在三个副本。整个系统里面如果机器挂掉了，副本数少了，这个时候应该会被自动发现，马上补充新的副本，这样会维持整个系统的副本数。这是很重要的 ，为了避免数据丢失，必须维持足够的副本数，因为副本数每少一个，你的风险就会再增加。这就是 Placement Driver 做的事情。

同时，Placement Driver 还会根据性能负载，不断去 move 这个 data 。比如说你这边负载已经很高了，一个磁盘假设有 100G，现在已经用了 80G，另外一个机器上也是 100G，但是他只用了 20G，所以这上面还可以有几十 G 的数据，比如 40G 的数据，你可以 move 过去，这样可以保证系统有很好的负载，不会出现一个磁盘巨忙无比，数据已经多的装不下了，另外一个上面还没有东西，这是 Placement Driver 要做的东西。

Raft 协议还提供一个很高级的特性叫 leader transfer。leader transfer 就是说在我不移动数据的时候，我把我的 leadership 给你，相当于从这个角度来讲，我把流量分给你，因为我是 leader，所以数据会到我这来，但我现在把 leader给你，我让你来当 leader，原来打给我的请求会被打给你，这样我的负载就降下来。这就可以很好的动态调整整个系统的负载，同时又不搬移数据。不搬移数据的好处就是，不会形成一个抖动。

MySQL Sharding

MySQL Sharding 我前面已经提到了它的各种天花板，MySQL Sharding 的方案很典型的就是解决基本问题以后，业务稍微复杂一点，你在 sharding 这一层根本搞不定。它永远需要一个 sharding key，你必须要告诉我的 proxy，我的数据要到哪里找，对用户来说是极不友好的，比如我现在是一个单机的，现在我要切入到一个分布式的环境，这时我必须要改我的代码，我必须要知道我这个 key ，我的 row 应该往哪里 Sharding。如果是用 ORM ，这个基本上就没法做这个事情了。有很多 ORM 它本身假设我后面只有一个 MySQL。但 TiDB 就可以很好的支持，因为我所有的角色都是对的，我不需要关注 Sharding 、分库、分表这类的事情。

这里面有一个很重要的问题没有提，我怎么做 DDL。如果这个表非常大的话，比如说我们有一百亿吧，横跨了四台机器，这个时候你要给它做一个新的 Index，就是我要添加一个新的索引，这个时候你必须要不影响任何现有的业务，实际上这是多阶段提交的算法，这个是 Google 和 F1 一起发出来那篇论文。

简单来讲是这样的，先把状态标记成 delete only ，delete only 是什么意思呢？因为在分布式系统里面，所有的系统对于 schema 的视野不是一致的，比如说我现在改了一个值，有一部分人发现这个值被改了，但是还有一部分人还没有开始访问这个，所以根本不知道它被改了。然后在一个分布系统里，你也不可能实时通知到所有人在同一时刻发现它改变了。比如说从有索引到没有索引，你不能一步切过去，因为有的人认为它有索引，所以他给它建了一个索引，但是另外一个机器他认为它没有索引，所以他就把数据给删了，索引就留在里面了。这样遇到一个问题，我通过索引找的时候告诉我有， 实际数据却没有了，这个时候一致性出了问题。比如说我 count 一个 email 等于多少的，我通过 email 建了一个索引，我认为它是在，但是 UID 再转过去的时候可能已经不存在了。

比如说我先标记成 delete only，我删除它的时候不管它现在有没有索引，我都会尝试删除索引，所以我的数据是干净的。如果我删除掉的话，我不管结果是什么样的，我尝试去删一下，可能这个索引还没 build 出来，但是我仍然删除，如果数据没有了，索引一定没有了，所以这可以很好的保持它的一致性。后面再类似于前面，先标记成 write only 这种方式，连续再迭代这个状态，就可以迭代到一个最终可以对外公开的状态。比如说当我迭代到一定程度的时候，我可以从后台 build index ，比如说我一百亿，正在操作的 index 会马上 build，但是还有很多没有 build index ，这个时候后台不断的跑 map-reduce 去 build index ，直到整个都 build 完成之后，再对外 public ，就是说我这个索引已经可用了，你可以直接拿索引来找，这个是非常经典的。在这个 Online，Asynchronous Schema Change in F1 paper之前，大家都不知道这事该怎么做。

Proxy Sharding 的方案不支持分布式事务，更不用说跨数据中心的一致性事务了。 TiKV 很好的支持 transaction，刚才提到的 Raft 除了增加副本之外，还有 leader transfer，这是一个传统的方案都无法提供的特性。以及它带来的好处，当我瞬间平衡整个系统负载的时候，对外是透明的， 做 leader transfer 的时候并不需要移动数据，只是个简单的 leader transfer 消息。

然后说一下如果大家想参与我们项目的话是怎样的过程，因为整个系统是完全开源的，如果大家想参与其中任何一部分都可以，比如说我想参与到分布式 KV，可以直接贡献到 TiKV。TiKV 需要写 Rust，如果大家对这块特别有激情可以体验写 Rust 的感觉 。

TiDB 是用 Go 写的，Go 在中国的群众基础是非常多的，目前也有很多人在贡献。整个 TiDB 和TiKV 是高度协作的项目，因为 TiDB 目前还用到了 etcd ，我们在和 CoreOS 在密切的合作，也特别感谢 CoreOS 帮我们做了很多的支持，我们也为 CoreOS 的 etcd 提了一些 patch。同时，TiKV 使用 RocksDB ，所以我们也为 RocksDB 提了一些 patch 和 test，我们也非常感谢 Facebook RocksDB team 对我们项目的支持。

另外一个是 PD，就是我们前面提的 Placement Driver，它负责监控整个系统。这部分的算法比较好玩，大家如果有兴趣的话，可以去自己控制整个集群的调度，它和 Kubernetes 或者是Mesos 的调度算法是不一样的，因为它调度的维度实际上比那个要更多。比如说磁盘的容量，你的 leader 的数量，你的网络当前的使用情况，你的 IO 的负载和 CPU 的负载都可以放进去。同时你还可以让它调度不要跨一个机房里面建多个副本。

编辑推荐：稀土掘金，这是一个针对技术开发者的一个应用，你可以在掘金上获取最新最优质的技术干货，不仅仅是Android知识、前端、后端以至于产品和设计都有涉猎，想成为全栈工程师的朋友不要错过！

原文：http://www.csdn.net/article/2015-08-31/2825579 

JSON——大家可能都知道它是几乎所有现代服务器都使用的轻量级数据交换格式。它体量轻，可读性强，通常比老式的、不友好的XML开发起来更加便捷友好。JSON是不依赖于开发语言的数据格式，但是在解析数据并将其转换到如Java对象时，会消耗我们的时间和存储资源。

几天前，Facebook宣布，其Android应用程序大幅提升了数据处理性能。这是由于几乎在全部应用程序中放弃了JSON数据格式，用FlatBuffers取而代之了。阅读这篇文章可以获得关于FlatBuffers的基础知识，学会如何从JSON转换到FlatBuffers。

虽然这东西是非常有前景的，但是乍一看其实现过程不是一下子就能明白的。而且Facebook也没有说得很详细。这就是为什么我要写这篇文章，在其中展示我们是如何使用Flatbuffers开展工作的。

FlatBuffers

总之，FlatBuffers是Google专门为游戏开发而创建的跨平台序列化库，就像Facebook所展示的那样，它在Android平台上遵循快速响应UI的16ms规则。

但是，在把所有数据迁移到FlatBuffers之前，你要确定确实需要这样做。因为，这样做有时对性能的影响是潜移默化的，而且数据安全性要比计算速度上几十毫秒的差异更重要。

什么使得Flatbuffers如此奏效？

• 由于是以二进制形式缓存，访问序列化数据时也无需数据解析过程。即使对于层次化数据也不需要解析。多亏不需要初始化解析器（初始化意味着要建立复杂的字段映射）和解析数据，这些都是需要花费时间的。

• Flatbuffers数据不需要分配比自身使用缓冲区还要多的内存。我们不必像在JSON中那样为解析数据的整个层次分配额外对象。

要获得正宗的数据，就再读一读Facebook上关于FlatBuffers迁移问题的文章，还有Google自己的文档。

实现

本文将介绍在Android应用程序中使用Flatbuffers的最简单方法：

• JSON数据在应用程序之外的某个地方被转换成FlatBuffer格式的文件（例如，将二进制数据以文件的形式提交，还可以从API直接返回FlatBuffer二进制文件）。

• 在flatc (FlatBuffer编译器)的帮助下，手工生成数据模型（Java类）。

• JSON文件存在一定的局限性（不能使用null字段，日期格式也被解析为字符串）。

将来，我们或许会提出更复杂的解决方案。

FlatBuffers编译器

首先，我们需要flatc，即flatbuffers编译器。该编译器可以从Google所属的源代码构建，源代码位于Flatbuffers资源库中。我们下载并克隆它。整个构建过程在FlatBuffers构建文档中都做了描述。如果你是Mac用户的话，需要这样来构建：

1. 在\{extract directory}\build\XcodeFlatBuffers.xcodeproj路径下，打开已下载的源代码。

2. 点击Play按钮或⌘ + R，运行flatc scheme（默认情况下应该是被选中的）。

3. flatc可执行文件就会在项目的根目录下出现。

现在，我们可以使用schema编译器了，该编译器能够把给定的schema（在Java、C#、Python、GO和C++语言中的schema）生成为模型类，还可以把JSON转换成Flatbuffer的二进制文件。

Schema文件

接着，我们必须准备schema文件，该文件定义了要进行序列化和反序列化的数据结构。这个schema将用于flatc创建Java模型，把JSON转换成FlatBuffers的二进制文件。

这里是JSON文件的一部分。

完整版本在这里。这是略微修改后的版本，可以从Github API调用：https://api.github.com/users/google/repos 。

Flatbuffer schema是编写得很好的文档，所以就不深入探讨这个问题了。另外，本文中的schema不会很复杂。我们所要做的仅仅是创建3张表：ReposList, Repo和User，并定义root_type。这是schema的重要组成部分。

完整的schema文件在这里。

FlatBuffers数据文件

真棒，我们现在要做的是把repos_json.json转换成FlatBuffers二进制文件，生成能够以Java风格表示数据的Java模型（此处操作所需的全部文件都在我们的代码库中）：

$ ./flatc -j -b repos_schema.fbs repos_json.json

如果一切顺利，会产生下列文件：

• repos_json.bin（要将重命名它为 repos_flat.bin）

• Repos/Repo.java

• Repos/ReposList.java

• Repos/User.java

Android应用程序

现在来创建示例程序，在实践中来看看Flatbuffers格式是如何起作用的。这是截图：

在UI部分，ProgressBar仅用于显示不恰当的数据处理对用户界面顺畅度的影响。

应用文件看起来是这个样子：app/build.gradle

当然，在本例中不是必须要用Rx或ButterKnife这样的视图注入利器，但是为什么不让应用更细致一些呢？？

我们把repos_flat.bin 和 repos_json.json文件放到res/raw/目录下。RawDataReader是工具类，它帮助我们读取Android应用中的原始文件。

最后，把Repo，ReposList和User这三张表对应的模型类代码放到项目源代码中。

FlatBuffers库

使用Java语言编程过程中，FlatBuffers提供了可以直接处理这种数据格式的库，也这是flatbuffers-java-1.2.0-SNAPSHOT.jar文件。如果你想手工生成该文件，需要下载FlatBuffers源代码，再到目录java/下，用Maven生成该库：

$ mvn install

现在将.jar文件放到Android项目的app/libs/目录下。

好了，当务之急是实现MainActivity类，这是完整源代码。

我们最为关注的两个方法是：

• parseReposListJson(String reposStr) - 这个方法初始化Gson解析器，并把JSON字符串转换成Java对象。

• loadFlatBuffer(byte[] bytes)  - 这个方法将字节（repos_flat.bin文件）转换成Java对象。

使用FlatBuffers的结果

现在让我们把JSON和FlatBuffers在加载时间和资源消耗方面的差异形象化。测试是在带有Android M（beta版）的Nexus 5上进行的。

加载时间

测量的过程是将其他文件转换为Java源文件，对所有（90个）元素进行迭代。

• 使用JSON：JSON文件（大小：478kB）平均加载时间200ms（时间区间：180ms～250ms）；

• 使用FlatBuffers：FlatBuffers二进制文件（大小：352kB）平均加载时间5ms（时间区间：3ms～10ms）。

记得16ms规则吗？我们在UI线程中调用这些方法的原因就是要看看在这种情况下界面表现如何：

JSON数据加载效果：

FlatBuffers数据加载效果：

看出区别了吗？JSON数据的加载过程中， ProgressBar停顿了一会，界面不是那么顺畅（加载时间超过了16ms）。

内存分配、CPU等资源

还有什么想要测量的吗？也许应该测量一下Android Studio 1.3，还有那些新特性。例如，内存分配跟踪器（Allocation Tracker），内存状态查看器（Memory Viewer）和方法跟踪器（Method Tracer）。

源代码

这里所讲解项目的完整源代码都在Github代码库中。你不需要接触整个FlatBuffers项目，所需的内容全都在flatbuffers/目录下。

（ 翻译/张挥戈  友情审校/白云鹏）

文章来源：froger_mcs dev blog

作者简介：

Miroslaw Stanek，Azimo Money Transfer公司移动项目负责人，Android和iOS平台程序员，视频游戏玩家，冰雪运动爱好者。个人博客：http://frogermcs.github.io。

你可能会问，既然我们已经有很标准的JSON以及转换库比如GSON和Jackson，为什么还要使用新的工具呢？

不妨先试一下FlatBuffers，然后你就会发现它比JSON快得多。

FlatBuffers是什么？

FlatBuffers是一个高效的跨平台序列化类库，可以在C++、C#、C、Go、Java、JavaScript、PHP和Python中使用。是Google开发的，是为了应用在游戏开发，以及其他注重性能的应用上。

为什么要使用FlatBuffers？

• 不需要解析/拆包就可以访问序列化数据 — FlatBuffers与其他库不同之处就在于它使用二进制缓冲文件来表示层次数据，这样它们就可以被直接访问而不需解析与拆包，同时还支持数据结构进化（前进、后退兼容性）。

• 内存高效速度快 — 访问数据时只需要访问内存中的缓冲区。它不需要多余的内存分配（至少在C++是这样，其他语言中可能会有变动）。FlatBuffers还适合配合 mmap或数据流使用，只需要缓冲区的一部分存储在内存中。访问时速度接近原结构访问，只有一点延迟（一种虚函数表vtable），是为了允许格式升级以 及可选字段。FlatBuffers适合那些花费了大量时间和空间（内存分配）来访问和构建序列化数据的项目，比如游戏以及其他对表现敏感的应用。可以参 考这里的基准。

• 灵活 — 由于有可选字段，你不但有很强的升级和回退兼容性（对于历史悠久的游戏尤其重要，不用为了每个版本升级所有数据），在选择要存储哪些数据以及设计数据结构时也很自由。

• 轻量的code footprint — FlatBuffers只需要很少量的生成代码，以及一个表示最小依赖的很小的头文件，很容易集成。细节上可以看上面的基准页。

• 强类型 — 编译时报错，而不需要自己写重复的容易出错的运行时检查。它可以自动生成有用的代码。

• 使用方便 — 生成的C++代码允许精简访问与构建代码。还有可选的用于实现图表解析、类似JSON的运行时字符串展示等功能的方法。（后者比JSON解析库更快，内存效率更高）

• 代码跨平台且没有依赖 — C++代码可以运行在任何近代的gcc/clang和VS2010上。同时还有用于测试和范例的构建文件（Android中.mk文件，其他平台是cmake文件）。

都有谁使用FlatBuffers?

• BobbleApp，印度第一贴图App。我们在BobbleApp中使用FlatBuffers后App的性能明显增强。

• Cocos2d-x，第一开源移动游戏引擎，使用FlatBuffers来序列化所有的游戏数据。

• Facebook使用FlatBuffers在Android App中进行客户端服务端的沟通。他们写了一篇文章来描述FlatBuffers是如何加速加载内容的。

• Google的Fun Propulsion Labs在他们所有的库和游戏中大量使用FlatBuffers。

App性能有多大提高？

• 解析速度 解析一个20KB的JSON流（这差不多是BobbleApp的返回大小）需要35ms，超过了UI刷新间隔也就是16.6ms。如果解析JSON的话，我们就在滑动时就会因为要从磁盘加载缓存而导致掉帧（视觉上的卡顿）。

• 解析器初始化 一个JSON解析器需要先构建字段映射再进行解析，这会花100ms到200ms，很明显的拖缓App启动时间。

• 垃圾回收 在解析JSON时创建了很多小对象，在我们的试验中，解析20kb的JSON流时，要分配大约100kb的瞬时存储，对Java内存回收造成很大压力。

FlatBuffers vs JSON

我尝试使用FlatBuffers和JSON解析4mb的JSON文件。

FlatBuffers花了1-5ms，JSON花了大约2000ms。在使用FlatBuffers期间Android App中没有GC，而在使用JSON时发生了很多次GC。在使用JSON时UI完全卡住，所以真实使用时只能在后台线程进行解析。

如何使用FlatBuffer呢？

我在我的GitHub中写了一个示例，里面手把手教你如何使用FlatBuffer。

原文链接:https://medium.freecodecamp.com/why-consider-flatbuffer-over-json-2e4aa8d4ed07

稿源：infoQ  作者Amit Shekhar  译者程大治

from:http://www.jdon.com/46111

本文来自Pivotal，分析了中国铁路总公司12306这个世界上最大的铁路系统的火车票预订系统。

在这个星球上人类最大的年度运动大概算是中国农历新年，又称春节。有3488万人次通过航空和235万人次通过铁路踏上他们的旅途。从历史上看，铁路旅行意味着排长龙队伍买票，中国铁路总公司（CRC）现在开始在网上卖火车票，提供比车站售票处或通过电话购买更方便的方法。

随着越来越多人的使用车票预订系统，12306铁路订票系统打破了其传统的RDBMS关系数据库系统，需要重新开始了一个新的项目，以改善原有系统性能和可伸缩性的问题，能够承受像春节度假旅游期间的尖峰的压力。目前该网站成为中国最受欢迎网站的之一。在这样严苛的访问条件下，系统出现以下很差用户体验：使用中断，性能差，预订错误，支付失败，票务确认出现问题等等。

中国铁道科学研究院的副主任朱剑圣首先解决性能问题，早在2011年，朱博士确保新系统解决基于下面两个性能瓶颈：

1.关系型数据库超负载，以至于不能处理传入的请求，无论是规模扩展性还是可靠性，都不能满足SLA要求的水平。 

2.UNIX服务器的计算能力不足以解决容量需求。

朱博士说：“传统关系型数据库和大型机的计算模式并不具有扩展性，系统不能基于内存扩展跨多个节点上运行。我们的网站证明了这一点，而试图扩展我们的遗留系统将变得非常昂贵”。

使用In-memory内存数据网格解决扩展性和可靠性
朱博士的团队开始寻找新的解决方案，大型机被发现和关系数据库有同样的瓶颈，在内存数据网格(IMDG)领域，他们发现了Pivotal GemFire，在海运货物系统 金融服务，航空，电子商务等多个行业都拥有成功解决最具挑战性的数据问题的良好记录。为了执行评估，朱博士和他的团队选择了国际综合系统公司（IISI）。IISI拥有强大为政府机构工作的跟踪记录，包括在开发交通运输解决方案，迁移遗留系统到云计算架构等方面经历，有与Pivotal GemFire合作经验。他们开始试点，相信了GemFire​​将满足性能，可扩展性和可用性的要求，包括能够在低成本硬件上运行。

IISI创造了一个概念证明和展示了GemFire几个优点​​。售票计算速度提高50到100倍。当负载增加时，响应时间保持10-100毫秒的延迟。他们可以看到，通过增加容量，能实现近乎线性增长的可扩展性和高可用性的能力。项目组在短短两个月内建立了一个试点，四个月后，新的在线系统全面部署，跨越5700火车站。

该小组负责铁路网上预订系统每年增长高达50％。他们的网站每天的平均水平预订250万票。

72台UNIX系统和关系数据库换成了10台初始和10个备份的x86服务器，这是一个更具成本效益的模式，能在内存中处理2TB或一个月的的火车票数据。

朱博士认为：“首先，Pivotal GemFire​​提供了一个在真实的测试环境的证明。然后，在生产环境面对意想不到的尖峰也是成功的，具体采取了一个迭代的方法来部署，克服了一系列大规模的挑战。在最近的2013春运期间，该系统具备了运行稳定的性能和正常运行时间。现在，我们有一个可靠，经济合理的生产体系​​，支持记录容量增长的空间。这个规模实现10-100毫秒的延迟。”

基于高可用性，冗余和故障切换机制上的GemFire​​提供了连续正常运行，它已超出了所有在该领域的CRC校验的指标，并帮助他们维护他们的SLA。

具体PDF下载

剖析Elasticsearch集群系列涵盖了当今最流行的分布式搜索引擎Elasticsearch的底层架构和原型实例。

本文是这个系列的第二篇，我们将讨论Elasticsearch如何处理分布式的三个C((共识(consensus)、并发(concurrency)和一致(consistency))的问题、Elasticsearch分片的内部概念，比如translog(预写日志，WAL(Write Ahead Log))，以及Lucene中的段。

本系列已经得到原文著者Ronak Nathani的授权

在本系列的前一篇中，我们讨论了Elasticsearch的底层存储模型及CRUD（创建、读取、更新和删除）操作的工作原理。在本文中，我将分享Elasticsearch是如何应对分布式系统中的一些基本挑战的，以及分片的内部概念。这其中包括了一些操作方面的事情，Insight Data的工程师们已经在使用Elasticsearch构建的数据平台之上成功地实践并真正理解。我将在本文中主要讲述：

• 共识——裂脑问题及法定票数的重要性
• 并发
• 一致——确保读写一致
• Translog(预写日志)
• Lucene的段

共识——裂脑问题及法定票数的重要性

共识是分布式系统的一项基本挑战。它要求系统中的所有进程/节点必须对给定数据的值/状态达成共识。已经有很多共识算法诸如Raft、Paxos等，从数学上的证明了是行得通的。但是，Elasticsearch却实现了自己的共识系统(zen discovery)，Elasticsearch之父Shay Banon在这篇文章中解释了其中的原因。zen discovery模块包含两个部分：

• Ping: 执行节点使用ping来发现彼此
• 单播(Unicast):该模块包含一个主机名列表，用以控制哪些节点需要ping通

Elasticsearch是端对端的系统，其中的所有节点彼此相连，有一个master节点保持活跃，它会更新和控制集群内的状态和操作。建立一个新的Elasticsearch集群要经过一次选举，选举是ping过程的一部分，在所有符合条件的节点中选取一个master，其他节点将加入这个master节点。ping间隔参数ping_interval的默认值是1秒，ping超时参数ping_timeout的默认值是3秒。因为节点要加入，它们会发送一个请求给master节点，加入超时参数join_timeout的默认值是ping_timeout值的20倍。如果master出现问题，那么群集中的其他节点开始重新ping以启动另一次选举。这个ping的过程还可以帮助一个节点在忽然失去master时，通过其他节点发现master。

注意：默认情况下，client节点和data节点不参与这个选举过程。可以在elasticsearch.yml配置文件中，通过设置discovery.zen.master_election.filter_client属性和discovery.zen.master_election.filter_data属性为false来改变这种默认行为。

故障检测的原理是这样的，master节点会ping所有其他节点，以检查它们是否还活着；然后所有节点ping回去，告诉master他们还活着。

如果使用默认的设置，Elasticsearch有可能遭到裂脑问题的困扰。在网络分区的情况下，一个节点可以认为master死了，然后选自己作为master，这就导致了一个集群内出现多个master。这可能会导致数据丢失，也可能无法正确合并数据。可以按照如下公式，根据有资格参加选举的节点数，设置法定票数属性的值，来避免爆裂的发生。

discovery.zen.minimum_master_nodes = int(# of master eligible nodes/2)+1

这个属性要求法定票数的节点加入新当选的master节点，来完成并获得新master节点接受的master身份。对于确保群集稳定性和在群集大小变化时动态地更新，这个属性是非常重要的。图a和b演示了在网络分区的情况下，设置或不设置minimum_master_nodes属性时，分别发生的现象。

注意：对于一个生产集群来说，建议使用3个节点专门做master，这3个节点将不服务于任何客户端请求，而且在任何给定时间内总是只有1个活跃。

我们已经搞清楚了Elasticsearch中共识的处理，现在让我们来看看它是如何处理并发的。

并发

Elasticsearch是一个分布式系统，支持并发请求。当创建/更新/删除请求到达主分片时，它也会被平行地发送到分片副本上。但是，这些请求到达的顺序可能是乱序的。在这种情况下，Elasticsearch使用乐观并发控制，来确保文档的较新版本不会被旧版本覆盖。

每个被索引的文档都拥有一个版本号，版本号在每次文档变更时递增并应用到文档中。这些版本号用来确保有序接受变更。为了确保在我们的应用中更新不会导致数据丢失，Elasticsearch的API允许我们指定文件的当前版本号，以使变更被接受。如果在请求中指定的版本号比分片上存在的版本号旧，请求失败，这意味着文档已经被另一个进程更新了。如何处理失败的请求，可以在应用层面来控制。Elasticsearch还提供了其他的锁选项，可以通过这篇来阅读。

当我们发送并发请求到Elasticsearch后，接下来面对的问题是——如何保证这些请求的读写一致？现在，还无法清楚回答，Elasticsearch应落在CAP三角形的哪条边上，我不打算在这篇文章里解决这个素来已久的争辩。

但是，我们要一起看下如何使用Elasticsearch实现写读一致。

一致——确保读写一致

对于写操作而言，Elasticsearch支持的一致性级别，与大多数其他的数据库不同，允许预检查，来查看有多少允许写入的可用分片。可选的值有quorum、one和all。默认的设置为quorum，也就是说只有当大多数分片可用时才允许写操作。即使大多数分片可用，还是会因为某种原因发生写入副本失败，在这种情况下，副本被认为故障，分片将在一个不同的节点上重建。

对于读操作而言，新的文档只有在刷新时间间隔之后，才能被搜索到。为了确保搜索请求的返回结果包含文档的最新版本，可设置replication为sync(默认)，这将使操作在主分片和副本碎片都完成后才返回写请求。在这种情况下，搜索请求从任何分片得到的返回结果都包含的是文档的最新版本。即使我们的应用为了更高的索引率而设置了replication=async，我们依然可以为搜索请求设置参数_preference为primary。这样，搜索请求将查询主分片，并确保结果中的文档是最新版本。

我们已经了解了Elasticsearch如何处理共识、并发和一致，让我们来看看分片内部的一些主要概念，正是这些特点让Elasticsearch成为一个分布式搜索引擎。

Translog(预写日志)

因为关系数据库的发展，预写日志(WAL)或者事务日志(translog)的概念早已遍及数据库领域。在发生故障的时候，translog能确保数据的完整性。translog的基本原理是，变更必须在数据实际的改变提交到磁盘上之前，被记录下来并提交。

当新的文档被索引或者旧的文档被更新时，Lucene索引将发生变更，这些变更将被提交到磁盘以持久化。这是一个很昂贵的操作，如果在每个请求之后都被执行。因此，这个操作在多个变更持久化到磁盘时被执行一次。正如我们在上一篇文章中描述的那样，Lucene提交的冲洗(flush)操作默认每30分钟执行一次或者当translog变得太大(默认512MB)时执行。在这样的情况下，有可能失去2个Lucene提交之间的所有变更。为了避免这种问题，Elasticsearch采用了translog。所有索引/删除/更新操作被写入到translog，在每个索引/删除/更新操作执行之后（默认情况下是每5秒），translog会被同步以确保变更被持久化。translog被同步到主分片和副本之后，客户端才会收到写请求的确认。

在两次Lucene提交之间发生硬件故障的情况下，可以通过重放translog来恢复自最后一次Lucene提交前的任何丢失的变更，所有的变更将会被索引所接受。

注意：建议在重启Elasticsearch实例之前显式地执行冲洗translog，这样启动会更快，因为要重放的translog被清空。POST /_all/_flush命令可用于冲洗集群中的所有索引。

使用translog的冲洗操作，在文件系统缓存中的段被提交到磁盘，使索引中的变更持久化。现在让我们来看看Lucene的段。

Lucene的段

Lucene索引是由多个段组成，段本身是一个功能齐全的倒排索引。段是不可变的，允许Lucene将新的文档增量地添加到索引中，而不用从头重建索引。对于每一个搜索请求而言，索引中的所有段都会被搜索，并且每个段会消耗CPU的时钟周、文件句柄和内存。这意味着段的数量越多，搜索性能会越低。

为了解决这个问题，Elasticsearch会合并小段到一个较大的段（如下图所示），提交新的合并段到磁盘，并删除那些旧的小段。

这会在后台自动执行而不中断索引或者搜索。由于段合并会耗尽资源，影响搜索性能，Elasticsearch会节制合并过程，为搜索提供足够的可用资源。

接下来有什么？

从搜索请求角度来说，一个Elasticsearch索引中给定分片内的所有Lucene段都会被搜索，但是，从Elasticsearch集群角度而言，获取所有匹配的文档或者深入有序结果文档是有害的。在本系列的后续文章中我们将揭晓原因，让我们来看一下接下来的主题，内容包括了一些在Elasticsearch中为相关性搜索结果的低延迟所做的权衡。

• Elasticsearch准实时性方面的内容
• 为什么搜索中的深层分页是有害的？
• 搜索相关性计算中的权衡之道

查看原文地址：Anatomy of an Elasticsearch Cluster: Part II

剖析Elasticsearch集群系列涵盖了当今最流行的分布式搜索引擎Elasticsearch的底层架构和原型实例。本文是这个系列的第三篇，我们将讨论Elasticsearch是如何提供近实时搜索并权衡搜索相关性计算的。

本系列已经得到原文著者Ronak Nathani的授权

在本系列的前一篇中，我们讨论了Elastisearch如何解决分布式系统中的一些基本挑战。在本文中，我们将探讨Elasticsearch在近实时搜索及其权衡计算搜索相关性方面的内容，Insight Data的工程师们已经在使用Elasticsearch构建的数据平台之上，对此有所实践。我将在本文中主要讲述：

• 近实时搜索
• 为什么深层分页在分布式搜索中是有害的？
• 计算搜索相关性中的权衡

近实时搜索

虽然Elasticsearch中的变更不能立即可见，它还是提供了一个近实时的搜索引擎。如前一篇中所述，提交Lucene的变更到磁盘是一个代价昂贵的操作。为了避免在文档对查询依然有效的时候，提交变更到磁盘，Elasticsearch在内存缓冲和磁盘之间提供了一个文件系统缓存。内存缓存(默认情况下)每1秒刷新一次，在文件系统缓存中使用倒排索引创建一个新的段。这个段是开放的并对搜索有效。

文件系统缓存可以拥有文件句柄，文件可以是开放的、可读的或者是关闭的，但是它存在于内存之中。因为刷新间隔默认是1秒，变更不能立即可见，所以说是近实时的。因为translog是尚未落盘的变更持久化记录，它能有助于CRUD操作方面的近实时性。对于每次请求来说，在查找相关段之前，任何最近的变更都能从translog搜索到，因此客户端可以访问到所有的近实时变更。

你可以在创建/更新/删除操作后显式地刷新索引，使变更立即可见，但我并不推荐你这样做，因为这样会创建出来非常多的小segment而影响搜索性能。对于每次搜索请求来说，给定Elasticsearch索引分片中的全部Lucene段都会被搜索到，但是，对于Elasticsearch来说，获取全部匹配的文档或者很深结果页的文档是有害的。让我们来一起看看为什么是这样。

为什么深层分页在分布式搜索中是有害的？

当我们的一次搜索请求在Elasticsearch中匹配了很多的文档，默认情况下，返回的第一页只包含前10条结果。search API提供了from和size参数，用于指定对于匹配搜索的全部文档，要返回多深的结果。举例来说，如果我们想看到匹配搜索的文档中，排名为50到60之间的文档，可以设置from=50，size=10。当每个分片接收到这个搜索请求后，各自会创建一个容量为from+size的优先队列来存储该分片上的搜索结果，然后将结果返回给协调节点。

如果我们想看到排名为50,000到50,010的结果，那么每个分片要创建一个容量为50,010的优先队列来存储结果，而协调节点要在内存中对数量为shards * 50,010的结果进行排序。这个级别的分页有可能得到结果，也有可以无法实现，这取决于我们的硬件资源，但是这足以说明，我们得非常小心地使用深分页，因为这非常容易使我们的集群崩溃。

一种获取全部匹配结果文档的可行性方案是使用scroll API，它的角色更像关系数据库中的游标。使用scroll API无法进行排序，每个分片只要有匹配搜索的文档，就会持续发送结果给协调节点。

获取大量文档的时候，对结果进行得分排序会非常昂贵。并且由于Elasticsearch是分布式系统，为每个文档计算搜索相关性得分是非常昂贵的。现在，让我们一起看看计算搜索相关性的诸多权衡中的一种。

计算搜索相关性中的权衡

Elasticsearch使用tf-idf来计算搜索相关性。由于其分布式的性质，计算全局的idf(inverse document frequency，逆文档频率)非常昂贵。反之可以这样，每个分片计算本地的idf并将相关性得分分配给结果文档，返回的结果只关乎该分片上的文档。同样地，所有分片使用本地idf计算的相关性得分，返回结果文档，协调节点对所有结果排序并返回前几条。这样做在大多数情况下是没有问题的，除非索引的关键字词项有倾斜或者单个分片上没有代表全局的足够数据。

比如说，如果我们搜索“insight”这个词，但包含"insight"这个词项的大多数文档都存放在一个分片上，这样以来匹配查询的文档将不能公平地在每个分片上进行排序，因为每个分片上的本地idf的值非常不同，得到的搜索结果可能不会非常相关。同样地，如果没有足够的数据，那么对于某些搜索而言，本地idf的值可能大有不同，结果也会不如预期相关。在有足够数据的真实场景中，本地idf值一般会趋于均等，搜索结果是相关的，因为文档得到了公平的得分。

这里有2种应对本地idf得分的办法，但都不建议真正在生产环境中使用。

• 一种办法是一索引一分片，本地idf即是全局idf，但这没有为并行计算/水平伸缩留有余地，对于大型索引并不实用。
• 另一种办法是在搜索请求中使用dfs_query_then_search (dfs = distributed frequency search，分布式频率搜索) 参数，这样以来，会首先计算每个分片的本地idf，然后综合这些本地idf的值来计算整个索引的全局idf值，最后使用全局idf计算相关性得分来返回结果。这种方式不为生产环境推荐，因为有足够的数据确保词项频率分布均匀。

在本系列的过去几篇中，我们回顾了一些Elasticsearch的基本原则，对于我们理解并上手Elasticsearch，这些内容非常重要。在接下来的一篇中，我将使用Apache Spark来研究Elasticsearch中的索引数据。

查看英文原文：Anatomy of an Elasticsearch Cluster: Part III

剖析Elasticsearch集群系列涵盖了当今最流行的分布式搜索引擎Elasticsearch的底层架构和原型实例。

本文是这个系列的第一篇，在本文中，我们将讨论的Elasticsearch的底层存储模型及CRUD（创建、读取、更新和删除）操作的工作原理。

本系列已经得到原文著者Ronak Nathani的授权

Elasticsearch是当今最流行的分布式搜索引擎，GitHub、 SalesforceIQ、Netflix等公司将其用于全文检索和分析应用。在Insight，我们用到了Elasticsearch的诸多不同功能，比如：

• 全文检索
  • 比如找到与搜索词项(term)最相关的维基百科文章。
• 聚合
  • 比如在广告网络中，可视化的搜索词项的竞价直方图。
• 地理空间API
  • 比如在顺风车平台，匹配最近的司机和乘客。

正是因为Elasticsearch如此流行并且就在我们身边，我决定深入研究一下。本文，我将分享Elasticsearch的存储模型和CRUD操作的工作原理。

当我在思考分布式系统是如何工作时，我脑海里的图案是这样的：

水面以上的是API，以下的才是真正的引擎，一切魔幻般的事件都发生在水下。本文所关注的就是水下的部分，我们将关注：

• Elasticsearch是主从架构还是无主架构
• Elasticsearch的存储模型是什么样的
• Elasticsearch是怎么执行写操作的
• Elasticsearch是怎么执行读操作的
• 如何定义搜索结果的相关性

在我们深入这些概念之前，让我们熟悉下相关的术语。

1 辨析Elasticsearch的索引与Lucene的索引

Elasticsearch中的索引是组织数据的逻辑空间(就好比数据库)。1个Elasticsearch的索引有1个或者多个分片(默认是5个)。分片对应实际存储数据的Lucene的索引，分片自身就是一个搜索引擎。每个分片有0或者多个副本(默认是1个)。Elasticsearch的索引还包含"type"(就像数据库中的表)，用于逻辑上隔离索引中的数据。在Elasticsearch的索引中，给定一个type，它的所有文档会拥有相同的属性(就像表的schema)。

(点击放大图像)

图a展示了一个包含3个分片的Elasticsearch索引，每个分片拥有1个副本。这些分片组成了一个Elasticsearch索引，每个分片自身是一个Lucene索引。图b展示了Elasticsearch索引、分片、Lucene索引和文档之间的逻辑关系。

对应于关系数据库术语

Elasticsearch Index == Database  Types == Tables  Properties == Schema

现在我们熟悉了Elasticsearch世界的术语，接下来让我们看一下节点有哪些不同的角色。

2 节点类型

一个Elasticsearch实例是一个节点，一组节点组成了集群。Elasticsearch集群中的节点可以配置为3种不同的角色：

• 主节点：控制Elasticsearch集群，负责集群中的操作，比如创建/删除一个索引，跟踪集群中的节点，分配分片到节点。主节点处理集群的状态并广播到其他节点，并接收其他节点的确认响应。

  每个节点都可以通过设定配置文件elasticsearch.yml中的node.master属性为true(默认)成为主节点。

  对于大型的生产集群来说，推荐使用一个专门的主节点来控制集群，该节点将不处理任何用户请求。

• 数据节点：持有数据和倒排索引。默认情况下，每个节点都可以通过设定配置文件elasticsearch.yml中的node.data属性为true(默认)成为数据节点。如果我们要使用一个专门的主节点，应将其node.data属性设置为false。

• 客户端节点：如果我们将node.master属性和node.data属性都设置为false，那么该节点就是一个客户端节点，扮演一个负载均衡的角色，将到来的请求路由到集群中的各个节点。

Elasticsearch集群中作为客户端接入的节点叫协调节点。协调节点会将客户端请求路由到集群中合适的分片上。对于读请求来说，协调节点每次会选择不同的分片处理请求，以实现负载均衡。

在我们开始研究发送给协调节点的CRUD请求是如何在集群中传播并被引擎执行之前，让我们先来看一下Elasticsearch内部是如何存储数据，以支持全文检索结果的低延迟服务的。

存储模型

Elasticsearch使用了Apache Lucene，后者是Doug Cutting(Apache Hadoop之父)使用Java开发的全文检索工具库，其内部使用的是被称为倒排索引的数据结构，其设计是为全文检索结果的低延迟提供服务。文档是Elasticsearch的数据单位，对文档中的词项进行分词，并创建去重词项的有序列表，将词项与其在文档中出现的位置列表关联，便形成了倒排索引。

这和一本书后面的索引非常类似，即书中包含的词汇与其出现的页码列表关联。当我们说文档被索引了，我们指的是倒排索引。我们来看下如下2个文档是如何被倒排索引的：

文档1(Doc 1): Insight Data Engineering Fellows Program
文档2(Doc 2): Insight Data Science Fellows Program

如果我们想找包含词项"insight"的文档，我们可以扫描这个(单词有序的)倒排索引，找到"insight"并返回包含改词的文档ID，示例中是Doc 1和Doc 2。

为了提高可检索性(比如希望大小写单词都返回)，我们应当先分析文档再对其索引。分析包括2个部分：

• 将句子词条化为独立的单词
• 将单词规范化为标准形式

默认情况下，Elasticsearch使用标准分析器，它使用了：

• 标准分词器以单词为界来切词
• 小写词条(token)过滤器来转换单词

还有很多可用的分析器在此不列举，请参考相关文档。

为了实现查询时能得到对应的结果，查询时应使用与索引时一致的分析器，对文档进行分析。

注意：标准分析器包含了停用词过滤器，但默认情况下没有启用。

现在，倒排索引的概念已经清楚，让我们开始CRUD操作的研究吧。我们从写操作开始。

剖析写操作

创建((C)reate)

当我们发送索引一个新文档的请求到协调节点后，将发生如下一组操作：

• Elasticsearch集群中的每个节点都包含了改节点上分片的元数据信息。协调节点(默认)使用文档ID参与计算，以便为路由提供合适的分片。Elasticsearch使用MurMurHash3函数对文档ID进行哈希，其结果再对分片数量取模，得到的结果即是索引文档的分片。

  shard = hash(document_id) % (num_of_primary_shards)

• 当分片所在的节点接收到来自协调节点的请求后，会将该请求写入translog(我们将在本系列接下来的文章中讲到)，并将文档加入内存缓冲。如果请求在主分片上成功处理，该请求会并行发送到该分片的副本上。当translog被同步(fsync)到全部的主分片及其副本上后，客户端才会收到确认通知。
• 内存缓冲会被周期性刷新(默认是1秒)，内容将被写到文件系统缓存的一个新段上。虽然这个段并没有被同步(fsync)，但它是开放的，内容可以被搜索到。
• 每30分钟，或者当translog很大的时候，translog会被清空，文件系统缓存会被同步。这个过程在Elasticsearch中称为冲洗(flush)。在冲洗过程中，内存中的缓冲将被清除，内容被写入一个新段。段的fsync将创建一个新的提交点，并将内容刷新到磁盘。旧的translog将被删除并开始一个新的translog。

下图展示了写请求及其数据流。

(点击放大图像)

更新((U)pdate)和删除((D)elete)

删除和更新也都是写操作。但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更。那么，该如何删除和更新文档呢？

磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并(我们将在本系列接下来的文章中讲到)时，在.del文件中被标记为删除的文档将不会被写入新段。

接下来我们看更新是如何工作的。在新的文档被创建时，Elasticsearch会为该文档指定一个版本号。当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

文档被索引或者更新后，我们就可以执行查询操作了。让我们看看在Elasticsearch中是如何处理查询请求的。

剖析读操作((R)ead)

读操作包含2部分内容：

• 查询阶段
• 提取阶段

我们来看下每个阶段是如何工作的。

查询阶段

在这个阶段，协调节点会将查询请求路由到索引的全部分片(主分片或者其副本)上。每个分片独立执行查询，并为查询结果创建一个优先队列，以相关性得分排序(我们将在本系列的后续文章中讲到)。全部分片都将匹配文档的ID及其相关性得分返回给协调节点。协调节点创建一个优先队列并对结果进行全局排序。会有很多文档匹配结果，但是，默认情况下，每个分片只发送前10个结果给协调节点，协调节点为全部分片上的这些结果创建优先队列并返回前10个作为hit。

提取阶段

当协调节点在生成的全局有序的文档列表中，为全部结果排好序后，它将向包含原始文档的分片发起请求。全部分片填充文档信息并将其返回给协调节点。

下图展示了读请求及其数据流。

(点击放大图像)

如上所述，查询结果是按相关性排序的。接下来，让我们看看相关性是如何定义的。

搜索相关性

相关性是由搜索结果中Elasticsearch打给每个文档的得分决定的。默认使用的排序算法是tf/idf(词频/逆文档频率)。词频衡量了一个词项在文档中出现的次数 (频率越高 == 相关性越高)，逆文档频率衡量了词项在全部索引中出现的频率，是一个索引中文档总数的百分比(频率越高 == 相关性越低)。最后的得分是tf-idf得分与其他因子比如(短语查询中的)词项接近度、(模糊查询中的)词项相似度等的组合。

接下来有什么？

这些CRUD操作由Elasticsearch内部的一些数据结构所支持，这对于理解Elasticsearch的工作机制非常重要。在接下来的系列文章中，我将带大家走进类似的那些概念并告诉大家在使用Elasticsearch中有哪些坑。

• Elasticsearch中的脑裂问题及防治措施
• 事务日志
• Lucene的段
• 为什么搜索时使用深层分页很危险
• 计算搜索相关性中困难及权衡
• 并发控制
• 为什么Elasticsearch是准实时的
• 如何确保读和写的一致性

查看原文地址：http://insightdataengineering.com/blog/elasticsearch-crud

近几年，微服务架构迅速在整个技术社区窜红，它被认为是IT软件架构的未来方向，大神Martin Fowler也给微服务极高的评价。那为什么我们需要微服务，微服务的真正优势到底是什么，一个完整的微服务系统，应该包含哪些功能，本文作者刘彦夫在软件设计和开发领域有10多年工作经验，他将会从他的角度给出答案。

对微服务的基本理解

顾名思义，微服务要从两个方面来理解，一个是“微”，一个是“服务”。体型小到一定程度才能叫“微”，这个程度是什么呢？一个身高1米6，体重90斤的MM，我们说她苗条。微服务也一样，根据亚马逊CEO Bezos给出的有趣定义，单个微服务的设计、开发、测试和运维的所有人加在一起吃饭，只需要两个批萨就够了，这是就是著名的two pizza team rule。

具备什么样的能力才能算是“服务”？这个话题很大，我这里按照自己的片面理解总结一下，所谓服务就一定会区别于系统的功能，服务是一个或者一组相对的较小且独立的功能单元，是用户可以感知的功能最小集，比如：购物车，订单，信用卡结算等都可以作为单个服务独立提供。

这个理解显然不够深刻，为了进一步理解为什么微服务在近两年业界迅速窜红，理解为什么微服务会被认为是IT软件架构的未来方向，就要理解为什么我们需要微服务？它能给企业带来什么价值。传统企业的IT软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。后来有了一个叫SOA的软件架构专门针对这些问题给出了一套解决方案，很多企业也因此将自身IT系统迁移到SOA架构上。

但是，由于SOA早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终SOA开起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

依然SOA

微服务，从本质意义上看，还是SOA架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有Java编写的服务，也可以有Python编写的服务，他们是靠Restful架构风格统一成一个系统的。

最粗浅的理解就是将微服务之间的交互看作是各种字符串的传递，各种语言都可以很好的处理字符串，所以微服务本身与具体技术实现无关，扩展性强。另一个不同是微服务架构本身很轻，底层也有类似于SOA的总线，不过非常轻薄，现在看到的就两种方式：MQ和HTTP，而HTTP都不能完全等同于总线，而仅仅是个信息通道。

所以，基于这种简单的的协议规范，无论是兼容老旧系统，还是上线新业务，都可以随着时代的步伐，滚动升级。比如：你去年还在使用.NET技术，今年就可以平滑的过度到Go了，而且系统已有服务不用改动。所以微服务架构，既保护用户已有投资，又很容易向新技术演进。

微服务水下的冰山

人月不是银弹，微服务更不是银弹，好像软件微服务化了，软件系统就能够应对各种问题了。其实微服务的水面下藏着巨大的冰山。下面是微服务提供的能力，以及背后需要付出的代价。

1. 单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。

2. 单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。

3. 单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。

4. 多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。

5. 微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址，类似于到餐厅吃饭，新菜要写到“菜单”中，以供用户选择。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。

6. 还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。

综上所述，微服务关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。

这些系统性的功能也需要有一些服务来提供，这些服务不会直接呈现给最终用户，也就是微服务系统冰山下面的部分，我们可以简称它为微服务系统的“底座”。所有的微服务都像一个APP，插在这个底座的上面，享受这个底座提供的系统能力比如：元数据存放、灰度发布、蓝绿部署等等。

微服务系统底座

一个完整的微服务系统，它的底座最少要包含以下功能：

• 日志和审计，主要是日志的汇总，分类和查询

• 监控和告警，主要是监控每个服务的状态，必要时产生告警

• 消息总线，轻量级的MQ或HTTP

• 注册发现

• 负载均衡

• 部署和升级

• 事件调度机制

• 资源管理，如：底层的虚拟机，物理机和网络管理

以下功能不是最小集的一部分，但也属于底座功能：

• 认证和鉴权

• 微服务统一代码框架，支持多种编程语言

• 统一服务构建和打包

• 统一服务测试

• 微服务CI/CD流水线

• 服务依赖关系管理

• 统一问题跟踪调试框架，俗称调用链

• 灰度发布

• 蓝绿部署

令人困惑的几个问题

微服务的底座是不是必须的？

是的，基本上是必须的。你可以不用代码实现一个资源管理服务，可以手工用Excel管理你的所有机器资源，但是不代表微服务系统没有这个功能，只不过这个功能是人工实现的。再举个例子，日志系统如果只是简单的打印文件，那么多个微服务的日志就需要手工收集，人工分类和筛选。所以，微服务的底座最小集一定会存在，问题是看怎样实现它。

这里仅仅是总结了对微服务系统的基本理解，而实现这个架构有很多技术，这里不进行详细展开。实践方面，推荐王磊的《微服务架构与实践》，他描述了使用Ruby相关的技术实现了一整套微服务系统，特别是书中后面的实践部分讲解了如何将已有的系统演化为微服务架构，是很好的参考和指导材料。

是不是所有软件都能做微服务？

这个命题有些微妙，也很难说清楚，回答这个命题本身就是一种挑战，可能最终也没有正确答案。不过，我还是把我自己的理解写在这里，让大家去拍砖。在我这里，答案是否定的。我只需举出一个反例，比如：存储系统，其架构是传统的分层架构，每一层都使用下面一层的服务，并为上一层提供服务。虽然可以将这种架构调整为基于服务的架构，但没办法做成微服务。

区别在哪里呢？核心的区别在于独立性上，微服务大多是可以独立的运行和使用的，而存储这种非常底层和基础的系统，每层部件都不能单独被使用，比如：Pool管理、CHUNK管理、VOL管理、NFS文件系统，这些功能都无法离开另外一些功能而独立运行，要对外提供可用的存储功能，一大堆功能必须一起上。这种系统做到极致，最多也就能够使其部件可以独立的部署和升级，俗称打热补丁。

这也就是为什么这种底层传统系统架构通常是单块架构的原因。由于单块架构的各个部分调用关系紧密，做成微服务后系统集成成本会大大增加，不仅如此，这样的架构做成微服务并不能提高交付效率，因为各个部分根本就无法独立的运行和测试。

什么样的软件做成微服务？

能不能做成微服务，取决于四个要素：

• 小：微服务体积小，2 pizza团队。

• 独：能够独立的部署和运行。

• 轻：使用轻量级的通信机制和架构。

• 松：为服务之间是松耦合的。

针对于小、轻、松都是可以通过某些技术手段达到目的，而独立的部署和运行，则是和业务本身有关系，如果你这个系统提供的业务是贴近最终用户的，并且这些功能之间的耦合性很小，则微服务就可以按照业务功能本身的独立性来划分，则这类系统做成微服务是非常合适的。如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就更加无法做到真正的微服务了。

感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们。

from:http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/

“探索推荐引擎内部的秘密”系列将带领读者从浅入深的学习探索推荐引擎的机制，实现方法，其中还涉及一些基本的优化方法，例如聚类和分类的应用。同时在理论讲解的基础上，还会结合 Apache Mahout 介绍如何在大规模数据上实现各种推荐策略，进行策略优化，构建高效的推荐引擎的方法。本文作为这个系列的第一篇文章，将深入介绍推荐引擎的工作原理，和其中涉及的各种推荐机制，以及它们各自的优缺点和适用场景，帮助用户清楚的了解和快速构建适合自己的推荐引擎。

信息发现

如今已经进入了一个数据爆炸的时代，随着 Web 2.0 的发展， Web 已经变成数据分享的平台，那么，如何让人们在海量的数据中想要找到他们需要的信息将变得越来越难。

在这样的情形下，搜索引擎（Google，Bing，百度等等）成为大家快速找到目标信息的最好途径。在用户对自己需求相对明确的时候，用搜索引擎很方便的通过关键字搜索很快的找到自己需要的信息。但搜索引擎并不能完全满足用户对信息发现的需求，那是因为在很多情况下，用户其实并不明确自己的需要，或者他们的需求很难用简单的关键字来表述。又或者他们需要更加符合他们个人口味和喜好的结果，因此出现了推荐系统，与搜索引擎对应，大家也习惯称它为推荐引擎。

随着推荐引擎的出现，用户获取信息的方式从简单的目标明确的数据的搜索转换到更高级更符合人们使用习惯的信息发现。

如今，随着推荐技术的不断发展，推荐引擎已经在电子商务 (E-commerce，例如 Amazon，当当网 ) 和一些基于 social 的社会化站点 ( 包括音乐，电影和图书分享，例如豆瓣，Mtime 等 ) 都取得很大的成功。这也进一步的说明了，Web2.0 环境下，在面对海量的数据，用户需要这种更加智能的，更加了解他们需求，口味和喜好的信息发现机制。

回页首

推荐引擎

前面介绍了推荐引擎对于现在的 Web2.0 站点的重要意义，这一章我们将讲讲推荐引擎到底是怎么工作的。推荐引擎利用特殊的信息过滤技术，将不同的物品或内容推荐给可能对它们感兴趣的用户。

图 1. 推荐引擎工作原理图
 

图 1 给出了推荐引擎的工作原理图，这里先将推荐引擎看作黑盒，它接受的输入是推荐的数据源，一般情况下，推荐引擎所需要的数据源包括：

• 要推荐物品或内容的元数据，例如关键字，基因描述等；
• 系统用户的基本信息，例如性别，年龄等
• 用户对物品或者信息的偏好，根据应用本身的不同，可能包括用户对物品的评分，用户查看物品的记录，用户的购买记录等。其实这些用户的偏好信息可以分为两类：

• 显式的用户反馈：这类是用户在网站上自然浏览或者使用网站以外，显式的提供反馈信息，例如用户对物品的评分，或者对物品的评论。
• 隐式的用户反馈：这类是用户在使用网站是产生的数据，隐式的反应了用户对物品的喜好，例如用户购买了某物品，用户查看了某物品的信息等等。

显式的用户反馈能准确的反应用户对物品的真实喜好，但需要用户付出额外的代价，而隐式的用户行为，通过一些分析和处理，也能反映用户的喜好，只是数据不是很精确，有些行为的分析存在较大的噪音。但只要选择正确的行为特征，隐式的用户反馈也能得到很好的效果，只是行为特征的选择可能在不同的应用中有很大的不同，例如在电子商务的网站上，购买行为其实就是一个能很好表现用户喜好的隐式反馈。

推荐引擎根据不同的推荐机制可能用到数据源中的一部分，然后根据这些数据，分析出一定的规则或者直接对用户对其他物品的喜好进行预测计算。这样推荐引擎可以在用户进入的时候给他推荐他可能感兴趣的物品。

推荐引擎的分类

推荐引擎的分类可以根据很多指标，下面我们一一介绍一下：

1. 推荐引擎是不是为不同的用户推荐不同的数据

   根据这个指标，推荐引擎可以分为基于大众行为的推荐引擎和个性化推荐引擎

   • 根据大众行为的推荐引擎，对每个用户都给出同样的推荐，这些推荐可以是静态的由系统管理员人工设定的，或者基于系统所有用户的反馈统计计算出的当下比较流行的物品。
   • 个性化推荐引擎，对不同的用户，根据他们的口味和喜好给出更加精确的推荐，这时，系统需要了解需推荐内容和用户的特质，或者基于社会化网络，通过找到与当前用户相同喜好的用户，实现推荐。

   这是一个最基本的推荐引擎分类，其实大部分人们讨论的推荐引擎都是将个性化的推荐引擎，因为从根本上说，只有个性化的推荐引擎才是更加智能的信息发现过程。

2. 根据推荐引擎的数据源

   其实这里讲的是如何发现数据的相关性，因为大部分推荐引擎的工作原理还是基于物品或者用户的相似集进行推荐。那么参考图 1 给出的推荐系统原理图，根据不同的数据源发现数据相关性的方法可以分为以下几种：

   • 根据系统用户的基本信息发现用户的相关程度，这种被称为基于人口统计学的推荐（Demographic-based Recommendation）
   • 根据推荐物品或内容的元数据，发现物品或者内容的相关性，这种被称为基于内容的推荐（Content-based Recommendation）
   • 根据用户对物品或者信息的偏好，发现物品或者内容本身的相关性，或者是发现用户的相关性，这种被称为基于协同过滤的推荐（Collaborative Filtering-based Recommendation）。
3. 根据推荐模型的建立方式

   可以想象在海量物品和用户的系统中，推荐引擎的计算量是相当大的，要实现实时的推荐务必需要建立一个推荐模型，关于推荐模型的建立方式可以分为以下几种：

   • 基于物品和用户本身的，这种推荐引擎将每个用户和每个物品都当作独立的实体，预测每个用户对于每个物品的喜好程度，这些信息往往是用一个二维矩阵描述的。由于用户感兴趣的物品远远小于总物品的数目，这样的模型导致大量的数据空置，即我们得到的二维矩阵往往是一个很大的稀疏矩阵。同时为了减小计算量，我们可以对物品和用户进行聚类， 然后记录和计算一类用户对一类物品的喜好程度，但这样的模型又会在推荐的准确性上有损失。
   • 基于关联规则的推荐（Rule-based Recommendation）：关联规则的挖掘已经是数据挖掘中的一个经典的问题，主要是挖掘一些数据的依赖关系，典型的场景就是“购物篮问题”，通过关联规则的挖掘，我们可以找到哪些物品经常被同时购买，或者用户购买了一些物品后通常会购买哪些其他的物品，当我们挖掘出这些关联规则之后，我们可以基于这些规则给用户进行推荐。
   • 基于模型的推荐（Model-based Recommendation）：这是一个典型的机器学习的问题，可以将已有的用户喜好信息作为训练样本，训练出一个预测用户喜好的模型，这样以后用户在进入系统，可以基于此模型计算推荐。这种方法的问题在于如何将用户实时或者近期的喜好信息反馈给训练好的模型，从而提高推荐的准确度。