技术交流qq群： 659201069
概述：solr支持单机和cloud两种运行模式，在cloud模式，会出现同一个查询条件数据不一致的问题，这其实就是分布式系统数据一致性问题，根据Eric Brewer教授的CAP定理，一个布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能满足其中两项。因为solr在分布式模式下运行，自然也会出数据一致性问题，而且这个问题目前敝人没有找到解决办法（敝人为此研究了solr源码，但没有找到根源所在，如大神有解决此问题的办法恳请指正），在实际工程中采取的措施是尽可能的减少commit的频率！本文重点分析产生此问题的原因！
下面结合敝人在实际工程中遇到的问题，进行一步步分析！
第一：问题现像，每次查询solr，如下图所示，
为什么会出现这种问题呢，先来看下solr架构图
经过本人分析，这是solr分片后，每个副本的数据不一致造成的，也是所有分布式系统都面临，而都无法彻底解决的问题！更准确的说这是调用solr的delete接口造成的，
在solr里面delete的过程是先调用query接口看要删除的数据是否存在，如果存在只是把id加入到killlist表里，要到段合并时才能真正的删除，在这个过程中，出现了问题造成在某个分片上数据有脏数据产生，所以在生产环境中，尽量不要调用delete接口，或者少调用，采用update的方式，来实现删除数据的目的，例如在数据中定义一个字段is_live来代表数据是否有效，但这样又会有过程的无效数据在solr里面，这就是一个架构的问题了，如何清理这种无效数据，本文不再讨论
下面看下具体的原因：先看下图
sku_seq是primary_key,在solr中唯一，但在此处出现了两条，原因是其中的一个副本的数据出现了问题，如果把shards参数换成另一个副本，数据就是正确的，这就是问题的原因，副本的数据不一致，可以说是solr本身的一个BUG,目前没有解决办法，只能尽可能的减少调用delete功能！