【AutoCS】技术分享| 汽车网络安全运营的中间件技术

分布式Lucene模块是Lucene的分布式框架，虽然底层用的是Lucene，但是Lucene不支持分布式搜索，ES为了能在每个节点上都运行Lucene进行相应的索引、查询、更新等操作，所以需要做成一个分布式的运行框架来满足业务需求。

ES组件模块包含了索引组件、搜索组件、映射组件等：

索引组件：对数据建立索引（通常是建立倒排索引），添加数据时要使用索引模块，创建索引；

搜索组件：对数据进行查询搜索，根据关键词匹配索引查询想要的文档；

映射组件：数据的每个字段可以根据建立的表结构通过mapping进行映射解析；mapping是处理数据的方式和规则方面做一些限制，如某个字段的数据类型、默认值、分析器、是否被索引等等，这些都是映射里面可以设置的；如果没有建立表结构，那么ES会根据数据类型来推测数据结构，并自动生成一个mapping，然后根据mapping进行解析。

ES集群中各个节点通过节点发现模块相互发现的，默认使用的是Zen。ES是一个基于p2p的系统，他先通过广播寻找存在的节点，再通过多播协议来进行节点之间的通信，同时也支持点对点的交互。

ES还可以支持多种script脚本语言，例如mvel、js、python等；通过使用脚本，可以在ES查询语句中计算自定义表达式。

传输模块管理ES内部节点之间或集群与客户端之间的通信，默认内部使用tcp协议进行交互，同时它还支持http协议、thrift、servlet、memcached、zeroMQ等通信协议（通过插件方式集成）在外部进行交互。

最上层就是ES暴漏给外部的访问接口,也是官方推荐的接口方案。直接发送基于http协议的Restful类型的请求，方便后续使用nginx做代理、分发包括可能后续会做权限的管理，通过http很容易做这方面的管理。　

以文档的ID为关键字，表中记录文档中每个字(如my、name)的位置信息(如文档1: my在第1位和第7位出现，出现了2次；name在第2位出现，出现了1次；…)，查找时扫描表中每个文档中字的信息直到找出所有包含查询关键字的文档。如表2所示：

表 2 正向索引排列表

先索引文档编号，再索引关键词，需要遍历扫描所有文档，才能知道哪些文档带有某个关键词，具体结构流程如下所示：

文档1  {my([1, 7], 2), name([2], 1),is([3, 9], 2),…}

文档2  {my([1], 1), name([2],1),…}

如果我们要找哪些文档包含name，需要先索引文档1再索引name判断是否存在此关键词，然后索引文档2再索引name判断是否存在此关键词。

与正向索引相反，倒排索引是以字或词为关键字进行索引，表中关键字所对应的表项记录了出现这个字或词的所有文档。一个表项就是一个字段,它记录该文档的ID和字符在该文档中出现的位置情况。如表3所示：

表 3倒排索引排列表

在表3中，我们把my、name这样的数据叫做term，[1,2]这样的叫做posting list(倒排列表)。如果term的数量有成千上万个，那么按表3排列去寻找term的值还是会慢。为了提升term和posting list的查询效率,我们需要分别引入检索技术和压缩技术：

1、 检索技术

检索技术的两个重要数据结构: Term Dictionary、Term Index。

·Term Dictionary：

Term dictionary是词项字典，包含了每个字段的被分词后的term列表。

词项字典在磁盘上是以分block的方式保存的，一个block内部利用公共前缀压缩。用二分查找的方式，比全遍历更快地找出目标的 term；但是term自身数量还是很大，为了实现把term缓存到内存中，需要进一步的处理，建立词典索引(term index)。

·Term Index：

Term Index是词典索引，其中词典索引文件是词典的一个索引，以便词典可以被随机访问。词典索引文件是会被全部加载到内存中去的。

词典索引把Term按前缀的形式拆成一棵字典树（如图2），再结合FST(Finite-State Transducer)的压缩技术，可以使整个term index以树的形式缓存到内存中。从term index查到对应的term dictionary的block后，然后再去磁盘直接找到term，大大减少了磁盘随机读的次数。

图 2  term字典树

2、Posting List压缩技术：Roaring Bitmap

谈到Roaring Bitmap就要先了解bitmap，bitmap是一种数据结构，可用于记录大量的0-1状态。与Posting List 的对应关系如下：

假设postingList=[3,5,7,10,11,15]，则bitmap可以表示成：

[0,0,0,1,0,1,0,1,0,0,1,1,0,0,0,1]。如图3所示：

图 3 列表数据转换成BitSet数据图

从上可以看出来bitmap分别用1和0来表示该位置存在和不存在数值，这种方法是用1个byte代表8个文档。不过当数据量大时，仍然会消耗很多内存，所以出现了压缩率更高的Roaring Bitmap。因为posting list存储的是文档的id，所以Elasticsearch对posting list的压缩做了两件事：排序和将大数变小数。

如图4所示，假设posting list的值为：[62,246,252,278,285,310]：

图 4 bitmap压缩步骤图

bitmap压缩步骤：

当step1中出现的增量很大时，比如使用bitmap压缩时有些块最大值转换成二进制超过20bit位，则这些块的每个数还是需要至少2.5bytes(未压缩时是int，占4btyes)。由此可见，这种压缩方式还是不够高效，需要进一步优化，所以Lucene使用的数据结构叫做Roaring Bitmap。如图5所示:

图 5 Roaring Bitmap压缩步骤图

Roaring Bitmap 压缩步骤为：

要注意的是每一块最多有65536个值，当某一块的值超过了4096个时，可以转化为bitmap存储。当值的个数低于4096时用数组比较省空间，高于4096时用bitmap比较省空间，可以最大限度地避免内存浪费。

每次启动Elasticsearch实例时，都会启动一个节点。连接节点的集合称为集群。增加节点数量能提升ES的高性能和高可用性。但要注意服务器之间的硬件配置要相近，避免在同一台服务器上部署多个节点。

在ES中，文档和索引被分成多个碎片，这些碎片叫做分片。分片产生的目的是为了实现分布式，而分布式的好处之一就是实现“高可用性”。但是，在分片大小和分片数量方面，存在许多性能方面的考虑和权衡取舍。在分片数量方面，由于每个分片都使用内存和 CPU 资源，分片不是越多越好，而应当视情况而定，与节点数量相匹配。在大小方面，如果没有硬性限制，10GB 到 50GB 之间的分片往往效果很好。

ES 默认安装后设置的内存是 1GB，对于现实业务来说，这个设置太小了，一般生产建议不要少于16G。ES是比较依赖内存的，并且对内存的消耗也很大，内存对ES的重要性甚至是高于CPU的，所以即使是数据量不大的业务，为了保证服务的稳定性，在满足业务需求的前提下，我们仍需考虑留有不少于20%的冗余性能。

磁盘在现代服务器上通常都是瓶颈。ES重度使用磁盘，磁盘能处理的吞吐量越大，节点就越稳定。为了优化磁盘，生产环境可以考虑把节点冷热分离，“热节点”使用SSD做存储，可以大幅提高系统性能；冷数据存储在机械硬盘中，降低成本。也可以使用raid 0，条带化RAID会提高磁盘IO，代价显然就是当一块硬盘故障时整个就故障了。