Javaの新鮮なビジネスプラットフォーム - 大規模な検索ElasticSearchアーキテクチャの設計と実際のソースコードの解析における電気の供給業者
新鮮な電気の供給業者の検索エンジンの機能
我々はすべて知っているように、標準的な検索エンジンは、3つの主要な部分に分割され、最初のステップは、クローラシステムであり、第2のステップは、データ分析である、第3のステップは、検索結果です。まず、すべてのデータは、通常、MicrosoftのデータベースまたはOracleデータベースを構成されているので、電気のサプライヤー検索エンジンクローラーシステムは、なかったので、我々はコンテンツを見つけるために別の場所に行くことを継続して「クローラー」としてBaiduのは好きではありませんもちろん、実際には、電気の供給者は、独自の「クローラー」システム、友人クロールの通常価格を持って、その後、彼自身の調整に。
第二点は、一般的に検索するために使用されるよりも、実際には電力会社検索エンジンフィルタリングです。検索自体よりもさらに大きいです。フィルタリングとは何ですか？一般的には、当社のウェブサイト、関連するすべてのブランドまたは他の分類を選択し、何か、おむつなどのキーワードの検索を買うには、私たちの前に提示されます。Baiduのために、どのような言葉は、それがニュースであれば、それは時間のフィルタオプションを持っているかもしれないものの単語が検索、です。
ように賞賛のプロパティをソートするためのサポート、販売、レビュー、価格とを含む、様々な寸法の仕分け支持する第3、電気の供給業者の検索エンジン。そして、リアルタイムデータの要件は非常に高いです。、Baiduのは、含まれ、このようないくつかのヘビー級のポータルなどの一般的な検索エンジン、唯一の非常に重要なサイトでは、非常に高速ですが、非常に少ないトラフィックは、これらのサイトには、月に一度だけクロールできます。データの電気供給業者の検索、リアルタイムの要件は、主に価格と在庫の二つの側面に反映されています。
別の電気の供給、検索エンジンの機能は、品物を失っていない、我々は淘宝網を持っているなど、Lynxは検索ショップをオープンし、その後、最終的活動に従事ではなく、これは耐え難いです。また、電気の供給業者の検索エンジンと推奨システムと広告システムがあるため、検索エンジンのトラフィックの寄与のマージされている最大のであるので、我々はすべての広告システム統合にお話したいと思います。もちろん、非常に重要な存在である、高可用性を保証することで、ダウンすることはできません。
電気サプライヤー検索エンジンアーキテクチャ
一般的な検索エンジンと電気の供給業者の検索エンジンは非常に異なっているため、そのアーキテクチャデザインもユニークです。まず、検索エンジンの実装が多く存在している、グーグル、Baiduは、Sogouのこの非常に大企業、そこJingdongは、淘宝網、详细な電気の供給業者の検索エンジンは、多くの中小の電気プロバイダは、オープンソースを使用することを好むことがあります検索エンジン。全体的に、これらは、次の方法のいくつかのものがあります。
最初は「Luceneの+自分のパッケージは」のみ検索、パッケージ、すべての背後にあるESのために使用され、これら二つは完全なソリューションですが、またその後、唯一の良いビジネスロジックを展開する必要があるすべてのもののインデックス、検索結果その上に。
第二は、LuceneをベースとJava5の開発、全文検索サーバーを使用して、高性能でSolrに、です。同時に設定可能なスケーラブルで最適化されたクエリのパフォーマンスを実現し、フル機能の管理インタフェースを提供しながら、それは非常に良いですが、Luceneクエリ言語よりも豊富に提供するために拡張されました全文検索エンジン。
第三はElasticSearchあり、これはLuceneをベースと検索サーバーです。これは、RESTfulなWebインターフェイスに基づいて、フルテキスト検索エンジンの分散型マルチユーザ機能を提供します。ElasticsearchはJavaで書かれた、と公表Apacheのライセンス条件の下でオープンソースとしてされ、使用中も非常に多く存在しています。
ここでは、検索エンジンが独自の実装であるとき、それを言及します。さて、新興のインターネット企業は、主に第一又は一般的に三使用されるデータよりも二、大きなを使用しています。
電気供給者の検索エンジンは、標準モジュールを来ります
我々は、検索エンジンを所有している場合次に、私は、話をしたい、そして、何が（図は電気の供給業者の検索エンジンの標準モジュールです）、実際には、だけでなく、検索エンジンの検索、他の検索経由に加え、電力供給者の検索エンジンで実装する必要がありますエンジンは、標準の使用です。
検索モジュールは、最初はユーザの検索条件に応じて、純粋なアルゴリズムを達成するために、分析するためのユーザの意図です。たとえば、ユーザーの検索語は「黒い袋」で、実際には、ユーザの意図は、黒のバッグを購入することですが、この「パッケージ」は、他の言葉と組み合わせることができる、でも、検索結果に「パン」があるかもしれません。だから、検索システムに伝える、行うには、クエリの解析システムを必要とする、あなたではなく、生鮮食品よりも、分類に行く服や靴の主要なする必要があります。
C ++を使用して、技術レベル、详细にデザイン。あなたは良いシステムパフォーマンスを構築する場合、古い小さな会社のいくつかは、我々は、C ++やC言語を使用しています。ただ详细は、実際には、多くの企業は、Cや検索エンジンのC ++実装を使用しているわけではありません。
データ更新モジュール
第二个模块就是数据更新模块，该模块负责生成索引。而数据中心模块主要做的事情，就是将原始的结构化数据，变成一个可供检索系统使用的搜索数据库。当然，数据更新模块和检索模块是分开还是合并呢？其实从本质上讲，都是一堆代码，完全可以写在一个进程里。当然，也可以分开，通过网络往外输入，各自都有道理。第一种是简单粗暴型的，如果是普通电商，像生鲜电商，数据量不大，实时性、季节性很强，就可以把两个系统用一个进程来完成。但是如果到了百万、千万甚至上亿级别的话，就不可能部在一台机器上了。
上图就是当两个系统合并在一起的时候，红色部分就是检索系统，黄色部分是上游产生数据的系统，如果是淘宝的话，对接就是淘宝的商户，当当网对接是市场部的人员，他们将数据录入系统，推到数据库，然后向下进行传送，最终建立一个索引。
上图中的蓝色部分就是业务逻辑，因为电商的搜索引擎业务需求量非常高，尤其是现在大家都喜欢用手机进行购物，像手机专享价就是一个新的业务，这也意味着需要一个专用的模块来处理这些商用的逻辑。
此外，就是用户行为的分析，我们搜集到的日志还有其他相关的数据都会存到 Hadoop 集群上去，通过离线计算，然后传给商业模块或者排序模块进行排序和打分，并提供给用户更好的使用体验。
出问题是不可避免的！如何解决？
虽然整理来看，设计的思路是非常合理的，但是还是会出现问题。一般而言，一个成熟的电商搜索系统，它的问题都很集中，要这几种情况：首先就是 Bug，当然这是所有系统都会遇到的问题；第二个就是并发，但是搜索系统是没办法进行分库分表，所以能做的就是索引切分；最后一点就是监控，包括问题追踪、日志系统和监控系统，那么为了解决这些问题，我们应该怎么做？
首先，针对 Bug 问题，只能靠自动化运维去解决（这里也推荐使用 OneAPM 工具）；第二个就是高并发的问题，目前主要是靠缓存和横向扩展。而缓存和横向扩展怎么应用到系统中去，这个很关键。很多人也说可以换一种语言，比如讲 Python 换成 C++，但实际情况下，换语言并不能解决并发的问题，好的数据结构的设计比换一种语言更能提高性能，所以一般解决高并发问题的也就是缓存和横向扩展。
第三个就是使用用 FLUME 日志系统（Flume 是 Cloudera 提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume 支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume 提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力）。其实，Flume 会把集群上每一个节点的日志全都收集起来，这样做起来有两个好处，第一是现场出问题，可以先回滚出 Bug，然后进行查询。第二个就是对日志进行搜集，然后做用户行为分析，查看用户点击了多少次，从何处导入的流量等等，从而便于更好的进行排序。
然后讲一下缓存的问题。一般搜索的缓存可能分为两级缓存，据我观察，像搜狗可能是使用页面级缓存，而百度可能用的是索引级的缓存。比如在搜狗搜索一个词，开始时可能需要 40 毫秒，然后再搜的话，就可能一下子降到 1 毫秒。这就是页面级缓存。而百度可能第一次搜索用了 40 毫秒，第二次就是 25 毫秒，它并不是把页面给缓存下来，而是将索引的倒排链缓存，级别其实是不一样的。
电商搜索很多使用的是两级缓存，对于特别热门的词汇，我们可以做页面级缓存，而页面级缓存的时间只有 15 秒到 20 秒。但是像价格这样的东西不能缓存，需要前台页面去反拉价格。第二级就是索引级别的缓存，实际上也是自建的一个缓存系统。另外，排序也有缓存，因为排序的结果不太会有太大的变化。
上图是当当的搜索架构，这里有一个集群是做数据分析的，上面备满了数据。
首先，集群之间采用什么样的通讯方式？我们主要使用 ZMQ（这是一个简单好用的传输层，像框架一样的一个 socket library，使得 Socket 编程更加简单、简洁和性能更高。是一个消息处理队列库，可在多个线程、内核和主机盒之间弹性伸缩）。原因其实只有一个，就是快，非常快，比较适合数据量比较大的业务。
如何避免冷启动？
最后就是冷启动的问题，这个问题是很多电商网站都很头疼的问题。尤其是随着电商网站的商品数量达到一定量级的时候，比如已经上亿了，像淘宝、天猫的话应该更多。如果重建了一次索引需要启动，或者新上线了一个业务模块，需要重启系统，是很麻烦的。
当然，当集群大了以后有很多方法，比如分开启动之类的，至于技术嘛，一般索引的加载都是使用 Lunix 标准的 MMAP（MMAP 将一个文件或者其它对象映射进内存。文件被映射到多个页上，如果文件的大小不是所有页的大小之和，最后一个页不被使用的空间将会清零。MMAP 在用户空间映射调用系统中作用很大），这样启动速度会很快，但是系统会有预热时间，前面一些时间的查询会比较慢
如果数据量不是特别大的话，而且现在内存也那么便宜，完全可以将数据一次性读入内存，因为 mmap 的操作毕竟性能没有直接内存来得快。
第三种的话，就是尽量减少做全量数据的频率，避免整个系统的重启，这需要定期做一下索引的优化，把没用的索引干掉。
如果是新上了一个业务模块需要重启集群，这样的事情最好不要发生，这就是架构有问题了，将业务模块变成外部的模块或者插件进行上线才是正确的，不然每上线一个模块需要重启集群，这谁都受不了。