編碼問題，誰不想避其鋒芒；
一、業務背景
在搜索引擎的功能上，曾經遇到過這樣一個問題，資料庫中某個公司名稱中存在特殊編碼，盡管資料已經正常同步到索引中，但是系統中關鍵詞始終也無法匹配到該公司；
然后在庫中模糊匹配，將公司名稱復制到搜索框中，這樣就可以正常命中索引，那么問題也就很清楚了，這種資料"隱身"的情況，即看著是同一個字，但是實際上不是，通常由特殊編碼引起的；
通過表單進行資料采集是常用的業務手段，但是如果表單存在多個任意輸入的文本框，這樣獲取的資料在質量上可能存在很多欠缺，尤其針對一些核心欄位，嚴謹的校驗規則十分有必要；
如果站在資料層面來看，雖然獲取多維度資料有利于全景識別，但是各個維度的值準確與否或質量高低才是關鍵，對于多數業務場景來說，只依賴資料物體的部分屬性，更多還是在于資料維度的質量；
提高資料質量的手段中，最行之有效的方式就是盡可能對欄位維度提供列舉值，將資料內容限制在約定的范圍內，其次就是校驗規則需要嚴謹，以此確保業務資料的高質量；
二、字典服務
在分布式系統架構中，比較常見的基礎服務層通常有：調度、快取、檔案、訊息、字典等，下面就來詳細的聊聊字典服務的設計與業務協作的邏輯；首先看一看互動邏輯：
在字典服務中，通常管理公共的常量與資料列舉值的維護；常規情況下，在業務表單加載的時候，從字典服務中讀取各維度列舉值，在表單提交的時候，校驗相關列舉欄位，以此提高內容的質量；
在字典服務中提供的列舉值，根本目的是為了確保資料值的統一性，盡可能的避免同一個資訊用兩種方式描述，比如編程標簽："JAVA"與"Java"，雖然從程式角度可以規避識別，但實際上是可以避免的；
從字典服務常見的內容管理來看，通常包括：常量、狀態描述、業務標識；行業、標簽、地址、學校等資料碼表；其最大的特點就是在系統中被全域復用和識別；
三、細節設計
1、維護方式
對于字典資料的維護，通常使用兩種手段：列舉類管理，碼表存盤，引數表存盤；如何選擇對應的方式，更多是取決于資料的屬性：
- 列舉類：維護基本不會改變的欄位，比如資料的常規狀態描述；
- 碼表：通常資料具有層次或者級聯關系，比如地址和行業中的多級聯動；
- 引數表：即時要求很高，例如欄位列舉值的定義，需要動態實時管理；
不管使用那種方式管理字典資料，都需要增強業務語意的描述，這樣在業務表單中通過相應標識讀取對應列舉選項即可，并且攔截范圍之外的提交動作；
2、資料加載
字典資料的查詢通常采用Cache-Aside快取模式，即查詢優先訪問快取資料，命中則回傳資料；否則訪問庫表資料，獲取資料后回傳頁面并同步快取中；在控制中心做內容修改后也需要再次同步快取；
字典服務雖然并不復雜的，但是系統訪問卻十分頻繁，如果出現例外情況很容易對業務產生大規模的影響，既要考慮并發訪問的流量，又要設計合理的查詢降低加載時間，避免對流程產生有感知的影響；
3、資料修改
不管是采用字典方式加載列舉值，還是采用任意輸入的方式，都會面對一個無法避開的問題，欄位值在業務開發中不斷優化，則需要對資料進行清洗，至于資料清洗的流程在之前有詳細的總結過，這里不再贅述，
四、資料意識
資料字典本身的邏輯比較簡單，但是如果放在資料體系中，這是一種基礎的意識，在資料中很容易出現同名但定義不同，或者定義相同但名稱不同，這會給資料分析帶來很多不必要的麻煩；
所以基于資料字典的方式，明確資料口徑同時避免業務語意產生分歧，尤其對于漢語來說，"意思"到底是什么意思?
五、參考原始碼
編程檔案：
https://gitee.com/cicadasmile/butte-java-note
應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/502452.html
標籤：其他