前幾天，有位小伙伴問(wèn)了我一個(gè)問(wèn)題：加密的手機(jī)號(hào)如何模糊查詢？

我們都知道，在做系統(tǒng)設(shè)計(jì)時(shí)，考慮到系統(tǒng)的安全性，需要對(duì)用戶的一些個(gè)人隱私信息，比如：登錄密碼、身份證號(hào)、銀行卡號(hào)、手機(jī)號(hào)等，做加密處理，防止用戶的個(gè)人信息被泄露。

很早之前，CSDN 遭遇了 SQL 注入，導(dǎo)致了 600 多萬(wàn)條明文保存的用戶信息被泄。

因此，我們?cè)谧鱿到y(tǒng)設(shè)計(jì)的時(shí)候，要考慮把用戶的隱私信息加密保存。

常見(jiàn)的對(duì)稱加密算法有 AES、SM4、ChaCha20、3DES、DES、Blowfish、IDEA、RC5、RC6、Camellia 等。

目前國(guó)際主流的對(duì)稱加密算法是AES，國(guó)內(nèi)主推的則是SM4。

無(wú)論是用哪種算法，加密前的字符串和加密后的字符串，差別還是比較大的。

比如加密前的字符串：蘇三說(shuō)技術(shù)，使用密鑰：123，生成加密后的字符串為：U2FsdGVkX1+q7g9npbydGL1HXzaZZ6uYYtXyug83jHA=。

如何對(duì)加密后的字符串做模糊查詢呢？

比如：假設(shè)查詢蘇三關(guān)鍵字，加密后的字符串是：U2FsdGVkX19eCv+xt2WkQb5auYo0ckyw。

上面生成的兩個(gè)加密字符串差異看起來(lái)比較大，根本沒(méi)辦法直接通過(guò) SQL 語(yǔ)句中的 like 關(guān)鍵字模糊查詢。

那我們?cè)撛趺磳?shí)現(xiàn)加密的手機(jī)號(hào)的模糊查詢功能呢？

1 一次加載到內(nèi)存

實(shí)現(xiàn)這個(gè)功能，我們第一個(gè)想到的辦法可能是：把個(gè)人隱私數(shù)據(jù)一次性加載到內(nèi)存中緩存起來(lái)，然后在內(nèi)存中先解密，再在代碼中實(shí)現(xiàn)模糊搜索的功能。

image.png

這樣做的好處是：實(shí)現(xiàn)起來(lái)比較簡(jiǎn)單，成本非常低。

但帶來(lái)的問(wèn)題是：如果個(gè)人隱私數(shù)據(jù)非常多的話，應(yīng)用服務(wù)器的內(nèi)存不一定夠用，可能會(huì)出現(xiàn) OOM 問(wèn)題。

還有另外一個(gè)問(wèn)題是：數(shù)據(jù)一致性問(wèn)題。

如果用戶修改了手機(jī)號(hào)，數(shù)據(jù)庫(kù)更新成功了，需要同步更新內(nèi)存中的緩存，否則用戶查詢的結(jié)果可能會(huì)跟實(shí)際情況不一致。

比如：數(shù)據(jù)庫(kù)更新成功了，內(nèi)存中的緩存更新失敗了。

或者你的應(yīng)用，部署了多個(gè)服務(wù)器節(jié)點(diǎn)，有一部分內(nèi)存緩存更新成功了，另外一部分剛好在重啟，導(dǎo)致更新失敗了。

該方案可能會(huì)導(dǎo)致應(yīng)用服務(wù)器出現(xiàn) OOM 問(wèn)題，也可能會(huì)導(dǎo)致系統(tǒng)的復(fù)雜度提升許多，總體來(lái)說(shuō)，有點(diǎn)得不償失。

2 使用數(shù)據(jù)庫(kù)函數(shù)

既然數(shù)據(jù)庫(kù)中保存的是加密后的字符串，還有一種方案是使用數(shù)據(jù)庫(kù)的函數(shù)解密。

