中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

賬號體系是平臺的底層系統，在此基礎上，用戶行為、業務發展等因素會引發賬號間交互的需求。

賬戶間的交互有“合并”“打通”“換綁”等方式，其中“合并”與“打通”這倆概念極易混淆，本文將對這兩種賬戶交互進行概念區分及處理方式的講解。

一、合并與打通的區分

這部分橘子將會以下圖為大綱進行講解：

1.賬號合并

（1）概念

賬號合并是指一個系統內，一個用戶的多個賬號合并成一個賬號。

賬號系統是為用戶所做，賬號即代表用戶身份。在一個系統內部，用戶本人為賬號的持有者，所以對多個賬號的合并只能由賬號持有者本人發起。

因此賬號合并需要從用戶的維度思考，合并結果為一個用戶在系統內的多個用戶身份，合并為一個用戶身份。

（2）業務場景

合并前的多個賬號，可以是相同類型的，也可以是不同類型的。

在此，先對“類型”進行簡單定義：注冊方式相同的賬號，視為相同類型的賬號。

一個系統內，相同類型的賬號合并：

e.g：游戲中，同一用戶用兩個手機號注冊了大小號。希望將其合并為一個賬號。

這些賬號是在同一個游戲內，通過相同的方式“手機號注冊”，用不同的手機號注冊的賬號，所以為相同類型的賬號合并。

一個系統內，不同類型的賬號合并：

e.g：一個平臺內有手機號、微信、微博等多個注冊入口，導致一個用戶有多個賬號，希望將這些賬號合并。

手機號、微信、微博等賬號是通過不同的注冊方式生成的，所以為不同類型的賬號合并。

（3）目的

賬號合并的重點在“并”，所以賬號合并希望達到的效果：

賬號“合n為1”：多個賬號聚合后生成一個主體賬號，一個用戶只有“一個”主體賬號代表其用戶身份。

數據取并集：合并后主體賬號的數據，為所有賬號數據資料的累加并集。

在上面相同類型的賬號合并的案例中：

一個游戲用戶希望將小號合并入大號，每個賬號都有10枚金幣。

則最終的合并結果：大號為主體賬號，數據為兩個賬號的累加，金幣為10*2=20枚，小號注銷無法再次使用。

不同類型賬號合并案例中：

一個用戶的手機號、微信、微博賬號要進行合并，系統定義的主體賬號為手機號，每個賬號都有10個收藏店鋪。

則最終的合并結果：微信賬號、微博賬號作為子賬號綁定在手機號上，微信賬號、微博賬號的數據并入手機賬號中，收藏店鋪為10*3=30個。

通過任何賬號登錄，調用的都是所關聯的主體賬號的信息。

2. 賬號打通

（1）概念

賬號打通是指同一個用戶的數據，在多個系統間進行流轉。

“打通”是多個系統賬戶體系的交互，用戶雖然是賬號的持有者，但是涉及到多個系統間的交互，用戶是沒有“發起”權的，僅有“授權”權，授權是否同意打通。

多系統內賬號的打通，為的是實現系統間數據的流轉，因此賬號打通更準確的說其實是系統間的數據打通，數據的傳輸紐帶為“同一用戶”。因此在本文后續都以“數據打通”來替代“賬號打通”。

數據打通的發起方，為使用打通后數據的業務系統。多個系統間的數據需要做交互，由需要該數據的業務系統來推動。

因此數據打通需要從系統、數據的維度思考，通過賬號的打通，來實現系統業務的打通，最終實現系統間數據的流轉。

（2）業務場景

多個系統間，系統間數據的打通分為單向與雙向。

不同系統內，單向的數據打通：

e.g，通過微信等第三方授權方式注冊登錄知乎后，app用戶的初始化用戶名為微信的用戶名。

此為知乎與微信兩個系統間的數據打通。知乎只需要微信提供用戶數據，所以為單向的數據打通。多用于授權模式的產品。

不同系統內，雙向的數據打通：

e.g.餓了嗎與百度外賣整合后，同一個用戶用同一個手機在兩個平臺注冊登錄，在餓了嗎修改送貨地址，百度外賣的送貨地址會自動進行同步；反之同理。

