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

一、業務背景

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

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

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

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

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

二、字典服務

在分散式系統架構中，比較常見的基礎服務層通常有：調度、緩存、文件、消息、字典等，下麵就來詳細的聊聊字典服務的設計與業務協作的邏輯；首先看一看交互邏輯：

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

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

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

三、細節設計

1、維護方式

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

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

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

2、數據載入

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

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

3、數據修改

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

四、數據意識

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

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

五、參考源碼

編程文檔：
https://gitee.com/cicadasmile/butte-java-note

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