博客文章

在java中产生uuid的方式是使用java.util.UUID。 UUID.randomUUID().toString(); 我在测试redis性能时，使用uuid产生测试数据，发现多线程测试redis的rpush接口的时候，性能老是上不去。 查看cpu利用率也不高，网卡流量也不大。就是tps上不去。但是如果用两台client去测，又可以达到更高的tps。 后来直接用jstack查看了下堆栈，发现大多数线程停留在： java.lang.Thread.State: BLOCKED (on object monitor) at java.security.SecureRandom.nextBytes(Unknown Source) - waiting to lock <0x00000005ffe1c548> (a java.security.SecureRandom) at java.util.UUID.randomUUID(Unknown Source) 原来uuid的生成遇到了性能瓶颈。于是我单独测试了下生成随机uuid的性能,发现无论是1个线程还是32个线程还是300个线程，它的tps只能到10万级别。 甚至是线程数越大，tps越低。tps在每个机器上都不一样，有的机器上测试tps只有5万。我们就以一台双核4G内存的虚拟机为例： tps在 140000+ 我们看randomUUID方法的javadoc的描述是： The UUID is generated using a cryptographically strong pseudo random number generator 也就是说uuid使用了一个强随机数，也也保证了uuid的不重复性。 public static UUID randomUUID() { SecureRandom ng=numberGenerator; if(ng == null) numberGenerator=ng=new SecureRandom(); byte[] randomBytes=new byte[16]; ng.nextBytes(randomBytes); return new UUID(randomBytes); } 再看SecureRandom的javadoc Note: Depending on the implementation, the generateSeed and nextBytes methods may block as entropy is being gathered, for example, if they need to read from /dev/random on various unix-like operating systems. ...

2015年6月30日，荣耀7发布，7天预约时间，京东和华为商城总预约量创纪录的达900多万，7月7日第一次发售，20万荣耀7在2分钟内售罄，说明华为荣耀又一次得到了花粉的认可和喜爱。不知道是什么时候开始，华为手机的一些独有技术被花粉称为黑科技，并为花粉喜爱。本文主要细数一下荣耀7有哪些黑科技： 第一：双卡盲插功能，自动识别SIM卡 荣耀7全网通可以实时检测两个4G卡的网络信号，自动选择最佳的信号。双通道智能下载，可以支持双卡同时上网。 第二：指纹识别，双硬件保护。 指纹识别有自学习功能，越用越灵敏，其次指纹识别键还可以做home键等其它功能。 第三：荣耀小口哨 荣耀小口哨是个智能蓝牙耳机，可以实现语音控制，可以插到手机上充电，可以同时支持两部手机。 第四：智灵键 双击智灵键可以打开情景智能功能，长按智灵键可以打开荣耀7的语音控制功能。用户可以查询饭店、购买车票甚至一键语音打车，整个过程不需要二次操作直达用户需求。 第五：语言找手机功能，黑屏打电话。 只要喊一句“荣耀小七，你在哪儿”，你的手机就会自动回应并播放音乐。 当然除此之外，华为荣耀7还有其它优势，例如NFC、红外遥控，2000W像素，全金属机身，3G内存，麒麟935、光绘摄影等。我想无论是配置还功能上这次荣耀7都无可挑剔。 当然一些米粉总是要挖空心思找一些东西来喷的。

cassandra2.1版终于出了稳定版-cassandra2.1.6版。照例把之前的功能在新版本上跑一跑。但是仍然遇到一个问题： 创建一个表 CREATE TABLE test ( a int, b int, c int, d int, PRIMARY KEY (a, b, c) ); 根据a=1 and b<6查询结果是： select * from test where a=1 and b<6; a | b | c | d —+—+—+— 1 | 3 | 1 | 2 1 | 3 | 2 | 2 1 | 3 | 4 | 2 1 | 3 | 5 | 2 1 | 4 | 4 | 2 1 | 5 | 5 | 2 ...

