前言上篇从分布式的角度阐述了 ES 的分布式设计和思想，这一篇打算与 Lucene 结合起来，摸透一些 ES 的常遇到的概念，我们可以将了解到的这些东西应用到优化实践中去。 废话不多说，进入正题。 ShardShard 实际上是一个 Lucene 的一个实例（Lucene Index），但往往一个 Elastic Index 都是由多个 Shards （primary & replica）
前言上篇大致介绍了 ElasticSearch CRUD 的数据走向和涉及到的 Gossip 算法和每一种节点扮演的角色。我们对 ES 有了初步的认知，这一篇着重从 CAP 的角度去解读 ES 的分布式思想。 Split Brain之前介绍过，对于去中心化的 ES 分布式系统来说，采用默认配置是无法避免脑裂问题的（可以参考前一篇文章的discovery.zen.minimum_master_nod
前言ElasticSearch （以下简称为 ES）从名字上看是搜索引擎，实际上除了搜索的作用，ES 甚至还支持上千台服务器分布式部署以及 PB 级别的可靠性存储，适合构建高可用和可扩展的系统。本文从设计的角度探讨 ES 是如何运作且能够支撑如此庞大的数据量的检索和插入。 节点类型 Master Eligible Node （候选主节点）：设置成node.master=true (default)
jps （JVM 进程状态工具）1jps -lv 通常这样就可以大致看清楚 JVM 应用的基本概况 -l : 输出main类或Jar的全名 -v : 输出携带的 JVM 参数 -m : 输出传入 main 方法的参数 -q : 静默模式，只输出进程号 jstack （查看 JVM 线程堆栈信息）123456789101112131415Usage: jstack [-l] <pi
概述之前的文章《Java线程同步策略》对Java的并发策略有了一个比较详尽的介绍。其中讲到ReentrantLock时提及到了AbstractQueuedSynchronizer（下文简称AQS）这个类。从字面含义去揣度，这就是一个抽象的队列同步器。所谓抽象，想必有许多方法（或者说模板）还需要开发者具体实现；所谓队列，意味着其中维护一套遵循FIFO原则的存储结构；所谓同步，说明其中蕴含某种系统级
线程安全概述引用《Java Concurrency In Practice》对线程安全的定义 当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象是线程安全的。 这意味着如若要实现线程安全，代码本身必须要封装所有必要的正确性保障手段（比如锁的实现），以确保程