91蜜臀在线视频免费,亚洲天堂福利视频,欧性猛交ⅩXXX乱大交,爱情岛一区二区,亚洲欧美在线视频一区,欧美黄色电影院,天天搞天天拍,激情尻逼久久

閱讀本文10分鐘，約3.8K字。

本文借助案例，分析了電商搜索商品的實現原理。

產品就能理解搜索做到什么程度、要準備哪些工作，以及輸出合格的PRD，并“指導”開發(fā)人員實現。

1、從一個bug說起

2、C端商城高并發(fā)搜索

3、商城搜索的一般機制

4、ES的引入，解決了什么痛點

5、總結和意義

從一次bug說起

操作過程：用導入方式，在后臺修改了商品的展示分類（即：再C端商城顯示的分類）。

預期：在商城中，選擇分類，可以查看到對應綁定的商品。

bug：結果在C端商城中，該分類下無該商品。而檢擦數據庫發(fā)現，該商品是綁有這個分類的。

調查原因：用導入的方式修改前端分類的時候，系統沒有把新分類同步到ES庫中。（ES庫可理解未提供商城查詢服務的中間庫，下文有詳解。）

處理辦法：將代碼調整為，導入方式修改的前端分類，也要觸發(fā)同步給ES。

結論：

（1）搜索引擎服務技術（ES）是神一般的存在，卻也是新手開發(fā)容易出問題的所在。

（2）該bug背后，值得產品經理透視搜索實現方案：比如搜索的機制……

C端商城的高并發(fā)搜索

我們普通做個列表的模糊查詢項，很簡單。輸入張三，就把張三豐和張三一起搜出來了。

產品經理寫這種方案似乎不用想。

但是為什么商城搜索的時候，就如此謹慎呢？

1、商品資料同步到商城C端

上述bug，發(fā)生在商品資料同步到商城C端這條路上。

商品后臺，是電商后臺體系中，較為簡單的板塊。但除了一點，那就是商品資料對C端的同步（支撐C端商城查詢）。

這種同步的場景來源，大致如下：

（1）上新品、開新門店，需要全量上架到商城；

（2）后臺修改商品資料，同步更新到商城；

（3）C端商城大量用戶查詢商品數據；

（4）C端商城初始打開頁面加載大量的商品資料；

（5）庫存價格同步（也有放在WMS對接商城端的，本質無差別）

事實上，C端商品的展示，主要有兩種情況：List（商品列表頁）和Detail（商品詳情頁）。

List包含商品標題、首圖、價格等，如上圖；

Detail包含商品的廠家、品牌、保質期、說明書等也就是點開每一個商品后的詳情頁面。

生活服務類電商（O2O）更特殊一點，不同開站城市或店鋪下的用戶，看到的團購/旅游/酒店/抽獎/電影訂座/外賣…等商品集合以及排序也不一樣。

2、基本實現機制

而在實現上，通常將商品資料的同步分為兩類實現機制：

一類是通過中間服務ES這種搜索引擎中間件，進行緩存和查詢支持。
另一類是接口，拉取數據庫的商品資料；

很明顯，ES是解決商品list，實現快速響應高并發(fā)數據的。

對應的同步路線就是：操作觸發(fā)——>數據庫——>ES——>商城。

商品詳情頁面，可以采用數據庫接口（因為一次請求一個商品扛得住，可以不需要ES）。

其數據路線就是：操作——數據庫——商城。

上述的bug產生的原因，就是開發(fā)做了導入數據的功能，忘記這個數據是需要同步ES的。

商城搜索的一般機制

搜索的基本模型就是，以請參，命中商品資料的指定的字段（比如“商品名稱”、“功能”、“品牌”、“廠家”），各字段可以加權重，最后以得分的形式，排序輸出商品。

1、搜索引擎的運算

這里最麻煩的是，命中的邏輯機制，也就是搜索的運算。所以很多架構中獨立出來一個搜索服務，專門為C端提供快速的運算。

比較成熟的方法很多我這里舉兩個例子：一個是分詞匹配，一個是逐字匹配。

搜索的時候，輸入關鍵詞。一般采用的是分詞搜索技術。ES自帶這種技術插件。

原理就是：

先初始化：

第一步，配置（或使用自帶的）分詞表2。比如該表配置有分詞“礦泉”、“水”、“礦泉水”。

第二步，以表1的商品（“礦泉水”為例），讀取分詞表2（該表有分詞為“礦泉”、“水”、“礦泉水”），生成商品與詞的關聯關系：

礦泉水對應三個分詞“礦泉”、“水”、“礦泉水”，放入表3中。

應用場景：

用戶輸入關鍵詞“礦泉醋”，讀取表2，提取用戶信息的分詞“礦泉”。

第二步，以用戶的分詞“礦泉”，查找表3，得到商品“礦泉水”。

總結：

我們發(fā)現這里最主要的是表2要維護好。供使用。

不同領域會有很大區(qū)別。比如醫(yī)藥，會有自己的分詞習慣，比如“阿莫西林” 是一個完整的詞。

注意：

需注意的是，分詞庫（表2）每次更新，都要重新進行初始化。重新生成表3（新的覆蓋舊的）。

過濾詞庫：

包括做一些“剔除詞庫”，去除語氣詞助詞等。比如xx藥，則把“藥”字去除，不參與。

還有不少關鍵字比較敏感，比如涉黃、涉賭等等，這些關鍵字我們通常都會屏蔽，不進行數據搜索。

要屏蔽對應的關鍵字，后臺就需要維護一套非法詞庫，當用戶輸入的關鍵字在非法詞庫中就不再做搜索，以減輕服務器壓力。

網上一般有現成的詞庫可以直接導入系統，不滿足的后臺再進行維護擴充。