单个文件，对其内容进行排序，使用sort命令： sort a.txt 去重加-u选项 sort -u a.txt 输出到一个文件 sort -o a.txt_sort -u a.txt 如果是100个1G大小的文件呢？如何进行排序去重呢？使用sort命令也是可以实现的。 第一步：先对单个文件进行排序去重 sort -o a1.txt -u a1.txt sort -o a2.txt -u a2.txt sort -o a3.txt -u a3.txt sort -o a4.txt -u a4.txt 。。。。 sort -o a100.txt -u a100.txt 第二步：使用sort的合并排序 sort -o a.txt -u -m a*.txt -m选项 表示merge已经有序的文件，如果文件事先没有排好序，这个可能会出错。 在执行merge的时候，你可能会遇到空间不足，无法写/tmp/sortXXXX的错误。 因为是多个大文件的合并操作，内存不够用，肯定是要写临时文件的。默认sort是写到/tmp目录下。 还好sort命令想的周到，你可以通过-T 选项指定一个较大空间的磁盘目录作为sort的临时文件目录。 sort -o a.txt -T /disk/temp -u -m a*.txt 最后等结果吧。

写博客，写的不好的时候，就想删除，目录结构设计的不合理，就想更改。但是有一些网页已经被百度等搜索引擎收录了。用户访问的时候就会显示404页面，表示页面不存在。 在过去，网站通常的做法是把404页面写上友好的提示语，或者随机显示一则笑话，甚至是直接跳转到主页。 现在有很多大型的网站，像百度、腾讯等都已经把404页面改为公益广告，特别是寻找丢失儿童的广告。例如腾讯公司内部员工志愿者就发起了这样一起互联网公益活动，建议站长博主在自己的404页面中嵌入一段简单的代码，就能通过互联网来迅速传播失踪儿童信息，从而提高找回失踪儿童的概率。 我认为这是个好主意，从今天开始，赵岩的博客正式加入公益404页面，打开不存在的页面都会跳转到公益寻人广告页面。 比如：http://zhaoyanblog.com/404.html

华为昨日公布了P8Max这款旗舰机的价格（3788元），同时也向媒体公布了其上半年手机出货量的情况。据华为介绍称，2015年上半年，华为手机出货量达到5000万部，5月单月出货量便达到1000万部，销量同比增长了40%，中国市场占比50%。 提到P8 Max这款新机时，华为终端中国区总裁朱平表示，中国中、高、低端手机都有一定的市场空间，而价格并非决定消费者需求的关键。P8 Max配置了6.8英寸的超大屏幕，主打高端商务人群，3788元的价格在中国手机市场中也属于高端水平。 华为CMO杨哲杨哲也表示，只要产品能够触及用户的真正需求，价格并不是问题。华为P8 Max国行版将于6月26日正式开售

cassandra是集群部署，多个节点，多个数据备份，一两个节点挂掉，一般不会有数据丢失。只要删除当掉的节点，对其它节点进行repair，数据都会自动均衡到完整的份数。 但是如果大面积节点掉电，或者机房着火那就肯定要丢失数据了，使用cassandra作为数据存储的业务，肯定是很大的业务，数据量超大的那种。机房容灾肯定是必不可少的。 cassandra提供多种多数据中心部署、机架敏感策略。这里介绍一种最普通的一种: GossipingPropertyFileSnitch GossipingPropertyFileSnitch策略支持简单的多个数据中心，和多机架。 第一步： 在cassandra.yaml配置文件中指定集群支持该策略： endpoint_snitch: GossipingPropertyFileSnitch 第二步： 在cassandra.yaml的seeds中把两个数据中心的种子节点都配上 seeds: “192.168.22.101,192.168.22.102,192.168.23.101,192.168.23.102” 第三步： 配置cassandra-rackdc.properties 每台机器都配置自己所属的数据中心名称和机架名称 dc=DC1 rack=RAC1 配置机架的目的是，防止整个机框掉电，数据丢失。cassandra可以尽量保证同一份数据的多个副本不存在于同一个机架上。 这就要求你的机架个数要大约等于你的数据副本个数，同时每个机架的节点个数尽量相同，否则会导致某些节点数据偏多，分布不均 第四步 创建keyspace使用NetworkTopologyStrategy策略，并且制定每个集群的份数。 CREATE KEYSPACE mykeyspace WITH replication = { ‘class’: ‘NetworkTopologyStrategy’, ‘DC1’: ‘3’, ‘DC2’: ‘3’ }; 第五步 客户端使用数据一致性策略，从QUORUM改为LOCAL_QUORUM。这样客户端会先从LOCAL数据中查询，LOCAL无法查询，再从REMOTE数据中心进行查询。 cassandra JAVA官方驱动，把默认首先连上的节点所属的数据中心视为LOCAL数据中心。所以你不要容灾数据中心节点IP配到了代码中。

