Elasticsearch学习笔记 recovery & gateway ES在有节点加入或退出时会根据机器的负载对索引分片进行重新分配，挂掉的节点重新启动时也会进行数据恢复。代表ES索引的持久化存储方式，ES默认是先把索引存放到内存中，当内存满了时再持久化到硬盘。当这个ES集群关闭在重新启动是就会从gateway中读取索引数据。支持本地文件，分布式文件系统，Hadoop的HDFS。{lamp/}搜索类型 SearchType搜索类型有4种 ①query and fetch(速度最快)(返回N倍数据量)②query then fetch（默认的搜索方式） ③DFS query and fetch ④DFS query then fetch(可以更精确控制搜索打分和排名。) DFS解释：先把各个分片的词频率和文档频率收集一下，然后进行词搜索的时候，各分片依据全局的词频率和文档频率进行搜索和排名。QUERY_AND_FETCH是最快的，DFS_QUERY_THEN_FETCH是最慢的。从搜索的准确度来说，DFS要比非DFS的准确度更高。{lamp/}Query 1.查询所有（match_all）。2.解析查询字符串（query_string）支持全部的Apache Lucene查询语法。3.通配符查询（wildcardQuery）匹配多个字符，?匹配1个字符 注意：避免 开始, 会检索大量内容造成效率缓慢。4.词条查询（termQuery）匹配在给定字段中含有该词条的文档，而且是确切的、未经分析的词条。5.字段匹配查询（matchQuery、multiMatchQuery匹配多个字段）。6.标识符查询（idsQuery）此查询针对内部的_uid字段运行，所以它不需要启用_id字段。7.相似度查询（fuzzy）基于编辑距离算法来匹配文档。8.范围查询（range）字段可以是数值型，也可以是基于字符串的。9.跨度查询（spanTermQuery）前面有多少词。10.组合查询、复杂查询、布尔查询（boolQuery）（must、mustNot、should-and、not、or）结合其他查询使用。11.正则表达式查询（regexpQuery）。12.分页查询（setFrom(0).setSize(1)）。13.排序查询（addSort）。14.过滤filter查询(setPostFilter(FilterBuilders.rangeFilter("age").from(1).to(19))）15.高亮highlight。16.聚合查询aggregations。{lamp/}文档写入 a.数据写入buffer 同时写入translog b.每隔1s，buffer中的数据被写入segment文件（先写入os cache）c.每隔30分钟或者translog文件一定大时就flush，所有cache中的文件被fsync到磁盘。数据写入到可以搜索默认是1s，近实时。{lamp/}IK分词器 ①针对于es集群中已经存在的历史索引库，不会进行重新分词，分词插件不起作用。②新建索引库，以及索引库下的type时，要指定相应的中文分词插件，才会起作用。会根据分词插件，对新增的索引信息进行分词，存储到es集群中。③需要将安装好的ik中文分词插件拷贝到集群中别的节点上。④给es集群安装插件时，优先安装中文分词插件（建议排在第一位！！）。⑤windows下的换行符是rn , Linux os下的换行符是n ；将windows下的指令拷贝到linux命令。行下执行，往往会报错，不能正常执行，应对方案是：a)先将内容粘贴到Linux下的临时文件中；b)然后从linux临时文件中拷贝。{lamp/}优化 ①log输出的水平默认为trace，查询超过500ms即为慢查询，就要打印日志，把log输出水平改为info，可以减轻服务器的压力②批量入库大量数据的话，建议将副本数设置为0。因为es在索引数据的时候，如果有副本存在，数据也会马上同步到副本中，这样会对es增加压力。待索引完成后将副本按需要改回来。这样可以提高索引效率。③调大系统的"最大打开文件数",建议32K甚至是64K ulimit -a (查看) ulimit -n 32000(设置)④修改bin/elasticsearch.in.sh中ES_MIN_MEM和ES_MAX_MEM的大小，建 议设置一样大，避免频繁的分配内存，根据服务器内存大小，一般分配60%左右(默认 256M) ⑤分片数过多会导致检索时打开比较多的文件，另外也会导致多台服务器之间通讯。而分片数过少会导至单个分片索引过大，所以检索速度慢。建议单个分片最多存储20G左右的索引数据，所以，分片数量=数据总量/20G ⑥副本多的话，可以提升搜索的能力，但是如果设置很多副本的话也会对服务器造成额外的压力，因为需要同步数据。所以建议设置2-3个即可⑦使用filter查询会使用query cache, 如果业务场景中的过滤查询比较多，建议将querycache设置大一些，以提高查询速度。indices.queries.cache.size：10%（默认），可设置成百分比，也可设置成具体值，如256mb。⑧查询结果如query.setSize不能设置成 Integer.MAX_VALUE， 因为ES内部需要建立一个数据结构来放指定大小的结果集数据。{lamp/}其他 1.Solr 查询快，但更新索引时慢（即插入删除慢），用于电商等查询多的应用；ES建立索引快（即查询慢），即实时性查询快，用于facebook新浪等搜索。2.索引库名称必须要全部小写，不能以下划线开头，也不能包含逗号。3.BigDesk Plugin：节点的实时状态监控，包括jvm的情况，linux的情况， elasticsearch的情况。4.discovery.zen代表ES的自动发现节点机制，通过配置可以禁用，此时需要设置节点注解列表。5.如果不想返回完整的JSON文档，可以使用source返回指定字段。6.在elasticsearch中所有的搜索都会触发相关性分数计算。过滤器不计算得分，所以他们比执行查询的速度，过滤器可缓存在内存中，允许重复搜索。如果相关性不重要，那就使用filter，否则就使用query。7.master节点不参与查询、索引操作，仅负责对于集群管理，所以在CPU、内存、磁盘配置上，都可以比数据节点低很多。8.在Lucene中删除文档，数据不会马上在硬盘上除去，而是在lucene索引中产生一个.del的文件，而在检索过程中这部分数据也会参与检索，lucene在检索过程会判断是否删除了，如果删除了再过滤掉。9.默认给索引设置5个分片1个副本，分片数已经创建就不可修改。10.ES5.X之后不再支持string；5.4之前Boolean类型支持代表boolean的数字和字符串，之后只接受true、false、"true"、"false"。11.ES5.4之后对test类型的字段采用BM25评分模型，而不是基于tf-idf，评分模型的选择可以通过similarity指定。12.ES是在每个分片上单独打分的，因此分片数量会影响打分结果，分词器也会影响评分，不同的分词器会使倒排索引中词项数发生改变。13.ES默认会索引所有的字段，如果只需要存储，enable可以设置成false，这样只能从_source中获取，无法搜索到。