此為餓了嗎與百度外賣兩個系統間的數據打通。送貨地址信息在兩個系統內相互流轉，所以為雙向的數據打通。多用于合作模式的產品。

（3）目的

數據打通的重點在“通”，打通后在系統間流轉的就是數據，所以數據打通希望達到的效果：

數據流通：一個用戶在多個系統內，局部數據流通（單向或雙向），數據總量不變。

在上面單向數據打通的案例中：知乎需要微信用戶體系內用戶的昵稱，因此需要微信提供查詢接口，知乎進行調用，查詢當前注冊的用戶在微信的昵稱，實現單向數據流通。

在上面雙向數據打通的案例中：餓了嗎與百度外賣中，同一用戶的送貨地址需要進行同步，百度外賣整合入餓了嗎，因此百度外賣需要相同用戶在餓了嗎的數據，并且可以寫入新的數據。因此由餓了嗎提供查詢、寫入接口，實現雙向數據流通。

3. 賬號合并與打通的區別總結

賬號合并

由用戶發起，所以合并的主體為：“一個”使用賬號的用戶本人。需要從用戶維度去思考。

合并后數據要求：所有賬號的數據累加植入合并后的賬號。

數據打通

由業務方發起，所以打通的主體為：使用打通后流轉數據的業務系統。需要從系統維度去思考。

打通后數據要求：同一個用戶的局部數據在多個系統間通過業務流轉同步，數據總量不變。

通過以上的拆解 ，相信大家能夠更準確的區分賬號的合并與打通。接下來，就是真正動手實操了，如何處理賬號的合并與打通呢？

二、合并與打通的方式

合并與打通的處理，都分為兩個部分，一為賬號業務層面的處理，二為舊數據的處理。本文僅詳述業務層面的處理，舊數據的處理將在下篇文章進行展開詳述。

1.賬號合并

回顧賬號合并主體：“一個”使用賬號的用戶本人。

賬號合并目的：一個用戶只有“一個”主體賬號代表其用戶身份。

下面會按照不同的場景，對賬號合并的處理方式進行討論。

（1）一個系統內，相同類型的賬號合并

多個賬號的類型相同，登錄方式相同，相當于多個完全獨立的用戶個體，要將其合n為1，說明這幾個用戶其實為一個人，那么只需要保留一個賬號代表該用戶個體，并且擁有所有賬號的數據即可。

所以，需要用戶在發起合并賬號請求時，指定合并后保留的賬號，以此為主體賬號，將其余賬號的數據資料全部累加計入主體賬號，然后注銷其余賬號。

e.g.將三個賬號abc合并，每個賬號都有10枚金幣，且主體賬號為a。則將bc的金幣累加進入a賬號，累計后金幣數為30，bc賬號注銷，無法再次登陸。

（2）一個系統內，不同類型的賬號合并

賬號的類型不同，登錄方式也不同，沒有一個統一的判斷基準，所以無法判斷這些賬號間的關系為同一用戶所有，還是不同用戶所有。

所以需要先設置一個統一的判斷基準：從哪種方式登錄的賬號，為用戶身份的唯一標志——主體賬號。

以下為常用的賬號合并操作思路：

1. 指定可確認用戶身份的登錄方式；
2. 新增主體賬號ID，為賬號系統內每個人用戶身份的唯一ID。僅有通過以第一步指定的的登錄方式注冊時，才會生成主體賬號id；
3. 以其余登錄方式產生的賬號，為主體賬號的子賬號。同一主體賬號ID可對應多個子賬號（ps：若非強綁定關系，在用戶用子賬號登錄后，不強制用主賬號流程注冊，無法生成主體賬號ID，就將其置為空，等后期用戶發起合并的時候進行填充）。
4. 用戶在發起賬號合并后，提供其需要綁定的主體賬號ID，將子賬號綁在指定主體賬號下，并將子賬號的用戶數據并入主賬號，便完成了賬號的合并。

通過以上方法，合并后通過用戶身份下任意方式登錄，都調用的是相同的主賬號下的用戶數據。