6月15日 @华为荣耀官方微博确定了荣耀7的发布时间和地点： 2015年6月30日 北京工业大学奥林匹克体育馆 海报是一个大大的指纹，确认荣耀7是带指纹识别无疑。 这是工信部网站注册型号为PLK-AL10的一款手机，想必就是荣耀7，从背面看，荣耀7的指纹识别是借用了Mate7的设计。 至于更多的细节和科技提升，我们要等发布会当天知晓了。

Elasticsearch 是默认延迟加载fielddata到内存里的。当elasticsearch第一次遇到一个查询需要一个指定field的fielddata的时候，就会把索引的每个段中整个field加载到内存。对于小段，这是个可以忽略不计的时间，但是如果你有一些5G大小的段并且需要加载10GB的fielddata到内存里，这个过程需要数十秒，习惯于秒内响应时间的用户会被网突如其来的迟钝所打击。 有三种方法应对这种延迟尖峰： Eagerly load fielddata（饿汉式（预）加载fielddata） Eagerly load global ordinals（饿汉式（预）加载全局序数） Prepopulate caches with warmers （使用warmer提前加载缓存）。 所有这些都是一个意思：预先加载fielddata到内存里，这样当用户需要执行一个搜索的时候就感受不到延迟了。 饿汉式（预）加载fielddata 首先是预先加载（而不是默认的延迟加载），当一个新的段形成时（无乱是刷新，写入或者是合并），可以预先加载的field会提前把段的fielddata加载到内存里，在这段可以用于搜索之前。 这意味着当你第一次查询的时候，如果碰到在这个段上，你不需要再触发加载fielddata的操作，它们已经在内存中了，这会防止你的用户遇到一些冷到缓存而发生延迟尖峰。 预先加载是基于每个field的，所以你可以控制哪些field进行预加载。 PUT /music/_mapping/_song { "price_usd": { "type": "integer", "fielddata": { "loading" : "eager" } } } 备注: 通过设置fielddata.loading: eager，告诉elasticsearch预先加载这个field的内容到内存里。 fielddata的加载可以设置成饿汉模式（预先加载）还是懒惰模式（延迟加载），使用update-mapping的api。 预先加载是简单对fielddata加载的开销的转移，从查询时间转义到刷新时刻。 大段的刷新时间会比小段的时间长，通常大段的产生都是由哪些已经可搜素的小段合并而来的，所以慢一点的刷新时间不是那么重要（译者注：意思是大段的刷新时间长不影响你的搜索，在大段合并成前的小段可以用于搜索）。 全局序数 其中一项用于减少string类型的fielddata占用内存的技术叫做序数。 假设我们有十亿条文档，每个文档都有一个status的field，只有三个值：status_pending, status_published, status_deleted，如果我们把所有的status加载到内存里，每个文档需要14-16byte，也就是说15GB 相反，我们可以确认这三个特殊的字符串，对他们排序，依次编号0,1,2 Ordinal | Term ------------------- 0 | status_deleted 1 | status_pending 2 | status_published 序号对应的字符串值要在序号列表中存储一次，每个文档只要使用他们的编号来表示他们所包含的值就可以了。 Doc | Ordinal ------------------------- 0 | 1 # pending 1 | 1 # pending 2 | 2 # published 3 | 0 # deleted 这个可以把15GB的内存占用减少到小于1GB ...

