虽然整理来看，设计的思路是非常合理的，但是还是会出现问题。一般而言，一个成熟的电商搜索系统，它的问题都很集中，要这几种情况：首先就是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的操作毕竟性能没有直接内存来得快。

第三种的话，就是尽量减少做全量数据的频率，避免整个系统的重启，这需要定期做一下索引的优化，把没用的索引干掉。

如果是新上了一个业务模块需要重启集群，这样的事情最好不要发生，这就是架构有问题了，将业务模块变成外部的模块或者插件进行上线才是正确的，不然每上线一个模块需要重启集群，这谁都受不了。（整理/OneAPM技术编辑王鹏 责编/仲浩）