一、回顧
之前的登陸流程在這篇里。之前的登陸流程簡述：
（1）先檢查是否同服已登陸，是則兩個鏈接都踢掉，否則進入下步；
（2）判斷是否異服已登陸，是則告訴異服踢老鏈接，隨后踢自己這的新鏈接。否則進入下步；
（3）當前服務器登陸相關流程走完后，向玩家在線列表匯報（寫入這個玩家登陸的服務器id為我）。這時的匯報寫入為redis的CAS操作，為了檢查是否發生了那篇里介紹的同賬號瞬間多起登陸事件。CAS操作成功，本服鏈接登陸完成，做后續操作。否則CAS操作失敗，表示瞬時登陸的異服同賬號的另一個鏈接的登陸流程走的快，已經完成整個流程，包括匯報進在線列表。這時的處理只用將慢拍的本服鏈接關閉就行了。
二、存儲架構變為redis+mysql后的問題
現在玩家上線時需要從mysql加載玩家離線數據到redis，需要考慮這個數據加載放到上邊登陸流程哪一步里。
首先數據加載有可能會失敗，如果數據加載出問題，就不能讓該玩家登陸。
如果放到（2）（3）之間，就是redis的CAS之前，這樣瞬間同一賬號多起登陸都有可能開始進行加載數據步驟，而處理的快的那個客戶端就有可能匯報登陸完成之后立即玩游戲并更新了自己在redis里的數據，處理的慢的客戶端還這時還在將mysql的數據往redis的加載，會覆蓋快的客戶端更新的數據。
如果放到（3）里redis的CAS之后，數據加載失敗，就需要回退CAS的操作。
可見第二種至少可以保證數據正確性。這種情況抽象下，就是第一種里沒有提供事務操作的回滾（慢客戶端覆蓋數據后發現干了壞事卻不方便回滾自己的破壞）。
（2）這個操作當時是為了區分異服登陸并玩游戲很久了和瞬間多起登陸這兩種情況的?，F在想想這兩種情況的處理統一為直接踢掉新舊兩個鏈接也沒什么，畢竟瞬時登陸的情況不多。
三、新流程
根據上邊的結論，新的流程為：
（1）先檢查是否同服已登陸，是則兩個鏈接都踢掉，否則進入下步；
（2）向玩家在線列表CAS報告自己登陸。如果失敗告訴異服踢掉該賬號老鏈接，自己這邊踢掉該賬號新鏈接即可。成功則進入下步；
（3）加載數據，成功就進入正常游戲流程。加載失敗，就去在線列表里清掉自己。