JAVA垃圾回收 垃圾回收算法 标记-清除算法 ：产生不连续的内存碎片，为较大对象分配内存时无法找到足够连续的内存，不得不提前触发垃圾收集动作。CMS垃圾回收器。标记-整理算法 ：存活的对象向一端移动，存活率高时，效率远高于复制算法。G1、ParallelGC（Paraller Old）。复制算法 ：Eden、s0、s1，比例是8:1:1，10%被浪费，JDK8，ParallelGC（Parallel Scavenge）。分代收集算法 。{lamp/}垃圾回收器 CMS收集器 ：发标记、并发清除、内存碎片、最短回收停顿时间为目标，与用户线程可以并发执行，牺牲一定的吞吐量；可开启内存碎片整理，会停顿用户线程。ParallelGC ：（JDK8）新生代（Parallel Scavenge复制算法），老年代（Paraller Old标记整理算法）。G1垃圾收集器 ：吞吐量高，可预测的停顿；整体基于标记-整理算法，从局部（两个Region）是基于复制算法；设置了新生代大小相当于放弃了G1为我们做的自动调优。G1官方的建议——实时数据占用了超过半数的堆空间；对象分配率或“晋升”的速度变化明显；期望消除耗时较长的GC或停顿（超过0.5——1秒）。ZGC ：着色指针（在对象的引用上标注了对象的信息），读屏障（把指针更新为有效地址再返回，也就是，永远只有单个对象读取时有概率被减速），Stop-The-World 只会在根对象扫描阶段发生，所以GC暂停时间并不会随着堆和存活对象的数量而增加。TB 级别的堆内存管理；最大 GC Pause 不高于 10ms；最大的吞吐率（Throughput）损耗不高于 15%。ParallelGC 吞吐量优先，后台运算而不需要太多交互的任务。CMS 响应速度优先，集中在互联网站或B/S系统服务端上的Java应用。G1 响应速度优先，面向服务端应用，将来替换CMS。{lamp/}内存划分为 JVM内存划分为堆内存和非堆内存，堆内存分为年轻代、老年代，非堆内存就一个永久代。在JDK1.8版本废弃了永久代，替代的是元空间（MetaSpace），元空间与永久代上类似，都是方法区的实现，他们最大区别是元空间并不在JVM中，而是使用本地内存。{lamp/}Full GC条件 a.发生minor gc之前会判断老年代最大可用连续空间是否大于新生代的所有对象总空间，如果大于直接发生minor gc，如果小于发生full gc。b.老年代空间不足时，创建一个大对象时Ended放不下，会直接保存到老年代中，如果老年代空间不足，就会触发full gc。c.显示调用System.gc()方法，可能会发生full gc。{lamp/}引用类型 强引用 ：永远不会回收软引用SoftReference ：内存不足时才会回收该对象。比如网页缓存、图片缓存等。弱引用WeakReference ：每次垃圾回收。虚引用PhantomReference ：虚引用必须和引用队列 （ReferenceQueue）联合使用，主要用来跟踪对象被垃圾回收器回收的活动。假如有一个应用需要读取大量的本地图片，如果每次读取图片都从硬盘读取，则会严重影响性能，但是如果全部加载到内存当中，又有可能造成内存溢出，此时使用软引用可以解决这个问题。

