Solr 如何處理日期類型

Solr日期類型處理

Solr 如何處理日期類型

日期格式與實際時間晚8小時

solr控制檯查詢出的日期格式與實際時間少8個小時，由於咱們是東八區，推測是時區的緣由。

形成這個問題的根源是東八區的人不習慣零時區的時間。其實，solr索引存儲的時間並無少8小時，只是在時間格式化的時候，用的是UTC時間，由於咱們是東八區，UTC是零時區時間，因此日期展現的時候，看起來是慢了8小時。

誤區一:修改寫入時間

爲了解決這個問題，在solrJ寫入時間時，修改時間，增長8小時。這種方案至關於篡改了數據，是不可取的。

誤區二:修改服務器時區

爲了解決這個問題，修改服務器的時區（或solr的時區）。集羣服務器時間配置應該保持一致，不該該爲了解決局部問題而破壞總體，因此不建議修改服務器時區。

Solr日期格式的傳輸與存儲

• Solr日期類型在索引文件中存儲的是long類型

經過Date的getTime獲取long值，經過new Date(longValue)轉換爲時間。

• Solr文本格式傳輸:日期爲UTC標準格式(如：1972-05-20T17:33:18.772Z)

json、XML格式都屬於文本格式。

SolrJ和Solr服務器都是根據本地時區來轉換UTC，同時也是根據本地時區來將UTC字符串轉換爲Date類型。

Solr的Web控制檯就是採用的文本傳輸格式，因此看見的時間是UTC格式字符串(滯後8小時)。

• Solr二進制傳輸：日期爲long類型

採用二進制傳輸時，與時區無關。

long值是經過date.getTime直接獲取，

long值轉換Date時，直接new Date(longValue);

文本傳輸&二進制傳輸

• 文本傳輸

優勢：保證UTC時間一致性，即使時區不一致的服務器依然能保證UTC時間的一致性

缺點：是數據報文比較大，性能很差。

適合場景：人機交互。

• 二進制傳輸

優勢:數據緊湊，性能好。

缺點：不考慮時區，沒法保證UTC時間一致。

場景：服務器間交互。通常企業集羣的服務器時鐘是統一配置的。

源碼分析

  org.apache.solr.util.DateFormatUtil源碼：
  文本格式日期處理相關

  public static final TimeZone CANONICAL_TZ = UTC;
  public static final Locale CANONICAL_LOCALE = Locale.ROOT;
  public static final String NOW = "NOW";
  ...
  static class ISO8601CanonicalDateFormat extends SimpleDateFormat {

    protected NumberFormat millisParser
        = NumberFormat.getIntegerInstance(CANONICAL_LOCALE);

    protected NumberFormat millisFormat = new DecimalFormat
        (".###", new DecimalFormatSymbols(CANONICAL_LOCALE));

    public ISO8601CanonicalDateFormat() {
      super("yyyy-MM-dd'T'HH:mm:ss", CANONICAL_LOCALE);
      this.setTimeZone(CANONICAL_TZ);
    }
    ....
  }
  ...   

 org.apache.solr.common.util.JavaBinCodec源碼：
 二進制格式日期處理相關

 if (val instanceof Date) {
    daos.writeByte(DATE);
    daos.writeLong(((Date) val).getTime());
    return true;
 }