這種方式需要修改賬號體系的架構，將平行的賬號關系修改為主/子賬號的母子關系，所以在前期實現賬號合并的時候改動大，成本較大。

但是在后期解綁/換綁子賬號的時候，對用戶數據無影響，因為用戶數據是儲存在主賬號ID下的。

2.數據打通

回顧數據打通主體：使用打通后流轉數據的業務系統。

數據打通目的：同一個用戶的局部數據在多個系統間通過業務流轉同步。

系統間的數據流轉要依賴接口，所以，需要通過設計接口來實現數據打通。

系統間需要進行數據流轉的為“同一用戶”，則首先兩個系統需要對用戶的身份有相同的判斷方式，接口通過該用戶唯一標示，來進行兩個系統間同一用戶數據的流轉。

下面會按照不同的場景，對數據打通的處理方式進行討論。

在此，我將使用打通后流轉數據的業務系統主體稱為甲方，提供數據的系統稱為乙方。

（1）不同系統內，單向的數據打通

單向數據打通，即甲方需要乙方的用戶數據，乙方不受甲方業務影響。所以需要乙方提供數據查詢接口，甲方進行調用。

市場中常見的微信、微博、qq等用戶數據已經有了成熟的對外接口，僅需進行申請便可進行調用。若乙方無成熟接口，就需要進行定制化的接口開發了。以下為接口的設計思路：

1）確定甲乙系統內用戶身份的唯一標示

方法：列出雙方賬號系統用戶賬號的所有可用信息，從中挑取相同的、與業務強相關的、用戶不會輕易改變的、最能代表用戶身份的字段，作為打通后識別用戶的唯一標示；例如手機號。唯一標示為接口的必填查詢入參。

2）甲方提供所需的用戶數據需求，詳細到字段，例如用戶名稱、用戶頭像；以及是否有批量查詢用戶數據需求。

3）乙方根據甲方需求提供查詢接口：

• 接口入參：前期統一的用戶唯一標示，來指定查詢的用戶；查詢的用戶數據；
• 接口出參：甲方查詢用戶的指定數據。

4）甲方對接后進行調用

（2）不同系統內，雙向的數據打通

雙方數據打通，即甲方需要乙方的用戶數據，同時也會向乙方插入用戶數據。乙方提供數據查詢接口、數據寫入接口，甲方進行調用。以下為接口設計思路：

1）確定系統間的唯一標示，作為打通后識別用戶的唯一標示

方法同單向打通

2）判斷唯一標示是否符合乙方賬號系統的注冊條件，據此保證打通后甲方向乙方寫入新用戶數據時，可以成功進行注冊

方法：判斷唯一標示為乙方賬號的什么信息：

• 為乙方賬號注冊時的唯一身份標示：不需任何處理
• 為乙方賬號關聯的字段：判斷甲方系統是否有乙方賬號注冊時的唯一身份標示字段，若有，注冊時使用該字段；若無，擴充乙方系統注冊方式，或甲方系統要求用戶補充該用戶信息。

3）甲方提供所需的用戶信息，以及要寫入乙方的數據

所需的乙方數據的提供方式，同單向數據打通

寫入乙方的數據，按照功能模塊劃分，再詳細到字段，例如綁定新用戶（唯一標示、用戶名稱、密碼）、填加數據（收貨地址）、刪除數據（收貨地址）。

4）乙方根據甲方提供需求，設計相應的查詢接口與寫入接口

查詢接口同單向數據打通。

• 寫入接口入參：前期統一的用戶唯一標示，來指定寫入的用戶；具體寫入數據；
• 寫入數據出參：操作結果（成功/失敗，及失敗理由）

5）甲方對接后進行調用

以上便為賬號“合并”與“打通”的概念區分及處理方式的講解，下一篇文章將會繼續這個話題，討論合并 /打通后，舊數據的處理方式后。

備注：文章若有思考不完善之處，歡迎各位幫忙指正，共同進步。

作者：橘子；公眾號：橘子周思錄；我是3年產品橘子，每周分享自己對日常工作的總結思考，希望與您一同成長。

本文由 @橘子 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。