最近几日 @华为荣耀 官方微博已经连续发布微博海报，表示6月8日会有新产品发布。 无论是从小苹果的苹果把，还是汽水瓶的吸管，形状都预示这款产品很可能是荣耀旗舰机型荣耀7。 而且荣耀6是去年6月24日发布的，时隔一年，荣耀7也是时候横空出世了。 但是总觉得这个宣传还不到位，首先发布会在一周前才开始宣传，而且至今也没有曝光媒体邀请函，以及发布会地点，有点反常。 很希望这次发布的是荣耀7，但是也有可能是荣耀其它产品，期待6月8日发布会。 6月6日 有那么一点冰爽，#有点意思# 6月5日 有那么一点勇敢，#有点意思# 6月4日 有那么一点诱惑，#有点意思# 6月3日 有那么一点速度，#有点意思# #李娜产女# 荣耀也有新宝贝！@李娜#有点意思# 6月2日 有那么一点生活，#有点意思# 6月1日 想象力概括了世界的一切。——阿尔伯特·爱因斯坦

ThreadPool部分 Elasticsearch 内部使用了线程池，通过这些线程池之间的合作完成工作，在需要时传递工作。一般来说你不需要调整和优化线程池。但是有时候你看着这些线程池的状态，对你掌握你的集群行为是很有帮助的。 这有十几个线程池，他们的格式都是类似的： "index": { "threads": 1, "queue": 0, "active": 0, "rejected": 0, "largest": 1, "completed": 1 } 每个线程都列出了配置的线程数，其中有多少个线程是正在处理事务的，也就是活动的，还有多少等待处理的事务在队列里。 如果队列满了，超出了限制，新的事务就会开始被拒绝，你可以看到拒绝的事务的统计，这通常表示你的集群正处在一个资源瓶颈，因为一个满的队列表示你的集群或者节点正在以最大的速度处理事务，但是依然赶不上新事务增加的速度。 关于bulk的拒绝 如果你的线程队列出现拒绝请求的事情，那么醉有可能发生的就是bulk批量索引的请求，通过采用并发导入线程，很容易发给elasticsearch很多的bulk请求，并发请求越多越好吗？ 现实中，任何集群都有一定的线程，造成入不敷出。一旦这个阈值达到了，你的队列就会被迅速的填满，新的bulk请求就会被拒绝。 这是一个好事，队列的拒绝是对压力的一个有效措施，他们告诉你你的集群正在处于最大的容量，这要好过把数据全部塞到内存队列里。增大队列大小不会提升性能，它只会隐藏问题，如果你的集群每秒只能处理1万个文档，这和你的队列大小是100还是一千万没有任何关系，你的集群每秒的处理能力仍然是1万个文档。 队列只会隐藏性能问题，并且带来数据丢失的风险，在队列里的表示还没有被处理的，如果你的节点挂了，那么这些请求就会永远的丢失了，此外队列会消耗很大的内存，这不是个好主意。 最好我们通过优雅的解决队列满了的问题来清理队列。当你遇到bulk拒绝请求时候，你应该采取如下措施： 1、停止插入线程3-5秒 2、从bluk请求里提取被拒绝的操作，可能大部分请求都成功了。bulk的响应里会告诉你哪些操作成功了，哪些操作被拒绝了。 3、把拒绝的操作重新生成一个新的bulk请求。 4、如果再有拒绝请求发生，就重复上面的步骤。 通过这种方式，你的代码会自然的适应你的集群的负载，自然的减压。 请求拒绝不是错误，它们只是表示你需要过会重试。 有十几个线程池，大部分你可以忽视，但是有少部分需要你特别注意： indexing 正常的索引文档的请求 bulk 批量请求，这有区别于非批量的请求 get 根据id获取文档的操作 search 索引的检索和查询请求 merging 专门管理lucene合并的线程池 FS和Network部分（剩余空间和网络） 继续看node stats api返回的信息，你会看到一个关于文件系统的统计信息，剩余空间，数据存放目录，磁盘io等待。如果你没有监控剩余磁盘空间大小，你可以从这里得到。磁盘io也是很容易得到，但是一些更专业的命令行工具（例如iostat）可能更有用。 很显然，如果你的磁盘空间不足了，elasticsearch肯定完蛋了，所以一定要保证充足的磁盘空间。 下面是关于network统计的两个部分： "transport": { "server_open": 13, "rx_count": 11696, "rx_size_in_bytes": 1525774, "tx_count": 10282, "tx_size_in_bytes": 1440101928 }, "http": { "current_open": 4, "total_opened": 23 }, transport: 显示了网络传输的基本信息，这涉及到节点之间的通信（通常是9300端口）和一些客户端和节点之间的链接。如果你看到很多链接在这里，不要担心，elasticsearch会保持大量的节点之间的链接。 ...

