可靠性
1. 搜索平台应用可靠性
搜索平台的进程视图如下：
下面分别介绍这些进程的可靠性方案：
1.1 Listener应用
Listener应用只是消息转发的功能，将MQ消息转发到用户的消息队列中。
Listener目前有两个应用，分别部署在不同的服务器上。两个应用属于双机热备，当主Listener应用出现问题时备Listener应用会激活并继续工作。因为我们使用的MQ持久化订阅，这种方式可以保证在Listener应用主备切换的时间内消息不丢失。
1.2 MsgQoS应用
MsgQoS应用主要是对MQ消息的流控、处理失败消息的重做等QoS方面的工作。
MsqQoS目前有两个应用，部署在不同的服务器上。两个应用属于双机热备，当主MsqQoS应用出现问题时备MsgQoS应用会激活并继续工作。搜索平台通过Zookeeper实现的分布式锁实现了该高可用方案。
1.3 Suggest应用
可靠性方案同MsgQoS，属于双机热备。
1.4 Worker应用
Worker应用基于Celery框架，多个Worker应用之间组成高可用集群，该集群自动负载均衡，新节点上线后自动加入集群。
1.5 WebServer、Management
这两个应用都是对外提供Web服务的，通过前置Nginx和HAProxy，可以实现高可用方案。
1.6 RestFulQoS
该应用主要是处理RestFul请求的QoS方面的工作，该应用从Kafaka中订阅失败的RestFul请求，然后根据设置的QoS策略，通过操作的时间戳对消息重做。
该应用的可靠性基于Kafaka的Consumer Group方案，多个RestFulQoS组成一个高可用集群，当一个RestFulQoS应用失败后，其它的应用会接管。
2. 外部数据可靠性
2.1 Elasticsearch集群正常工作状态
目前搜索平台的数据都存储在Elasticsearch，如果Elasticsearch集群发生故障，对于搜索平台是灾难性的。没有数据，哪怕搜索平台的应用再健壮可靠，也是无源之水。Elasticsearch集群本身就是一个高可用的方案，之前因为我们的设计和使用问题，发生了多次Elasticsearch集群宕机的情况，导致整个搜索平台无法对外提供服务。
我们将签约用户和非签约用户数据区分开来，分成签约用户Elasticsearch集群和非签约用户Elasticsearch集群，另外还创建了一个备份Elasticsearch集群，备份集群的数据为生产集群的前一天数据。
Worker主要是保持搜索平台和业务系统数据一致性，WebServer对业务侧提供查询接口。
2.2 签约用户Elasticsearch集群发生故障
例如11点的时候签约用户Elasticsearch集群发生故障，此时对签约用户的商品数据的写入和查询都不可用。MsgQoS应用会把Worker应用写失败的消息记录下来，放到该用户的重做消息队列中。
2.3 切换签约用户Elasticsearch集群
此时搜索平台管理员收到告警后，通过人工诊断出签约用户Elasticsearch集群发生故障，此时管理员通过搜索平台管理接口发送一个签约用户Elasticsearch集群切换RestFul请求，搜索平台会将WebServer对所有签约用户的查询RestFul请求切换到备份Elasticsearch集群，切换过程由程序自动完成，无需重启任何应用。但是Worker应用对签约用户的数据写入不会切换到备份集群，下面分析为何要采用这样的切换方式。此时搜索平台状态变更为：
切换后搜索平台可以对外提供RestFul请求，返回结果为前一天数据。但是搜索平台的所有通过MQ消息的写入请求都会失败。反应到用户侧的结果是：用户可以在网站可以搜索和看到今天0点前的商品，今天的0点以后添加的商品都看不到；用户可以对商品正常下单等流程；用户无法编辑商品，即编辑商品在搜索结果中看不到，比如下架一个商品，但是该商品仍然可以搜索到。这相当于搜索平台提供了一个降级的服务，以保证主流程可用。
2.4 回切签约用户Elasticsearch集群
经过处理，签约用户Elasticsearch集群于12点恢复，此时管理员发送一个签约用户Elasticsearch集群回切RestFul请求，搜索平台会自动把查询的RestFul请求回切到签约用户Elasticsearch集群。此时搜索平台查询、数据写入功能都已经正常。
回切后唯一的问题的从集群发生故障的11点到集群恢复的12点之间的用户对商品数据的变更都已经丢失了，换句话说，此时签约用户Elasticsearch中的数据是用户11点的数据，如何把11点到12点之间的数据找回来呢？上面提到Worker节点一直没有切换Elasticsearch，因此此时间段用户的商品变更请求都是失败的，MsgQoS应用会把失败的消息都记录到该用户的失败消息队列后，当集群恢复后，MsgQoS会根据失败消息重做策略将这些失败的消息重新提交给Worker执行。因此11点到12点的数据最终还是会同步回来的。