Spark学习笔记 Spark Streaming KafkaUtils.createStream:PUSH，Kafka高级API，数据漏处理或者多处理状况，主题分区与RDD的分区不相关，可开启WAL(数据复制两次)。KafkaUtils.createDirectStream：PULL，Kafka低级API，Kafka和RDD分区之间有一对一的映射关系，不会更新Zookeeper中的偏移量。{lamp/}内存管理 spark on yarn （yarn-cluster）Resource Manager接收到申请后在集群中选择一个Node Manager分配Container，并在Container中启动ApplicationMaster进程，在ApplicationMaster中初始化SparkContext，生成一系列task，ApplicationMaster向Resource Manager申请资源后通知Node Manager在获得的Container中启动Excutor进程，SparkContext分配task给Excutor，Excutor发送运行状态给Driver。一个Container对应一个JVM进程，也就是一个executor，所以JVM的Heap Size取决于spark.executor.memory。堆内存90%以上作为安全空间，如果内存大，可以调高95%。缓存空间是60%(Heep 90%60%)(safetyFraction 和 memoryFraction) ，会负责存储 Persist、Unroll 以及 Broadcast 的数据。Unroll序列化空间是20%(Heep 90%60%*20%)。shuffle空间的安全比例是80%，spark.shuffle.memeoryFraction 0.2(Heep 80% 20%)。Spark1.6之后 联合内存 加入Heap 4G预留内存（Reserved Memory）：系统预留内存，会用来存储Spark内部对象。默认是300M，Java Heap大小至少为*1.5=450M。用户内存（User Memory）：主要用于存储 RDD 转换操作所需要的数据，例如 RDD 依赖等信息。(Heap-300M)*25%=949M，每个 Executor 分配 1G 的数据就会OOM。Spark Memory， (Heap-300M)*75%，各50%，动态占用机制。Execution 内存：主要用于存放 Shuffle、Join、Sort、Aggregation 等计算过程中的临时数据。Storage 内存：主要用于存储 spark 的 cache 数据，例如RDD的缓存、unroll数据。Storage占用对方内存可能被淘汰，如果没有再磁盘存储会丢失(storage_level )，Execution占用对方内存只能等释放。先借用，再溢写到磁盘，内存优先。启用静态内存管理的方式是:spark.memory.useLegacyMode true{lamp/}RDD有多少分区就有多少task，因为一个task只能处理一个partition上的数据。Spark算子分为transform、action，只有action算子才触发计算（延迟计算）如：countbykey、reduce、count、take(n)、foreach、collect。一个action算子提交一个job、一个job包含一个或者多个stage、stage是根据RDD宽依赖(一个RDD分到两个不同的子RDD)、窄依赖（一个子RDD可以依赖多个父RDD）划分的。Excuotor(包含一个或者多个task,每个task一个虚拟core)，Excuotor、task数量可以在submit中设置。总task数量一般设置成总core数的2-3倍，因为有的task可能先执行完。map一条记录变一条记录，function函数返回Object；faltmap一条记录变多条记录，function函数返回Iterable<Object>迭代器。join操作时，可以将reduce join转换成map join，并广播大变量。{lamp/}SHUFFLE 有hashshuffle、sortshuffle、钨丝shuffle，后者会进行排序，一个task一个文件，钨丝shuffle效果跟sort差不多， 使用了自己实现的一套内存管理机制，性能上有很大的提升。hashshuffle，map端写文件时每个task都会创建下一个stage总task数量的文件，可以设置合并，这样，每个excutor中的task就会公用一批文件，先往内存缓存写，再溢出到磁盘，调整大一些可以减少io次数，reduce端拉取文件时有buffer缓冲区，每次都只能拉取与buffer缓冲相同大小的数据。{lamp/}调优 Spark优化还包括，设置kyro序列化方式 ，性能更高、调整RDD持久化内存比例、调整shuffle时reduce端拉取数据重试次数，等待时长（因为在JVM full gc时是stop the world，多尝试几次）、数据本地化等待时长。

