? ? ? ?考慮到ElasticSearch優(yōu)秀的索引和檢索性能完丽，項目中使用ES作為前臺搜索引擎，但是在創(chuàng)建和更新ES數(shù)據(jù)的時候拇舀，由于種種原因逻族，可能會出現(xiàn)ES更新失敗，造成ES數(shù)據(jù)和數(shù)據(jù)庫最新真實數(shù)據(jù)出現(xiàn)不一致的現(xiàn)象骄崩。在做項目的過程中整理了一下四種解決方案：
1聘鳞、開一張表專門記錄創(chuàng)建和更新ES數(shù)據(jù)失敗的信息（比如我們項目中主需要記錄主表ID，更新數(shù)據(jù)時根據(jù)ID組裝數(shù)據(jù)）刁赖，然后設(shè)置一個定時任務(wù)搁痛，定時向ES更新失敗的數(shù)據(jù)；
2宇弛、小批量鸡典、多批次更新；通俗講就是設(shè)置固定時間間隔枪芒，然后更新先前一段時間的數(shù)據(jù)彻况，比如每隔10分鐘，全量更新前20分鐘的數(shù)據(jù)舅踪；缺點就是有些數(shù)據(jù)正常的數(shù)據(jù)也更新了纽甘，消耗性能；
3抽碌、大批量悍赢，小批次更新；和第二條闡釋類似，比如在每天夜晚2點種左权，全量更新某一時間段范圍(1或2天)皮胡、某一標簽或類別（商品、服務(wù)）赏迟、某一地區(qū)屡贺、某類用戶畫像等等可以分類分區(qū)的數(shù)據(jù)；
4锌杀、定時任務(wù)甩栈，異步全量查詢數(shù)據(jù)庫表，開多線程糕再，更新ES量没；消耗大量資源，且全量更新數(shù)據(jù)庫表也不科學(xué)亿鲜；
? ? ? ? 我司另一個項目組采用方案2允蜈，但是從消耗資源和技術(shù)設(shè)計角度講，我認為上述四條方案中蒿柳，方案1最佳饶套，方案4最差。
? ? 有考慮不周或不對的地方垒探，還請各路大神敬請留言妓蛮，不吝賜教
