流量紅利正逐漸走向終結(jié)，這已經(jīng)不再是什么秘密。后互聯(lián)網(wǎng)時(shí)代斯稳，如何維系住用戶群，提升用戶在平臺(tái)上的體驗(yàn)是整個(gè)行業(yè)都需要考慮的事情迹恐。正是出于這一原因挣惰，現(xiàn)在全行業(yè)都在關(guān)注會(huì)員體系的搭建，這也是馬蜂窩 2019 年重點(diǎn)投入的方向之一。
面對(duì)這個(gè)全行業(yè)都在發(fā)力的會(huì)員市場(chǎng)，要對(duì)「馬蜂窩特色」的會(huì)員體系進(jìn)行有力的支撐乳规，無(wú)疑對(duì)會(huì)員體系的架構(gòu)設(shè)計(jì)提出更高的要求。
馬蜂窩會(huì)員體系建設(shè)從 2018 年 9 月份開始啟動(dòng)竖幔，經(jīng)過(guò)前期對(duì)會(huì)員身份和會(huì)員權(quán)益的摸索，伴隨業(yè)務(wù)的快速發(fā)展是偷，到 2019 年上半年拳氢，為了讓更多用戶體驗(yàn)到馬蜂窩高質(zhì)量的會(huì)員服務(wù)募逞，公司推出了更靈活、維度更多馋评、權(quán)益更豐富的會(huì)員模式放接。在這樣的背景下，初期較為粗曠的底層技術(shù)也需要及時(shí)做出調(diào)整留特，對(duì)核心架構(gòu)和服務(wù)進(jìn)行升級(jí)纠脾。
Part 1
會(huì)員身份策略改造
早期的會(huì)員身份模塊由會(huì)員產(chǎn)品、用戶屬性和時(shí)間屬性共同構(gòu)成蜕青。由于當(dāng)時(shí)的產(chǎn)品較為單一苟蹈，因此產(chǎn)品信息設(shè)計(jì)成一級(jí)結(jié)構(gòu)：
可以看到早期的會(huì)員產(chǎn)品比較單一，因此將產(chǎn)品信息設(shè)計(jì)成一級(jí)結(jié)構(gòu)右核。這種設(shè)計(jì)的好處是邏輯簡(jiǎn)單慧脱，可以快速實(shí)現(xiàn)，但不易擴(kuò)展蒙兰，一旦新增會(huì)員類別以及不同卡種之間出現(xiàn)復(fù)雜關(guān)系時(shí)磷瘤，不論是對(duì)項(xiàng)目或者對(duì)代碼本身而言芒篷，維護(hù)成本都將成倍增長(zhǎng)搜变。
從 2019 年年初開始，馬蜂窩會(huì)員體系進(jìn)行了全面升級(jí)针炉，主要體現(xiàn)在以下幾個(gè)方面：
更完善的獲客渠道挠他，增加了在小程序端的服務(wù)展示；
更豐富的會(huì)員類別篡帕，新增了非常多卡種殖侵，在最初的年度金卡和體驗(yàn)金卡基礎(chǔ)上，增加了季度金卡镰烧、 7 日卡拢军、「蜂享卡」，未來(lái)還計(jì)劃推出月度金卡怔鳖、學(xué)生卡等茉唉；
更低的獲取門檻，早期的會(huì)員身份只能通過(guò)在 App 中購(gòu)買獲得结执，為了讓更多用戶享受到品質(zhì)更高的服務(wù)度陆，增加了通過(guò)完成用戶激勵(lì)任務(wù)、供應(yīng)商合作献幔、產(chǎn)品搭售懂傀、線下實(shí)體卡等會(huì)員獲取方式。
這也意味著蜡感，同一時(shí)間段內(nèi)用戶的會(huì)員身份將變得愈發(fā)復(fù)雜蹬蚁，早期單一的會(huì)員身份策略和模型設(shè)計(jì)已經(jīng)不能滿足需求恃泪。重新設(shè)計(jì)會(huì)員身份的時(shí)候，我們明確了未來(lái)無(wú)論業(yè)務(wù)線如何劃分會(huì)員身份缚忧，底層結(jié)構(gòu)都要能夠較好地支持悟泵，因此決定把會(huì)員模塊身份抽離出來(lái)。會(huì)員體系升級(jí)后闪水，產(chǎn)品信息調(diào)整為以 SKU 作為最小粒度重新劃分糕非，同時(shí)增加了用戶信息中的來(lái)源以及獲取渠道信息：
Part 2
會(huì)員中心架構(gòu)設(shè)計(jì)和優(yōu)化
在明確了新的會(huì)員身份策略后，我們對(duì)整個(gè)會(huì)員體系進(jìn)行了梳理球榆，將現(xiàn)階段的會(huì)員中心架構(gòu)設(shè)計(jì)如下：
結(jié)合上面的架構(gòu)圖來(lái)看朽肥，目前馬蜂窩會(huì)員中心系統(tǒng)主要?jiǎng)澐譃閿?shù)據(jù)存儲(chǔ)、核心服務(wù)持钉、接口層衡招、應(yīng)用層四大部分：
數(shù)據(jù)儲(chǔ)存：主要基于 MySQL 和 Redis，以及馬蜂窩統(tǒng)一日志系統(tǒng) MES
-
核心服務(wù)：這是當(dāng)前馬蜂窩會(huì)員體系中最重要的一層每强。核心服務(wù)又可以分為三大塊：
（1）「四駕馬車」：會(huì)員身份始腾、權(quán)益、增值服務(wù)接入空执、會(huì)員積分浪箭，驅(qū)動(dòng)著整個(gè)會(huì)員體系的運(yùn)轉(zhuǎn)；
（2）交易營(yíng)銷：輔助四駕馬車快速往前跑辨绊；
（3）支撐模塊：與會(huì)員體系對(duì)接的公司級(jí)別支撐模塊奶栖，包括風(fēng)控、監(jiān)控门坷、日志宣鄙、消息總線、商家結(jié)算對(duì)賬等
接口****層：會(huì)員體系對(duì)外暴露的接口默蚌，包括了會(huì)員身份冻晤、權(quán)益領(lǐng)取、蜂蜜消費(fèi)等接口
應(yīng)用層：主要是面向 C 端的應(yīng)用绸吸，包括會(huì)員頻道頁(yè)鼻弧、蜂蜜中心、用戶權(quán)益中心惯裕、任務(wù)中心等
下面重點(diǎn)圍繞「核心服務(wù)」層展開介紹温数。
2.1「四駕馬車」
2.1.1 會(huì)員身份
目前，市面上很多常見的會(huì)員產(chǎn)品都是采用普通的續(xù)費(fèi)模式蜻势，比如一些視頻平臺(tái)的年度會(huì)員撑刺、季度會(huì)員。這種模式的特點(diǎn)是只進(jìn)行時(shí)間的區(qū)分握玛，在會(huì)員身份后生效后享受的權(quán)益完全相同够傍，通過(guò)續(xù)費(fèi)使權(quán)益時(shí)效得到相應(yīng)延長(zhǎng)甫菠。
但是馬蜂窩由于業(yè)務(wù)的特殊性，會(huì)員體系需要設(shè)計(jì)得更為立體冕屯。如果只采用單純的續(xù)費(fèi)模式寂诱，會(huì)影響高忠誠(chéng)度用戶的使用體驗(yàn)。
首先安聘，在同一類別的會(huì)員身份下痰洒，時(shí)長(zhǎng)不同的產(chǎn)品對(duì)應(yīng)的權(quán)益也不同。以金卡會(huì)員為例浴韭，季度金卡丘喻、年度金卡這種同類別下的會(huì)員身份，可以通過(guò)續(xù)費(fèi)升級(jí)念颈，但它們彼擁有的權(quán)益不完全相同泉粉，比如年度金卡 96 折抵額上限為 500 元，季度金卡只有 100 元榴芳。
另外嗡靡，同一用戶在同一時(shí)間內(nèi)，只要滿足條件窟感，就可同時(shí)擁有不同類別的卡種讨彼，比如金卡和蜂享卡。
為了滿足上述需求肌括，我們決定引入用戶身份的疊加以及續(xù)費(fèi)模型点骑。通過(guò)增加會(huì)員 SKU 疊加酣难、續(xù)費(fèi)關(guān)系表谍夭，使用戶在一個(gè)時(shí)間段內(nèi)不僅可以同時(shí)擁有多種身份，還可以續(xù)費(fèi)已有卡種憨募。
上圖是會(huì)員身份的時(shí)間軸示意紧索。橫軸代表時(shí)間，縱軸代表不同的卡種菜谣。我們通過(guò)最終 SKU 時(shí)間軸便可以確認(rèn)用戶當(dāng)前的會(huì)員身份珠漂。
我們將用戶已有的每個(gè) SKU 時(shí)間軸拉平，當(dāng)用戶在某個(gè)時(shí)間點(diǎn)發(fā)出購(gòu)買新卡種的請(qǐng)求時(shí)尾膊，查看當(dāng)前生效的時(shí)間軸中是否已有用戶正在購(gòu)買的 SPU媳危，如果沒(méi)有則疊加，如已有則需要再判斷 SKU 之間的配置策略冈敛，決定是疊加還是續(xù)費(fèi)待笑；然后繼續(xù)計(jì)算出正在購(gòu)買的 SKU 生效時(shí)間軸；接下來(lái)根據(jù)配置好的規(guī)則抓谴，對(duì)比當(dāng)前購(gòu)買生效時(shí)間軸和已有 SKU 時(shí)間軸的身份關(guān)系暮蹂，決定用戶是否可以完成此次購(gòu)買寞缝，如：
前置身份：指必須已經(jīng)購(gòu)買某個(gè) SKU，才可以購(gòu)買當(dāng)前 SKU
沖突身份：指如果已經(jīng)購(gòu)買某個(gè) SKU仰泻，就不可以購(gòu)買當(dāng)前 SKU
為了滿足不同的業(yè)務(wù)需求荆陆，這里的疊加、續(xù)費(fèi)關(guān)系都是可以通過(guò)運(yùn)營(yíng)來(lái)配置的集侯。整個(gè)流程大致示意如下：
為了讓用戶的體驗(yàn)更好被啼，當(dāng)同時(shí)擁有多重身份的時(shí)候，我們會(huì)根據(jù)數(shù)據(jù)分析結(jié)果調(diào)整會(huì)員 SPU 權(quán)重棠枉，優(yōu)先展示權(quán)重高的權(quán)益趟据。比如當(dāng)前會(huì)員同時(shí)擁有金卡和門票卡，數(shù)據(jù)顯示金卡權(quán)益的使用率或者關(guān)注度高于其他產(chǎn)品术健，則提升金卡權(quán)重汹碱，金卡身份和相關(guān)權(quán)益會(huì)在用戶進(jìn)入會(huì)員頻道頁(yè)時(shí)首先展示。
2.1.2 權(quán)益中心
除了身份體系荞估，最重要的就是會(huì)員權(quán)益咳促，它直接體現(xiàn)會(huì)員的不同級(jí)別。會(huì)員項(xiàng)目發(fā)展初期勘伺，一切都是從零開始跪腹，對(duì)拓展性要求不高，每出現(xiàn)一種新的身份飞醉、卡種冲茸，都需要從頭設(shè)計(jì)其所含權(quán)益，開發(fā)效率很低缅帘，后臺(tái)的配置也很分散轴术。后期為了支撐業(yè)務(wù)快速發(fā)展，我們開始考慮將權(quán)益中心進(jìn)行拆分钦无，分成兩部分進(jìn)行改造逗栽。
第一步是權(quán)益池的搭建，下圖是權(quán)益池的基本模型：
我們將會(huì)員權(quán)益中通用的屬性抽象出來(lái)失暂，定義為原則上不變的基礎(chǔ)屬性彼宠，形成「權(quán)益物料」存放在權(quán)益池中，通用的屬性主要包括：
權(quán)益類型：主要有兌換碼弟塞、折扣購(gòu)買凭峡、優(yōu)惠券、三方跳轉(zhuǎn) 4 種决记，目前能支持到馬蜂窩所有的權(quán)益類型
供應(yīng)商：不同供應(yīng)商提供了不同的權(quán)益摧冀，甚至還有不同的權(quán)益接入流程和權(quán)益消費(fèi)流程，同時(shí)和涉及了不同的供應(yīng)商結(jié)算模式
下發(fā)時(shí)機(jī)：主動(dòng)下發(fā)或者被動(dòng)下發(fā)，例如金卡 96 折權(quán)益按价，是用戶購(gòu)買會(huì)員的核心權(quán)益惭适，這種權(quán)益在用戶購(gòu)卡之后便直接下發(fā)至用戶賬戶。其他的權(quán)益例如機(jī)場(chǎng)貴賓廳楼镐、QQ 綠鉆癞志、騰訊視頻季卡等則需要用戶主動(dòng)領(lǐng)取。
基礎(chǔ)屬性：權(quán)益的基礎(chǔ)屬性依賴于權(quán)益類型框产、下發(fā)時(shí)機(jī)凄杯、供應(yīng)商，也就是說(shuō)不同的供應(yīng)商或者不同的權(quán)益類型和下發(fā)時(shí)機(jī)秉宿，都會(huì)組合出不同的權(quán)益基礎(chǔ)屬性戒突，這里的屬性大多是這些權(quán)益的固定屬性。最終這 4 大屬性共同組成了基本的權(quán)益物料描睦。
下圖是用戶開卡及權(quán)益發(fā)放的流程示意：
當(dāng)會(huì)員產(chǎn)品支付完成后膊存，會(huì)員中心會(huì)通知權(quán)益中心發(fā)放權(quán)益；權(quán)益中心進(jìn)行權(quán)益過(guò)濾之后通知優(yōu)惠中心忱叭，最終由優(yōu)惠中心完成被動(dòng)權(quán)益的發(fā)放隔崎；需要用戶主動(dòng)領(lǐng)取的權(quán)益則只為用戶發(fā)放使用權(quán)利，最終由用戶決定是否領(lǐng)取韵丑。
第二步權(quán)益規(guī)則的配置爵卒。有了第一步的基礎(chǔ)之后，會(huì)員中心為權(quán)益池中的權(quán)益物料配置相應(yīng)的權(quán)益規(guī)則撵彻，之后展示給用戶钓株。
權(quán)益規(guī)則主要?jiǎng)澐譃椋?/p>
條件規(guī)則：指確定權(quán)益的一些基本前提，主要指會(huì)員身份陌僵、前求來(lái)源轴合、當(dāng)前業(yè)務(wù)等
通用規(guī)則：指對(duì)外展示的標(biāo)準(zhǔn)，包括文案拾弃、排序值桩、上下線時(shí)間摆霉、權(quán)益說(shuō)明等等
運(yùn)營(yíng)規(guī)則：這是權(quán)益規(guī)則中變動(dòng)最多豪椿，也是體現(xiàn)權(quán)益中心精細(xì)化運(yùn)營(yíng)的一部分。不同的用戶身份擁有不同的權(quán)益價(jià)格携栋、兌換價(jià)格以及不同的標(biāo)簽搭盾，差異化地顯示用戶的身份特權(quán)
我們抽象出了權(quán)益規(guī)則中的通用屬性，形成權(quán)益對(duì)外展示統(tǒng)一的標(biāo)準(zhǔn)婉支。當(dāng)然鸯隅，只有通用的權(quán)益規(guī)則配置是遠(yuǎn)遠(yuǎn)不夠的，因此在不影響核心權(quán)益規(guī)則的前提下，在后臺(tái)加入了擴(kuò)展規(guī)則模板的配置蝌以，以便滿足特殊權(quán)益不同規(guī)則的需求炕舵，實(shí)現(xiàn)動(dòng)態(tài)規(guī)則配置，使用起來(lái)更加靈活跟畅。
2.1.3 第三方權(quán)益接入
權(quán)益池中有一部分是站內(nèi)權(quán)益咽筋，比如核心的金卡商品 96 折、馬蜂窩優(yōu)惠券徊件、接送機(jī)等奸攻。這些權(quán)益的發(fā)放和消費(fèi)在站內(nèi)建立的統(tǒng)一規(guī)則下完成，接入起來(lái)相對(duì)容易虱痕。
另外一部分是需要接入的站外權(quán)益睹耐，也就是為會(huì)員供提的增值服務(wù)，比如機(jī)場(chǎng)貴賓廳部翘、旅行保險(xiǎn)等硝训。不同的第三方都有自己權(quán)益規(guī)則的特殊性，目前無(wú)法抽象成統(tǒng)一標(biāo)準(zhǔn)新思，也就無(wú)法采用 OpenAPI 的方式接入捎迫。
現(xiàn)階段我們把第三方權(quán)益的接入進(jìn)行了流程上的整合，最終形成了兩大類方式：
一類是權(quán)益領(lǐng)取在馬蜂窩內(nèi)完成表牢，用戶所有的操作完全在我們的應(yīng)用里進(jìn)行窄绒，完成后異步再調(diào)用第三方接口為用戶發(fā)放權(quán)益。
第二類是權(quán)益領(lǐng)取過(guò)程完全在第三方系統(tǒng)中進(jìn)行崔兴，主要針對(duì)一些積分兌換的權(quán)益彰导。用戶點(diǎn)擊領(lǐng)取權(quán)益后跳轉(zhuǎn)至第三方頁(yè)面，交互完成之后異步回調(diào)馬蜂窩接口敲茄，馬蜂窩系統(tǒng)根據(jù)回調(diào)情況進(jìn)行積分的增加或者扣減位谋。這種方式的弊端是用戶體驗(yàn)完全由第三方?jīng)Q定，可控性不高堰燎；但優(yōu)勢(shì)在于能夠快速接入一些復(fù)雜的權(quán)益玩法掏父，比如一些游戲類權(quán)益，避免投入大量精力去開發(fā)秆剪。
上圖是兩種領(lǐng)取模式的流程對(duì)比圖赊淑，可以看到每一步的三方對(duì)接都是通過(guò)異步方式進(jìn)行的，這樣當(dāng)?shù)谌较到y(tǒng)出現(xiàn)異常不會(huì)影響到馬蜂窩的正常服務(wù)仅讽，使系統(tǒng)可用性得到保證陶缺。
2.1.4 會(huì)員積分
成長(zhǎng)體系對(duì)于搭建完整的會(huì)員體系非常重要，以內(nèi)容社區(qū)起家的馬蜂窩在這方面有天然的優(yōu)勢(shì)洁灵。我們決定引入已有的用戶積分體系「蜂蜜」來(lái)承載一部分會(huì)員積分的功能饱岸。通過(guò)與會(huì)員中心打通增強(qiáng)與會(huì)員用戶的線上互動(dòng)，提高用戶活躍度和黏性。在不同的蜂蜜場(chǎng)景和蜂蜜策略下苫费，用戶可以賺取積分汤锨，滿足相應(yīng)條件后可以兌換所需權(quán)益；此外百框，我們也正在拓展更多蜂蜜和 B 端的結(jié)合方式泥畅，希望促進(jìn)平臺(tái)和商家的共贏。
上圖是會(huì)員體系利用蜂蜜中心提供的服務(wù)以及一些近期規(guī)劃示意琅翻。如何利用好激勵(lì)機(jī)制使整個(gè)會(huì)員體系更加完善位仁，實(shí)現(xiàn)對(duì)會(huì)員用戶更加精細(xì)化的運(yùn)營(yíng)，對(duì)于馬蜂窩「內(nèi)容+交易」戰(zhàn)略的深化而言是一個(gè)重要的課題方椎，也是研發(fā)團(tuán)隊(duì)需要不斷探索的方向聂抢。
實(shí)現(xiàn)了會(huì)員身份、權(quán)益中心棠众、第三方權(quán)益接入琳疏、蜂蜜中心的改造后，會(huì)員中心也完成了升級(jí)之路的第一步闸拿。
2.2 營(yíng)銷活動(dòng)的性能優(yōu)化
為了讓更多用戶了解會(huì)員機(jī)制并體驗(yàn)會(huì)員權(quán)限空盼，我們推出了很多營(yíng)銷活動(dòng)。其中不少活動(dòng)都存在秒殺的場(chǎng)景新荤。以下部分就來(lái)重點(diǎn)介紹為保障這些營(yíng)銷活動(dòng)的穩(wěn)定可靠而進(jìn)行的技術(shù)優(yōu)化揽趾。
2.2.1 并發(fā)控制
在秒殺場(chǎng)景中，需要防止由高并發(fā)導(dǎo)致的庫(kù)存超賣苛骨。關(guān)于這個(gè)問(wèn)題業(yè)界已經(jīng)有不少成熟的解決方案篱瞎，比如采用悲觀鎖、分布式鎖痒芝、樂(lè)觀鎖俐筋、隊(duì)列串行、Redis 原子操作等等严衬，當(dāng)然最理想的是用分布式鎖來(lái)實(shí)現(xiàn)澄者。
考慮到目前的并發(fā)量級(jí)以及技術(shù)成本，我們決定先采用 MySQL 樂(lè)觀鎖的方式來(lái)實(shí)現(xiàn)現(xiàn)階段的秒殺功能请琳。大家知道數(shù)據(jù)庫(kù)內(nèi)部 Update 同一行是不允許并發(fā)的粱挡，只有當(dāng)該行被更新后才會(huì)釋放。我們的方案是通過(guò)增加唯一的 Version 來(lái)防止超賣的情況發(fā)生：在每次數(shù)據(jù) Update 的時(shí)候判斷版本號(hào)是否和數(shù)據(jù)庫(kù)中的一致单起，不一致則表示當(dāng)前庫(kù)存已經(jīng)被其他用戶占用抱怔，此時(shí)拋出異常；如果一致則完成當(dāng)前用戶對(duì)庫(kù)存的占用嘀倒。
2.2.2 流量削峰
要緩解由瞬間流量爆發(fā)造成的數(shù)據(jù)庫(kù)壓力，我們首先要明確會(huì)引起瞬間 QPS 劇增的場(chǎng)景。
一種情況是接口被惡意重刷测蘑。由于我們的秒殺業(yè)務(wù)需要用戶必須登錄灌危，偽造 Session 的可能性較低，因此如果這種情況發(fā)生碳胳，很有可能是由同一個(gè) UID 遍歷刷接口導(dǎo)致的勇蝙。這里只需要加上 UID 的 Redis 鎖，使一個(gè) UID 在一定時(shí)間內(nèi)只能透過(guò)一次請(qǐng)求挨约，這樣絕大部分的遍歷刷接口行為就能被攔住味混。
還有一種情況是由流量突發(fā)引起，可能是真實(shí)的搶購(gòu)用戶數(shù)量巨大诫惭，也可能是對(duì)方使用了大量設(shè)備請(qǐng)求翁锡，這才是我們目前面對(duì)的實(shí)際場(chǎng)景。前面我們提到的加 MySQL 樂(lè)觀鎖來(lái)避免超賣夕土，如果瞬時(shí)流量巨大 MySQL 的讀寫馆衔、鎖表等現(xiàn)象會(huì)比較嚴(yán)重，當(dāng)數(shù)據(jù)庫(kù)壓力達(dá)到極限就會(huì)被打掛怨绣。因此為了減小數(shù)據(jù)庫(kù)的瞬時(shí)壓力角溃，我們需要在服務(wù)層做好限流。比如當(dāng)庫(kù)存只有 1000 件篮撑，但是有 1w 請(qǐng)求打到數(shù)據(jù)庫(kù)時(shí)减细，其實(shí)后面的請(qǐng)求都沒(méi)有意義。我們知道不論是 Memcache 還是 Redis赢笨，單機(jī)下每秒扛住 10w 請(qǐng)求都不會(huì)有太大問(wèn)題邪财。所以在沒(méi)有完成分布式鎖的情況下，我們是用 Redis 來(lái)做最基本的限流质欲，使大部分的請(qǐng)求被攔截在服務(wù)層树埠，只有少量請(qǐng)求會(huì)穿透到數(shù)據(jù)庫(kù)。
上圖是當(dāng)前秒殺體系簡(jiǎn)單的流程圖嘶伟。后續(xù)如果這類會(huì)員營(yíng)銷活動(dòng)依舊是業(yè)務(wù)重點(diǎn)怎憋，我們還是會(huì)采用 Redis 分布式鎖的方式來(lái)優(yōu)化，搭建更為完善的秒殺體系九昧。
2.3 風(fēng)險(xiǎn)控制
關(guān)于支撐模塊的部分主要分享與風(fēng)險(xiǎn)控制相關(guān)的內(nèi)容绊袋。為了保證享受到會(huì)員服務(wù)的是真實(shí)用戶，我們需要識(shí)別并抵御由黑產(chǎn)帶來(lái)的潛在風(fēng)險(xiǎn)铸鹰，保障系統(tǒng)的正常運(yùn)行癌别，嚴(yán)控由此帶來(lái)的損失。
上圖是目前會(huì)員體系中安全控制的結(jié)構(gòu)示意蹋笼。API 路由層主要負(fù)責(zé)數(shù)據(jù)收集和風(fēng)險(xiǎn)預(yù)估展姐，收集上來(lái)的數(shù)據(jù)統(tǒng)一寫入到公司的日志系統(tǒng) MES 中存儲(chǔ)躁垛。我們使用了滑窗模式的限流方式，當(dāng)發(fā)現(xiàn)總訪問(wèn)量超過(guò)一定閾值則會(huì)將大流量或者過(guò)快的請(qǐng)求記錄到會(huì)員疑似黑名單的表中圾笨，再進(jìn)行路由層的限流處理并接入公司級(jí)別風(fēng)控體系教馆，根據(jù)對(duì)不同業(yè)務(wù)場(chǎng)景的識(shí)別采用相關(guān)風(fēng)控策略；最終通過(guò)郵件擂达、短信等方式通知到路由層相應(yīng)的技術(shù)負(fù)責(zé)人土铺，盡快處理。
Part 3
總結(jié)和展望
在進(jìn)行馬蜂窩會(huì)員體系架構(gòu)的搭建的實(shí)戰(zhàn)過(guò)程中板鬓，我們積累了很多有價(jià)值的經(jīng)驗(yàn)悲敷，其中感受最深的就是切忌盲目?jī)?yōu)化，系統(tǒng)層面上的重構(gòu)更要首先以業(yè)務(wù)為導(dǎo)向去關(guān)注核心框架的升級(jí)和技術(shù)體系的演進(jìn)俭令，不要因?yàn)檫^(guò)度陷入技術(shù)細(xì)節(jié)而迷失方向后德。
今后，我們還將積極調(diào)研和應(yīng)用更多主流唤蔗、前沿技術(shù)探遵，比如會(huì)員標(biāo)簽、用戶畫像體系的引入妓柜，真正把這些技術(shù)用好用活箱季，使會(huì)員中心發(fā)揮更大價(jià)值。
本文作者：****馬蜂窩電商會(huì)員項(xiàng)目研發(fā)團(tuán)隊(duì)棍掐。
版權(quán)申明：內(nèi)容來(lái)源網(wǎng)絡(luò)藏雏，版權(quán)歸原創(chuàng)者所有。除非無(wú)法確認(rèn)作煌，我們都會(huì)標(biāo)明作者及出處掘殴，如有侵權(quán)煩請(qǐng)告知，我們會(huì)立即刪除并表示歉意粟誓。謝謝奏寨。