Kafka、RocketMQ消息队列总结 Kafka 同一个partition内的消息只能被同一个组中的一个consumer消费，当消费者数量多于partition的数量时，多余的消费者空闲。每个partition为一个目录，partiton命名规则为topic名称+有序序号，每个partion(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中，默认保留7天的数据。Kafka支持以Partition为单位对Message进行冗余备份，每个Replication集合中的Partition都会选出一个唯一的Leader，所有的读写请求都由Leader处理，其他Replicas从Leader处把数据更新同步到本地。Offset：消息在Partition中的编号，编号顺序不跨Partition。消费失败不支持重试，组与组之间的消息是否被消费是相互隔离互不影响的。kafka可以横向扩展，堆积能力强，当你需要进行大量数据的持久化。kafka的ack机制：在kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常的能够被收到。重复消费（已经消费了数据，但是offset没提交），每次消费时更新每个topic+partition位置的offset在内存中，多台服务器集群，offset要做去重处理。消息丢失，producer同步模式（ack）、异步模式（buffer满了不清理），consumer自己手动维护偏移量。{lamp/}RocketMQ Topic分片再切分为若干等分，其中的一份就是一个Queue。一个broker对应一组消息文件commitLog，所有topic的消息都存在commitLog中，consumerqueue保存的是消息在commitLog中的地址 。broker主从(单Master、多Master、Master-Slave(异步复制)、Master-Slave(同步双写))。consumer第一次默认从master节点拉取消息，未消费的数据量占物理内存的比例，当超过40%时，会返回建议的拉取节点id。RocketMQ不保证消息不重复。消息丢失（在各个层都可能发生）,producer同步（send不报错）异步（重写回调方法），生产者返回消息状态，开启重试消费。顺序消息，必须Producer单线程顺序发送，且发送到同一个队列，一个queue对应一个consumer，Broker重启，由于队列总数发生变化，哈希取模后定位的队列会变化，产生短暂的消息顺序不一致。RocketMQ可以严格的保证消息有序。但这个顺序，不是全局顺序，只是分区（queue）顺序。要全局顺序只能一个分区，kafka是放同一个topic。一个Queue最多只能分配给一个Consumer。Queue是Topic在一个Broker上的分片等分为指定份数后的其中一份，是负载均衡过程中资源分配的基本单元。{lamp/}消费并行度 Kafka消费并行度和分区数一致；RocketMQ消费并行度分两种情况，顺序消费方式并行度同Kafka完全一致，乱序方式并行度取决于Consumer的线程数，如Topic配置10个队列，10台机器消费，每台机器100个线程，那么并行度为1000。

Zookeeper学习笔记 节点选举 Zookeeper节点状态有looking following leading。①每个server首先给自己投票（myid，ZXID，epoch），将这个投票发给集群中其他机器（epoch选举周期，每次进入新一轮的投票后，都会对该值进行加1操作）②每个server接受来自各个服务器的投票，检查是否是本轮投票、是否来自LOOKING状态的服务器③处理投票优先检查ZXID。ZXID比较大的服务器优先作为Leader如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器④统计投票每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，一旦选出leader，后边的机器不管myid和ZXID多大，都自动成为follow⑤改变服务器状态{lamp/}Znode Znode数据节点，数据大小不能超过1M，分为持久节点和临时节点，临时节点的生命周期和客户端会话绑定，一旦客户端会话失效节点就会被移除。创建节点时还可以指定SEQUENTIAL属性，这样会在节点后面增加一个自增的整型数字。节点信息包含czxid创建该节点的事务id、mzxid最后一次更新该节点的事务id等。Zookeeper将数据存储于内存中，Znode是存储数据的最小单元，而Znode被以层次化的结构进行组织，形容一棵树，这种节点称为Znode：data：Znode存储的数据信息。ACL：记录Znode的访问权限，即哪些人或哪些IP可以访问本节点。child：当前节点的子节点引用，类似于二叉树的左孩子右孩子。stat：包含Znode的各种元数据，比如事务ID、版本号、时间戳、大小等等。{lamp/}应用场景 ①.数据发布订阅：配置信息等放到Zookeeper某个节点上，集群中其他机器监听变更。②.负载均衡：动态感知子节点（即服务ip）的上下线。③.命名服务：持久顺序节点，每个父节点都会为子节点维护一个顺序，数字后缀、上限为整型的最大值。④.分布式协调和通知：同a。⑤.集群管理：每个机器一个临时节点。⑥.Master选举：所有服务同时创建一个节点并监测，成功的为Master。⑦.分布式锁：排它锁（一起去创建和监听临时节点）、共享锁（创建临时序号节点，比本序号小的序号没有写请求时，才可以写）。⑧.分布式队列。{lamp/}其他 ①.ZAB协议原子消息广播协议，分为消息广播、崩溃恢复。②.基于观察者模式设计，数据的状态发生变化，Zookeeper就通知已经在Zookeeper上注册的那些观察者做出相应的回应。③.Zookeeper的数据结构和linux的目录结构类似，也像数据结构中的树。