我們可以使用 MySQL 的 DES_ENCRYPT 函數(shù)加密，使用 DES_DECRYPT 函數(shù)解密：

SELECT DES_DECRYPT('U2FsdGVkX1+q7g9npbydGL1HXzaZZ6uYYtXyug83jHA=', '123'); 

應(yīng)用系統(tǒng)中所有的用戶隱私信息的加解密都在 MySQL 層實(shí)現(xiàn)，不存在加解密不一致的情況。

該方案中保存數(shù)據(jù)時(shí)，只對(duì)單個(gè)用戶的數(shù)據(jù)進(jìn)行操作，數(shù)據(jù)量比較小，性能還好。

但模糊查詢數(shù)據(jù)時(shí)，每一次都需要通過(guò) DES_DECRYPT 函數(shù)，把數(shù)據(jù)庫(kù)中用戶某個(gè)隱私信息字段的所有數(shù)據(jù)都解密了，然后再通過(guò)解密后的數(shù)據(jù)做模糊查詢。

如果該字段的數(shù)據(jù)量非常大，這樣每次查詢的性能會(huì)非常差。

3 分段保存

我們可以將一個(gè)完整的字符串，拆分成多個(gè)小的字符串。

以手機(jī)號(hào)為例：18200256007，按每 3 位為一組進(jìn)行拆分，拆分后的字符串為：182,820,200,002,025,256,560,600,007，這 9 組數(shù)據(jù)。

然后建一張表：

CREATE TABLE `encrypt_value_mapping` (  `id` bigint NOT NULL COMMENT '系統(tǒng)編號(hào)',  `ref_id` bigint NOT NULL COMMENT '關(guān)聯(lián)系統(tǒng)編號(hào)',  `encrypt_value` varchar(255) NOT NULL COMMENT '加密后的字符串') ENGINE=InnoDB  CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='分段加密映射表'

這張表有三個(gè)字段：

• id：系統(tǒng)編號(hào)。
• ref_id：主業(yè)務(wù)表的系統(tǒng)編號(hào)，比如用戶表的系統(tǒng)編號(hào)。
• encrypt_value：拆分后的加密字符串。

用戶在寫(xiě)入手機(jī)號(hào)的時(shí)候，同步把拆分之后的手機(jī)號(hào)分組數(shù)據(jù)也一起寫(xiě)入，可以保證在同一個(gè)事務(wù)當(dāng)中數(shù)據(jù)的一致性。

如果要模糊查詢手機(jī)號(hào)，可以直接通過(guò) encrypt_value_mapping 的 encrypt_value，模糊查詢出用戶表的 ref_id，再通過(guò) ref_id 查詢用戶信息。

具體 sql 如下：

select s2.id,s2.name,s2.phone from encrypt_value_mapping s1inner join `user` s2 on s1.ref_id=s2.idwhere s1.encrypt_value = 'U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB'limit 0,20;

這樣就能輕松地通過(guò)模糊查詢，搜索出我們想要的手機(jī)號(hào)了。

注意這里的 encrypt_value 用的等于號(hào)，由于是等值查詢，效率比較高。

注意：這里通過(guò) sql 語(yǔ)句查詢出來(lái)的手機(jī)號(hào)是加密的，在接口返回給前端之前，需要在代碼中統(tǒng)一做解密處理。

為了安全性，還可以將加密后的明文密碼，用*號(hào)增加一些干擾項(xiàng)，防止手機(jī)號(hào)被泄露，最后展示給用戶的內(nèi)容，可以顯示成這樣的：182***07。

4 其他的模糊查詢

如果除了用戶手機(jī)號(hào)，還有其他的用戶隱私字段需要模糊查詢的場(chǎng)景，該怎么辦？

我們可以將 encrypt_value_mapping 表擴(kuò)展一下，增加一個(gè)type字段。

該字段表示數(shù)據(jù)的類型，比如：1.手機(jī)號(hào) 2.身份證 3.銀行卡號(hào)等。

