> 編碼問題，誰不想避其鋒芒；

# 一、業務背景

在搜尋引擎的功能上，曾經遇到過這樣一個問題，資料庫中某個公司名稱中存在特殊編碼，儘管資料已經正常同步到索引中，但是系統中關鍵詞始終也無法匹配到該公司；

然後在庫中模糊匹配，將公司名稱複製到搜尋框中，這樣就可以正常命中索引，那麼問題也就很清楚了，這種資料"隱身"的情況，即看著是同一個字，但是實際上不是，通常由特殊編碼引起的；

透過表單進行資料採集是常用的業務手段，但是如果表單存在多個任意輸入的文字框，這樣獲取的資料在質量上可能存在很多欠缺，尤其針對一些核心欄位，嚴謹的校驗規則十分有必要；

如果站在資料層面來看，雖然獲取多維度資料有利於全景識別，但是各個維度的值準確與否或質量高低才是關鍵，對於多數業務場景來說，只依賴資料實體的部分屬性，更多還是在於資料維度的質量；

提高資料質量的手段中，最行之有效的方式就是儘可能對欄位維度提供列舉值，將資料內容限制在約定的範圍內，其次就是校驗規則需要嚴謹，以此確保業務資料的高質量；

# 二、字典服務

在分散式系統架構中，比較常見的基礎服務層通常有：排程、快取、檔案、訊息、字典等，下面就來詳細的聊聊字典服務的設計與業務協作的邏輯；首先看一看互動邏輯：

![](http://img.blog.itpub.net/blog/2022/08/22/ce00a8a231f6817f.png?x-oss-process=style/bb)

在字典服務中，通常管理公共的常量與資料列舉值的維護；常規情況下，在業務表單載入的時候，從字典服務中讀取各維度列舉值，在表單提交的時候，校驗相關列舉欄位，以此提高內容的質量；

在字典服務中提供的列舉值，根本目的是為了確保資料值的統一性，儘可能的避免同一個資訊用兩種方式描述，比如程式設計標籤："JAVA"與"Java"，雖然從程式角度可以規避識別，但實際上是可以避免的；

![](http://img.blog.itpub.net/blog/2022/08/22/479d4666353f4357.png?x-oss-process=style/bb)

從字典服務常見的內容管理來看，通常包括：常量、狀態描述、業務標識；行業、標籤、地址、學校等資料碼錶；其最大的特點就是在系統中被全域性複用和識別；

# 三、細節設計

## 1、維護方式

對於字典資料的維護，通常使用兩種手段：列舉類管理，碼錶儲存，參數列儲存；如何選擇對應的方式，更多是取決於資料的屬性：

- 列舉類：維護基本不會改變的欄位，比如資料的常規狀態描述；
- 碼錶：通常資料具有層次或者級聯關係，比如地址和行業中的多級聯動；
- 參數列：即時要求很高，例如欄位列舉值的定義，需要動態實時管理；

![](http://img.blog.itpub.net/blog/2022/08/22/b7ee32eca6986e65.png?x-oss-process=style/bb)

不管使用那種方式管理字典資料，都需要增強業務語義的描述，這樣在業務表單中透過相應標識讀取對應列舉選項即可，並且攔截範圍之外的提交動作；

## 2、資料載入

字典資料的查詢通常採用Cache-Aside快取模式，即查詢優先訪問快取資料，命中則返回資料；否則訪問庫表資料，獲取資料後返回頁面並同步快取中；在控制中心做內容修改後也需要再次同步快取；

![](http://img.blog.itpub.net/blog/2022/08/22/83d731f16f159779.png?x-oss-process=style/bb)

字典服務雖然並不複雜的，但是系統訪問卻十分頻繁，如果出現異常情況很容易對業務產生大規模的影響，既要考慮併發訪問的流量，又要設計合理的查詢降低載入時間，避免對流程產生有感知的影響；

## 3、資料修改

不管是採用字典方式載入列舉值，還是採用任意輸入的方式，都會面對一個無法避開的問題，欄位值在業務開發中不斷最佳化，則需要對資料進行清洗，至於資料清洗的流程在之前有詳細的總結過，這裡不再贅述。

# 四、資料意識

資料字典本身的邏輯比較簡單，但是如果放在資料體系中，這是一種基礎的意識，在資料中很容易出現同名但定義不同，或者定義相同但名稱不同，這會給資料分析帶來很多不必要的麻煩；

所以基於資料字典的方式，明確資料口徑同時避免業務語義產生分歧，尤其對於漢語來說，"意思"到底是什麼意思?

# 五、參考原始碼

```
程式設計文件：
https://gitee.com/cicadasmile/butte-java-note

應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent
```

字典服務的設計與管理

相關文章