Mageek`s Wonderland

后端好书阅读与推荐系列文章：
后端好书阅读与推荐
后端好书阅读与推荐（续）
后端好书阅读与推荐（续二）
后端好书阅读与推荐（续三）
后端好书阅读与推荐（续四）
后端好书阅读与推荐（续五）
后端好书阅读与推荐（续六）

Elasticsearch权威指南

Elasticsearch: The Definitive Guide (豆瓣): https://book.douban.com/subject/25868239/

Elasticsearch是一个强大的开源搜索引擎（不仅如此，还是一个分布式存储、实时分析系统），作为后端开发者，我们常常需要用到它，甚至是借鉴其原理来实现自己特定的功能，因为了解一下是很有必要的。这本书不仅讲了使用方法，还讲了原理，很适合我们学习与查阅。

亮点：

• Elasticsearch使用Java开发并使用 Lucene 作为其核心来实现所有索引和搜索的功能，它的目的是通过简单的 RESTful API 来隐藏 Lucene 的复杂性。也对用户隐藏了分布式系统的复杂性，而且提供了一系列运行良好的默认值，从而让全文搜索变得简单，达到开箱即用的效果
• ES与传统RDB的对比：
  • Relational DB -> Databases -> Tables -> Rows -> Columns
  • Elasticsearch -> Indices -> Types -> Documents -> Fields
• ES的自动实现了分片、负载均衡、发现、冗余、选主、同步、扩展迁移、容错等功能。一个节点(node)就是一个Elasticsearch实例，而一个集群(cluster)由一个或多个节点组成，它们具有相同的cluster.name，集群中一个节点会被选举为主节点(master)，它将临时管理集群级别的一些变更，例如新建或删除索引、增加或移除节点等。索引只是一个用来指向一个或多个分片(shards，是一个 Lucene 实例)的逻辑命名空间(logical namespace)，分片可以是主分片(primary shard)或者是复制分片(replica shard)。索引中的每个文档属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据，复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，启动新节点时集群会重新组织并均匀分配各个分片
• ES提供了丰富的数据操纵功能，不仅有简单的查询字符串搜索（含通配符），还有DSL，可以构建更复杂、强大的查询
• 批量请求可以减少网络往返次数开销，以及日志数量，可以提升性能（mysql也有这种做法），这个批量的大小要根据你的硬件来定制
• 倒排索引是全文搜索的核心技术，也就是按照每个单词（经过分词后）划分归属集，存储包含这个单词的文档，检索是按照单词的，所以可以很快返回相关文档
• ......

此外需要注意的是Elasticsearch发展太快，书籍只是用来系统性的学习的，如果真的要使用起来，还是要去官网看最新的用法，但是基本原理和思想变化是不多的。

最近在看kafka的代码，就免不了想看看消息队列的一些要点：服务质量（QOS）、性能、扩展性等等，下面一一探索这些概念，并谈谈在特定的消息队列如kafka或者mosquito中是如何具体实现这些概念的。

服务质量

服务语义

服务质量一般可以分为三个级别，下面说明它们不同语义。

At most once

至多一次，消息可能丢失，但绝不会重复传输。
生产者：完全依赖底层TCP/IP的传输可靠性，不做特殊处理，所谓“发送即忘”。kafka中设置acks=0。
消费者：先保存消费进度，再处理消息。kafka中设置消费者自动提交偏移量并设置较短的提交时间间隔。

Kafka是一款很棒的消息系统，可以看看我之前写的 后端好书阅读与推荐来了解一下它的整体设计。今天我们就来深入了解一下它的实现细节（我fork了一份代码），首先关注Producer这一方。

要使用kafka首先要实例化一个KafkaProducer，需要有brokerIP、序列化器等必要Properties以及acks（0、1、n）、compression、retries、batch.size等非必要Properties，通过这个简单的接口可以控制Producer大部分行为，实例化后就可以调用send方法发送消息了。

核心实现是这个方法：

public Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback callback) {
    // intercept the record, which can be potentially modified; this method does not throw exceptions
    ProducerRecord<K, V> interceptedRecord = this.interceptors.onSend(record);//①
    return doSend(interceptedRecord, callback);//②
}

通过不同的模式可以实现发送即忘（忽略返回结果）、同步发送（获取返回的future对象，回调函数置为null）、异步发送（设置回调函数）三种消息模式。

Raft是当前分布式领域最重要的一致性算法之一，今天我们就来好好研究研究这个算法的论文, 还有对应网站, 动画, 不想看英文的也有中文的翻译，所以我这边就不翻译了，主要还是记录一下论文重点和自己的心得。

Raft算法作者的初衷是对标Paxos算法（过去十年分布式一致性的事实标准），但是要比它更易理解，主要手段有：

1. 分解，把整个一致性问题拆分为Leader选举、日志复制和安全机制这三大方面还有角色改变这个小方面。所以模块化是一个软件系统可维护、理解和扩展的不二手段。
2. 减少状态空间的状态，相比于Paxos，Raft减少了非确定性和服务器之间可以处于不一致的方式。所以在复杂的问题上做减法，可以减少很多不必要的繁琐的步骤。

Raft使用了更强的Leader，感觉这和我之前看的OceanBase是相似的，就是增强Leader（UpdateServer）或者说单点的作用，加重中心化（这也是社会的运作方式，没有Leader就是大家一盘散沙，文明是达不到今天这个程度的），要做决策就先选择一个Leader，然后让他去协调所有的决议，会更加简单快速，而Paxos就是P2P或者说弱Leader的方式。事实上，我们之所以使用分布式系统也是迫不得已，如果单台机器能搞定还要这么多系统干嘛？所以我们也要看到单点系统的好处，那就是一致性很容易保证，所以在分布式系统中使用一个增强（能力和责任）的单点既利于一致性的保证也能获得分布式的优势。

David John Wheeler有一句名言“计算机科学中的任何问题都可以通过加上一层间接层来解决”，一层不够就再加一层。后半句是我加的 (*￣︶￣) ，虽然有点玩笑的意思，但是也的确能说明一些问题。计算机科学的确是靠着一层又一层的抽象与封装解决了巨量的问题。

我们来简单回顾一下：
开始的时候是程序员直接输入二进制指令来操纵硬件的，不仅性能低下还很耗费用户时间；
于是后来出现了操作系统，用文件、进程与线程、地址空间抽象了磁盘、CPU与内存，统一和简化了硬件访问方式；
机器语言对用户不友好，于是便出现了汇编语言、中级语言（如C）、高级语言（如Java）的包装，其最终执行还是要转化为机器语言；
裸高级语言大家还用得不爽，觉得开发效率低，于是又出现了各种框架（如Spring、Hibernate）
......

这样一层一层抽象包装下来，我们要想实现一个功能比如定时写文件等已经变成了很简单的事，只需要几行代码就搞定了。
但是抽象层数过多就会导致我们顶层的用户有时候会出现一些莫名其妙的问题，我们用一个实际的案例伪共享来说明一下