這樣如果有身份證和銀行卡號(hào)模塊查詢的業(yè)務(wù)場(chǎng)景，我們可以通過(guò) type 字段做區(qū)分，也可以使用這套方案，將數(shù)據(jù)寫(xiě)入到 encrypt_value_mapping 表，最后根據(jù)不同的 type 查詢出不同的分組數(shù)據(jù)。

如果業(yè)務(wù)表中的數(shù)據(jù)量少，這套方案是可以滿足需求的。

但如果業(yè)務(wù)表中的數(shù)據(jù)量很大，一個(gè)手機(jī)號(hào)就需要保存 9 條數(shù)據(jù)，一個(gè)身份證或者銀行卡號(hào)也需要保存很多條數(shù)據(jù)，這樣會(huì)導(dǎo)致 encrypt_value_mapping 表的數(shù)據(jù)急劇增加，可能會(huì)導(dǎo)致這張表非常大。

最后的后果是非常影響查詢性能。

那么，這種情況該怎么辦呢？

5 增加模糊查詢字段

如果數(shù)據(jù)量多的情況下，將所有用戶隱私信息字段，分組之后，都集中到一張表中，確實(shí)非常影響查詢的性能。

那么，該如何優(yōu)化呢？

答：我們可以增加模糊查詢字段。

還是以手機(jī)模糊查詢?yōu)槔?/p>

我們可以在用戶表中，在手機(jī)號(hào)旁邊，增加一個(gè) encrypt_phone 字段。

CREATE TABLE `user` (  `id` int NOT NULL,  `code` varchar(20)  NOT NULL,  `age` int NOT NULL DEFAULT '0',  `name` varchar(30) NOT NULL,  `height` int NOT NULL DEFAULT '0',  `address` varchar(30)  DEFAULT NULL,  `phone` varchar(11) DEFAULT NULL,  `encrypt_phone` varchar(255)  DEFAULT NULL,  PRIMARY KEY (`id`)) ENGINE=InnoDB CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='用戶表'

然后我們?cè)诒４鏀?shù)據(jù)的時(shí)候，將分組之后的數(shù)據(jù)拼接起來(lái)。

還是以手機(jī)號(hào)為例：

18200256007，按每 3 位為一組，進(jìn)行拆分，拆分后的字符串為：182,820,200,002,025,256,560,600,007，這 9 組數(shù)據(jù)。

分組之后，加密之后，用逗號(hào)分割之后拼接成這樣的數(shù)據(jù)：,U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB,U2FsdGVkX1+qysCDyVMm/aYXMRpCEmBD,U2FsdGVkX19oXuv8m4ZAjz+AGhfXlsQk,U2FsdGVkX19VFs60R26BLFzv5nDZX40U,U2FsdGVkX19XPO0by9pVw4GKnGI3Z5Zs,U2FsdGVkX1/FIIaYpHlIlrngIYEnuwlM,U2FsdGVkX19s6WTtqngdAM9sgo5xKvld,U2FsdGVkX19PmLyjtuOpsMYKe2pmf+XW,U2FsdGVkX1+cJ/qussMgdPQq3WGdp16Q。

以后可以直接通過(guò) sql 模糊查詢字段 encrypt_phone 了：

select id,name,phonefrom user where encrypt_phone like '%U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB%'limit 0,20;

注意這里的 encrypt_value 用的like。

這里為什么要用逗號(hào)分割呢？

答：是為了防止直接字符串拼接，在極端情況下，兩個(gè)分組的數(shù)據(jù)，原本都不滿足模糊搜索條件，但拼接在一起，卻有一部分滿足條件的情況發(fā)生。

當(dāng)然我們也可以根據(jù)實(shí)際情況，將逗號(hào)改成其他的特殊字符。

此外，其他的用戶隱私字段，如果要實(shí)現(xiàn)模糊查詢功能，也可以使用類似的方案。

最后說(shuō)一句，雖說(shuō)本文介紹了多種加密手機(jī)號(hào)實(shí)現(xiàn)模糊查詢功能的方案，但我們要根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景來(lái)選擇，沒(méi)有最好的方案，只有最合適的。