Highlight
透明分布式
全局二級索引
MySQL兼容性
客戶介紹
真有趣（So Funny）成立于2012年8月，致力于為全球用戶提供健康有趣快樂的游戲體驗與服務。目前已推出《香腸派對》、《不休的烏拉拉》、《仙俠道》等9款游戲，累計服務2億多用戶。這里聚集著一群有趣的人，秉持用戶第一、熱愛創作、講邏輯的理念，為贏得百萬人熱愛而奮斗！
《香腸派對》是由真有趣游戲開發、由心動網絡發行的一款“吃雞”游戲，“開局一根腸，裝備全靠撿”，曾連續三年獲得“金翎獎”，擁有非常成熟的職業聯賽。
業務痛點
用戶關系是游戲類應用非常普遍的場景，需要存儲用戶或者玩家之間的相互關系，通過社交關系提升用戶的活躍度以及黏性，幫助玩家及時找到有關聯的好友。在用戶關注關系中，主要包含幾種狀態：
關注我的人->我的粉絲（fans）；
我關注的人->我的關注（follow）；
相互關注的人->互關（mutual）；
拉黑的人->加黑（黑名單）；
其核心表“關注表”對應的表結構示意：
create table user_focus(
id bigint primary key,
uid bigint, -- 用戶ID
focus_uid bigint, -- 關注的用戶ID
extra varchar(1024), -- 其他業務屬性
index idx_focus_uid(focus_uid),
index idx_uid(uid)在業務場景上也分為：
我關注了誰
select * from user_focus where uid=xxx;誰關注了我
select * from user_focus where focus_uid=xxx;玩家圈選，他們關注了誰，誰有關注了他們
select * from user_focus where uid in (xxxx);
select * from user_focus where focus_uid in (xxxx);很容易理解，該表存在uid與focus_uid兩種查詢維度。
我們通過一張單表存儲用戶信息以及關注人的信息，上述這些業務場景的本質就是對基于這張表上不同列的多維查詢。當前這張表的行數已經超過了百億，傳統關系數據庫的能力捉襟見肘。
響應性能達不到預期；
DDL變更的成本非常高；
傳統文檔型數據庫Elasticsearch、MongoDB的方案也只能解決單一維度查詢的問題。
解決方案
透明分布式
PolarDB分布式版兼容MySQL的語法和協議，應用從單機MySQL遷移過來無需修改代碼，應用研發可以保持以前使用MySQL的思路和習慣。通過指定分區鍵的方式，輕松完成數據拆分，業務無感且透明，不再有任何分庫分表的限制，分區鍵、分區數均可自由調整。
在PolarDB分布式版中，我們使用分區表的語法對表進行水平拆分，在本例中，我們對表按照uid進行分區：
create table user_focus( id bigint primary key, uid bigint, -- 用戶ID focus_uid bigint, -- 關注的用戶ID extra varchar(1024), -- 其他業務屬性 index idx_focus_uid(focus_uid), index idx_uid(uid) ) partition by hash(uid);
全局二級索引
PolarDB分布式版支持全局索引，在對數據做了水平拆分的基礎上，還能支持業務的多維度查詢的需求。通過創建全局二級索引，空間換時間，通過數據冗余的方式。
為了滿足focus_uid上的查詢，我們只需要執行一條DDL語句，即可為表創建一個全局二級索引：
create global index gsi_focus_uid on user_focus(focus_uid) partition by hash(focus_uid);
全局二級索引本質是一種數據冗余。例如，當執行一條SQL：
INSERT INTO user_focus (id,uid,focus_uid,extra) VALUES (1,99,1000,"xxx");可以簡單理解為，會分別往主表與gsi_focus_uid寫入一條記錄：
INSERT INTO user_focus (id,uid,focus_uid,extra) VALUES (1,99,1000,"xxx");INSERT INTO gsi_focus_uid (id,uid,focus_uid) VALUES (1,99,1000);其中user_focus主表的分區鍵是uid，gsi_focus_uid的分區鍵是focus_uid。
同時，由于這兩條記錄大概率不會在一個DN上，為了保證這兩條記錄的一致性，我們需要把這兩次寫入封裝到一個分布式事務內（這與單機數據庫中，二級索引通過單機事務來寫入是類似的）。
當我們所有的DML操作都通過分布式事務來對全局索引進行維護，二級索引和主鍵索引就能夠一直保持一致的狀態了。
性能測試
業務壓測過程中進行了全局索引的創建，索引添加過程是在線進行的，不會鎖表。
數據庫的響應時間由創建前的平均數百毫秒，下降到了創建后的1-2ms，同時TPS提升了數百倍：
數據庫響應時間，單位毫秒
同時，全局索引的添加，使得絕大多數查詢做到了“本地化”，可以理解為，一個SQL只對一個DN發起請求。這樣，整個系統擁有了極高的擴展上限，可以做到線性擴展，也即如果10個節點可以支撐50W的QPS，那么20個節點就可以支撐100W的QPS。
下圖是業務上線后的效果，使用8個節點，在峰值達到20W QPS的情況下，依然保持著1ms的響應時間：
數據庫QPS，峰值20W左右
數據庫響應時間，單位毫秒
客戶收益
百億數據查詢從100毫秒下降到2毫秒級，RT提升50倍。
同等規格下TPS提升100倍，輕松應對百萬QPS場景。
分布式改造對業務透明，代碼零修改。
客戶證言
“PolarDB分布式版有極強的線性擴展能力，能夠多寫多讀；它的全局索引能力，是分布式改造的利器，成功解決了傳統分布式方案中多維度查詢的難題，在《香腸派對》的好友系統上，實現了百億好友關系20萬QPS的毫秒級查詢。”
——廈門真有趣《香腸派對》服務端主程 洪光裕