其他輔助詞庫

比如錯誤詞糾正、還可以做近義詞庫：比如“維生素”=V，以及大小寫字母通用等。推薦詞庫等。

逐字匹配：

而逐字匹配比較機械，用戶輸入ABCD，我們的指定字段中含有“ABCD”的，都篩選出來?；蛘吆小癆B”的也篩選出來。這里就可以做權重，按順序輸出。

這個方法最原始，往往與用戶的真實意愿不符合。

2、搜索結果輸出

當后臺將內容摟出來之后，會按默認順序分頁輸出。比如我查出來1000個，會按權重順序輸出每頁50個，展示在前端。

需考慮的是：

（1）按SPU還是按SKU輸出（商戶自己可以選擇）；

（2）若是O2O，是所有門店都展示還是取最近一個有商品的門店。

（3）排序是以門店優(yōu)先，還是商品優(yōu)先。

（4）用戶指定排序規(guī)則的情況下，則將摟出來的數據重新按用戶的順序輸出。

若你和作者一樣非技術出身，那么了解一些技術原理，工作就容易很多了。推薦一本適合的產品書<后端產品經理寶典>！

ES的引入，解決了什么痛點？

那么使用ES，究竟能為商品同步到商城發(fā)揮哪些不可替代的作用呢？

1、大規(guī)模數據檢索的困擾

我們知道，隨著網站業(yè)務的不斷發(fā)展，網站商品搜索篩選的粒度越來越細，維度也就越來越多。

(注意這里的"篩選"不僅是用戶主動查詢，還包括默認打開頁面時候的前端請求）

常規(guī)的方式，在多維度的 count 和 select 查詢、各種排序、不同篩選維度的組合篩選下，回造成數據庫的索引命中率不高。

一旦沒有命中索引，就造成整個數據庫的壓力增大響應變慢（MongoDB 的索引策略基本和 MySQL 的差不多）。

當系統數據量上了10億、100億條的時候，系統架構通常會從以下角度去考慮問題：

（1）用什么數據庫好？(mysql、sybase、oracle、達夢、神通、mongodb、hbase…) ；

（2）如何解決單點故障；(lvs、F5、A10、Zookeep、MQ) ；

（3）如何保證數據安全性；(熱備、冷備、異地多活) ；

（4）如何解決檢索難題；(數據庫代理中間件：mysql-proxy、Cobar、MaxScale等;) ；

（5）如何解決統計分析問題；(離線、近實時)

其結果，往往各有瓶頸。

那么假設，全部放在內存中呢？——速度問題是解決了，但成本問題上來了。

當我們的數據達到PB級別時，按照每個節(jié)點96G內存計算，在內存完全裝滿的數據情況下，我們需要的機器是：1PB=1024T=1048576G，節(jié)點數=1048576/96=10922個。

實際上，考慮到數據備份，節(jié)點數往往在2.5萬臺左右。成本巨大決定了其不現實！

為解決以上問題，就引出了ES（elaticsearch的簡寫）。

2、ES是專治大規(guī)模數據檢索難題的

ES是一個開源的高擴展的分布式全文檢索引擎，它可以近乎實時的存儲、檢索數據。

本身擴展性很好，可以擴展到上百臺服務器，處理PB級別的數據。從而讓全文搜索變得簡單。這個過程如下圖所示：

它的處理能力上，支持橫向擴展，理論上無限制。

比如在雙十一這樣的高峰期，我們可以采用調配臨時節(jié)點的方式，來分解壓力，在不需要的時候我們可以停掉多余的節(jié)點來節(jié)省資源。

還有ES的高可用性，在集群節(jié)點出現一個節(jié)點或者多個節(jié)點出現故障時，主要數據完整，依然可以正常提供服務。

因此采用這種技術，用戶一打開商城就看的到商品list，快速展示給用戶。

輕松解決前端請求的壓力。當雙十一等爆單期，任由用戶狂刷商城，高枕無憂。

05 總結和意義

1、總結

（1）從開篇的bug，我們引發(fā)出了商品從后臺到前端的機制探索。

商品列表的展示和搜索，通常通過ES實現；商品詳情字段，可以通過普通的接口請求數據庫。

（2）ES簡單理解為以類似緩存的方式，實現高速大量搜索請求的引擎。

數據傳遞方面，它相當于一個介于數據提供方和使用方之間的容器，需要先將數據提交給它。

因此牽扯同步ES、請求ES、清除ES等。這就容易導致開發(fā)遺漏。

（3）當遇到搜索壓力大的時候，比如商城快速加載大量商品列表數據的時候，可以考慮類似ES的機制。在技術選型上還有與之相似的solr等。

2、意義

后端產品體系對技術方案的依賴，需要產品經理理解這種機制。

產品經理需協助溝通ES收錄的字段范圍，需要在PRD中說明。
在需求方案和刷數據等環(huán)節(jié)，避免與開發(fā)產生過大的脫節(jié)。

寫在最后：

若你和作者一樣非技術出身，那么了解一些技術之后，工作就容易很多了。

推薦產品書<后端產品經理寶典>。

??掃ES技術培訓資料??

公眾號jjyypm回復“ES”領取

ES技術培訓ppt，回復“ES”領取

——往期推薦——

B端產品經理對接第三方API，可能有多坑！

4千字，總結產超時”品需求文檔的形式、規(guī)范、自查

電商商品搜索：需求方案和實現原理（“搜索產品經理”的傳送門）

其他輔助詞庫

比如錯誤詞糾正、還可以做近義詞庫：比如“維生素”=V，以及大小寫字母通用等。推薦詞庫等。

比如錯誤詞糾正、還可以做近義詞庫：比如“維生素”=V，以及大小寫字母通用等。推薦詞庫等。