操作系统和进程部分 操作系统和进程部分的含义是很清楚的，这里不会描述的很详细。他们列出了基本的资源统计，例如CPU和负载。操作系统部分描述了整个操作系统的情况，进程部分只是描述了Elasticsearch的JVM进程的使用情况。 这显然是很有用的统计， 但是往往会被忽视，一些统计包括如下部分： CPU 负载 内存使用情况 swap使用情况 打开文件句柄数 JVM部分 jvm部分包含一些有关于运行elasticsearch的jvm进程的关键信息。最重要的是，它包含了垃圾回收方面的细节，这对你的elasticsearch的集群的稳定性有很大影响。 垃圾收集（GC）入门 在我们描述这个之前，很有必要先介绍下GC以及它对elasticsearch的影响。如果你对jvm中的GC很熟悉，可以跳过这一章。 java是一个自己进行垃圾回收的语言，也就是说程序员不需要主动管理内存的分配和释放。程序员只要专心写自己的代码，java虚拟机会管理根据需要分配内存的过程，然后当内存不再使用的时候，它自己会去释放。 当内存被分配给JVM进程，它会被分配成一个叫堆的大块区域。JVM会把这个堆分成两组，叫做“代”： 年轻代（或者伊甸园） 新实例化的对象就在这里分配空间，年轻代的空间通常很小，大约100MB-500MB。年轻代包含两个幸存者区域 老年代 存储那些老的对象的区域。这些对象是长期存在，并且持续很长时间。老年代通常比年轻代大很多。你可以看到elasticsearch节点的老年代可能大到30GB 当一个对象被实例化后，它会被放置到年轻代，当年轻代的空间满了，一个年轻代的垃圾回收就启动了。那些仍然存活的对象就会被移动到其中一个幸存者区域。而死了的对象就会被清除了。如果一个对象在年轻代中经历了多次GC仍然幸存，那它将被晋升到老年代。 类似的过程也发生在老年代，当老年代的空间越来越满了，一个垃圾回收就启动了，同时死了对象会被清除。 天下没有免费的午餐，年轻代和老年代的垃圾回收都包含一个“stop-the-world”的阶段。在这个时间内，JVM会停止程序的执行，进行对象的标记和收集，在这个stop-the-world的阶段，没有任何事情发生，请求不会被处理，ping不会被会回应。shards不会再进行迁移。整个世界真的停止了。 对于年轻代这不是一个问题，因为它很小，GC执行的很快。但是对于大一点的老年代，缓慢的GC意味着1s甚至15s的停顿，这对于一个服务器软件来说是不可接受的。 垃圾回收在JVM是很复杂的算法，为了减少停顿做了很多的工作。同时Elasticsearch很努力适应GC，比如通过内部对象的重用，利用网络缓冲区，并挺贵一些特征值例如文档的数量。但是GC的频率和长短是需要你特别留意的信息，因为它是集群不稳定的头号元凶。 如果一个集群经常性的发生长时间GC，那么你的集群一定内存不足并且负载特别高。这些长时间GC会导致节点周期性的脱离集群。这种不稳定会导致分片数据不断的重新生成，以保证集群内的平衡以及足够的分片数量。这会增加网络贷款和磁盘IO，同时你的集群还要承担进行正常的索引数据和查询。 简而言之，长时间的GC是很糟糕的，需要尽可能的减少。 因为GC对Elasticsearch如此重要，你必须对node stats的API显示的这个部分特别熟悉才行。 "jvm": { "timestamp": 1408556438203, "uptime_in_millis": 14457, "mem": { "heap_used_in_bytes": 457252160, "heap_used_percent": 44, "heap_committed_in_bytes": 1038876672, "heap_max_in_bytes": 1038876672, "non_heap_used_in_bytes": 38680680, "non_heap_committed_in_bytes": 38993920, jvm部分首先列出的是有关堆内存使用情况的一般情况，你可以看到多少heap被用到，有多少可以被使用（已经分配了线程），还有堆内存最大可以长到多少。理想情况下heap_committed_in_bytes应该和heap_max_in_bytes相同，如果被分配的堆较小，那JVM将会不得不调整堆的大小，这个过程代价是很高的。如果你的这两个值是不同的，请看《Heap: Sizing and Swapping》章节，确认你配置的是否正确。 heap_used_percent 是你必须盯着看的一个有用的参数。Elasticsearch配置的是当堆使用到75%的时候进行GC，如果你的节点总是大约75%，那你节点正在承受内存方面的压力，这是一个告警，预示着你不久就会出现慢GC。 如果你的heap使用率一直在85%以上，那你有麻烦了，90-95%的概率会因为10-30s的GC 发生性能问题，这还是好的，最坏的就是发生内存溢出。 "pools": { "young": { "used_in_bytes": 138467752, "max_in_bytes": 279183360, "peak_used_in_bytes": 279183360, "peak_max_in_bytes": 279183360 }, "survivor": { "used_in_bytes": 34865152, "max_in_bytes": 34865152, "peak_used_in_bytes": 34865152, "peak_max_in_bytes": 34865152 }, "old": { "used_in_bytes": 283919256, "max_in_bytes": 724828160, "peak_used_in_bytes": 283919256, "peak_max_in_bytes": 724828160 } } }, young, survivor, and old sections 显示了每个代在GC中的使用情况，供你分析。这些数据方便你看到他们的相对大小，但是对于你调查问题往往不是很重要。 ...

第一：去掉一些不用的html head内容，让页面更小 在function.php中加入： remove_action( ‘wp_head’, ‘wp_generator’); remove_action( ‘wp_head’, ‘wlwmanifest_link’); remove_action( ‘wp_head’, ‘rsd_link’); remove_action( ‘wp_head’, ‘index_rel_link’ ); remove_action( ‘wp_head’, ‘parent_post_rel_link’, 10, 0 ); remove_action( ‘wp_head’, ‘start_post_rel_link’, 10, 0 ); remove_action( ‘wp_head’, ‘adjacent_posts_rel_link_wp_head’, 10, 0 ); remove_action( ‘wp_head’, ‘feed_links’, 2 ); remove_action( ‘wp_head’, ‘feed_links_extra’, 3 ); remove_action( ‘wp_head’, ‘wp_print_head_scripts’, 9 ); remove_action( ‘wp_head’, ‘rel_canonical’ ); remove_action( ‘wp_head’, ‘wp_shortlink_wp_head’, 10, 0 ); 第二：去掉一些定时任务，这些定时任务会频繁访问数据库和网络 在function.php中加入： remove_action( ‘init’, ‘wp_schedule_update_checks’ ); remove_action( ’load-plugins.php’, ‘wp_update_plugins’ ); remove_action( ’load-themes.php’, ‘wp_update_themes’ ); remove_action( ’load-update-core.php’, ‘wp_update_plugins’ ); remove_action( ’load-update-core.php’, ‘wp_update_themes’ ); remove_action( ’load-update.php’, ‘wp_update_plugins’ ); remove_action( ’load-update.php’, ‘wp_update_themes’ ); remove_action( ‘upgrader_process_complete’, ‘wp_update_plugins’ ); remove_action( ‘upgrader_process_complete’, ‘wp_update_themes’ ); remove_action( ‘upgrader_process_complete’, ‘wp_version_check’ ); remove_action( ‘wp_maybe_auto_update’, ‘wp_maybe_auto_update’ ); remove_action( ‘wp_update_plugins’, ‘wp_update_plugins’ ); remove_action( ‘wp_update_themes’, ‘wp_update_themes’ ); remove_action( ‘wp_version_check’, ‘wp_version_check’ ); ...

集群的健康只是一个方面，它是对整个集群所有方面的一个很高的概括。节点状态的api是另外一个方面，它提供了关于你的集群中每个节点令你眼花缭乱的统计数据。 节点的状态提供了那么多的统计数据，在你很熟悉它们执勤，你可能不确定哪些指标是至关重要。我们会把需要监控的最重要的几个指标跳出来（我们建议你把所有的统计指标记录下来，例如使用Marvel插件，因为你不知道你哪天可能就需要）。 节点状态的API可以通过下面的方式执行 GET _nodes/stats 在输出内容的开头，我们可以看到集群的名字和我们第一个node的信息： { "cluster_name": "elasticsearch_zach", "nodes": { "UNr6ZMf5Qk-YCPA_L18BOQ": { "timestamp": 1408474151742, "name": "Zach", "transport_address": "inet[zacharys-air/192.168.1.131:9300]", "host": "zacharys-air", "ip": [ "inet[zacharys-air/192.168.1.131:9300]", "NONE" ], ... 节点会根据一个hash值的顺序来显示，也就是node的uuid值。还有一些关于node的网络属性会显示（例如传输地址和HOST）。这些信息有助于调试发现问题，比如那些节点没有加入集群。通常你可能会发现端口用错了，或者节点绑错了IP地址等等。 Indices部分 indices部分列出的是对于所有的索引在该节点上的汇总信息。 "indices": { "docs": { "count": 6163666, "deleted": 0 }, "store": { "size_in_bytes": 2301398179, "throttle_time_in_millis": 122850 }, 它返回的统计信息可以分成这样几个部分： docs: 显示有多少文档在该节点，以及有多少删除的文档还没有从数据段中清除出去。 store: 显示该节点消耗了多少物理存储，这个数据包含主分片和副分片，如果throttle_time_in_millis太大，说明你设置的磁盘流量太低（参考段的合并一章节） "indexing": { "index_total": 803441, "index_time_in_millis": 367654, "index_current": 99, "delete_total": 0, "delete_time_in_millis": 0, "delete_current": 0 }, "get": { "total": 6, "time_in_millis": 2, "exists_total": 5, "exists_time_in_millis": 2, "missing_total": 1, "missing_time_in_millis": 0, "current": 0 }, "search": { "open_contexts": 0, "query_total": 123, "query_time_in_millis": 531, "query_current": 0, "fetch_total": 3, "fetch_time_in_millis": 55, "fetch_current": 0 }, "merges": { "current": 0, "current_docs": 0, "current_size_in_bytes": 0, "total": 1128, "total_time_in_millis": 21338523, "total_docs": 7241313, "total_size_in_bytes": 5724869463 }, indexing： 表示索引文档的次数，这个是通过一个计数器累加计数的。当文档被删除时，它不会减少。注意这个值永远是递增的，发生在内部索引数据的时候，包括那些更新操作。 ...

Elasticsearch已经有很好的默认值，特别是涉及到性能相关的配置或者选项。如果你有什么拿不准的，最好就不要动它。我们已经目睹了数十个因为错误的设置而导致集群毁灭，因为它的管理者总认为他改动一个配置或者选项就可以带来100倍的提升。 注意：请阅读全文，所有的配置项都同等重要，和描述顺序无关，请阅读所有的配置选项，并应用到你的集群中。 其它数据库可能需要调优，但总得来说，Elasticsearch不需要。如果你遇到了性能问题，最好的解决方法通常是更好的数据布局或者更多的节点。在Elasticsearch中有很少的"神奇的配置项"，如果存在，我们也已经帮你优化了。 指定名字 Elasticsearch默认启动的集群名字叫elasticsearch，你最好给你的生产环境的集群改个名字，改名字的目的很简单，就是防止某个人的笔记本加入到了集群，造成意外。简单修改成elasticsearch_production ，会省掉多次心痛~。 你可以在你的elasticsearch.yml中修改： cluster.name: elasticsearch_production 同样，修改节点的名字也是明智的，就像你现在可能发现的那样，Elasticsearch会在你的节点启动的时候随机给它指定一个名字。这在你开发的时候可能觉得很萌，但是当凌晨3点钟，你还在尝试会议哪台物理机是Tagak the Leopard Lord.的时候，你就不觉得萌了。 更重要的是，这些名师是在启动的时候产生的，每次启动节点，它都会得到一个新的名字，这可以使日志混淆，因为所有节点的名称都是不断变化的。 这些可能性都是很无聊的，我们建议你给每个及诶点一个有意义的名字-一个清楚的，描述性的名字，同样你可以在elasticsearch.yml中配置： node.name: elasticsearch_005_data 路径 默认情况下，Eleasticsearch会把插件、日志以及你最重要的数据放在安装目录下。这会带来不幸的事故。即如果你重新安装Elasticsearch的时候就可能不小心把安装目录覆盖了，如果你不小心，你就可能把你的全部数据删掉了。 不要笑，这种情况，我们见过很多次了。 最好的选择就是把你的数据目录配置到安装目录以外的地方，同样你也可以选择转移你的插件和日志目录。 可以更改如下： path.data: /path/to/data1,/path/to/data2 Path to log files: path.logs: /path/to/logs Path to where plugins are installed: path.plugins: /path/to/plugins 注意：你可以通过逗号分隔指定多个目录。 数据可以保存到多个不同的目录，每个目录如果是挂载在不同的硬盘，做一个人RAID 0是一个简单而有效的方式。Elasticsearch会自动把数据分隔到不同的目录，以便提高性能。 最小主节点数 minimum_master_nodes的设定对你的集群的稳定及其重要，当你的集群中有两个masters的时候，这个配置有助于防止集群分裂。 如果你发生了一个集群分裂，你集群就会处在丢失数据的危险中，因为master节点是被认为是这个集群的最高统治者，它决定了什么时候新的索引可以创建，多少分片要移动等等。如果你有两个master节点，你的数据的完整性将得不到保证，因为你有两个master节点认为他们有集群的控制权。 这个配置就是告诉Elasticsearch当没有足够master候选节点的时候，就不要进行master选举，等master候选节点足够了才进行选举。 该配置必须应该配置成master候选节点的法定个数(大多数个),法定个数就是（master候选节点个数/2)+1. 这里有几个例子： *如果你有10个节点（能保存数据，同时能成为master） 法定数就是6 *如果你有3个候选master，和100个数据节点，法定数就是2，你只要数数那些可以做master的节点数就可以了。 *如果你有两个节点，你遇到难题了，法定数当然是2，但是这意味着如果有一个节点挂掉，你整个集群就不可用了。设置成1可以保证集群的功能，但是就无法保证集群分裂了，像这样的情况，你最好至少保证有3个节点。 elasticsearch.yml中这样配置： discovery.zen.minimum_master_nodes: 2 但是由于ELasticsearch是动态的，你可以很容易的添加和删除节点，这会改变这个法定个数，如果你不得不修改索引的节点的配置并且重启你的整个集群为了让配置生效，这将是非常痛苦的一件事情。 基于这个原因，minimum_master_nodes （还有一些其它配置），允许通过API调用的方式动态进行配置，当你的集群在线运行的时候，你可以这样修改配置： PUT /_cluster/settings { “persistent” : { “discovery.zen.minimum_master_nodes” : 2 } } 这将成为一个永久的配置，并且无论你配置项里配置的如何，这个将优先生效。当你添加和删除master节点的时候，你需要更改这个配置。 集群恢复方面的配置项 当你集群重启时，几个配置项影响你的分片恢复的表现。首先，我们必须明白，如果什么也没配置将会发生什么。 想象一下假设你有10个节点，每个节点保存一个分片，主分片或者副分片，也就是有一个有5个主分片/1个副本 的索引。你需要停止整个集群进行休整（举个例子，为了安装一个新的驱动程序）。当你重启你的集群，很自然会出现5个节点已经起动了，还有5个还没启动的场景。 ...