技術交流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功能！