靈域

內(nèi)存泄露

• 現(xiàn)象：項(xiàng)目上線一周左右，客服反饋玩家操作反映很卡，而在線玩家并不多
• 后臺：top發(fā)現(xiàn)CPU占用接近100%(單核)
• 排查問題：
  • 初步推斷內(nèi)存泄露或者內(nèi)存不足引起大量fullgc，導(dǎo)致gc線程占用大量cpu
  • 通過：jstat -gc pid 查看gc情況
  • 從下面輸出可以看到fullgc次數(shù)達(dá)到81次，fullgc的時(shí)間差不多124秒，即2分多鐘
  • 初步斷定cpu過高的原因是因?yàn)榇罅縡ullgc，而fullgc的原因通常是因?yàn)閮?nèi)存占用過高
  • 通過：jmap -heap pid 查看堆內(nèi)存占用信息
  • 從下面的輸出可以看到concurrent mark-sweep generation（老年代）的內(nèi)存占用已經(jīng)使用了98%
  • 通過：jmap -histo pid查看對內(nèi)存的對象數(shù)量和占用大小
  • 從下面的輸出可以看到：
    • 第一位的是[B，即byte[]數(shù)組，差不多占用了1個(gè)多G,因?yàn)槭莝hallow size，所以這里是實(shí)實(shí)在在的byte[]數(shù)組申請
    • 在程序中，直接搜索byte[]的引用相關(guān)，通常可以確定泄露的對象
    • 通過程序查找(有一些第三方庫沒有關(guān)聯(lián)源代碼)，發(fā)現(xiàn)引用byte[]的對象，結(jié)合輸出發(fā)現(xiàn)遠(yuǎn)遠(yuǎn)達(dá)不到60多萬個(gè)實(shí)例的數(shù)量級(如ByteBuffer/HeapByteBUffer)
    • 總共有60多萬個(gè)byte[],在直接導(dǎo)出的對象中實(shí)例中查找類似數(shù)量級的，找到一個(gè)對象：
      22: 599961 14399064 com.google.protobuf.LiteralByteString
    • 查看LiteralByteString的源代碼(protobuf的源代碼),其持有一個(gè)byte數(shù)組的，而其被調(diào)用是通過ByteString#copyFrom調(diào)用，調(diào)用一次方法都會new一個(gè)LiteralByteString對象
    • 進(jìn)而查找ByteString#copyFrom的調(diào)用層次，排查到了BFResult#buildReplaydata
    • 即對于實(shí)際業(yè)務(wù)來說，要緩存每個(gè)玩家15天的戰(zhàn)報(bào)，而戰(zhàn)報(bào)的BattleReplayData都會持有一個(gè)ByteString.copyFrom返回的LiteralByteString(bindata),從而確定泄露的主要原因是內(nèi)存的戰(zhàn)報(bào)數(shù)據(jù)過大
    • 另外注意protobuf中協(xié)議對象中的String類型的字段實(shí)現(xiàn)都是利用ByteString,所以也會持有LiteralByteString
• 總結(jié)：
  • 本地cache使用lru_cache，將近期最少使用的數(shù)據(jù)移除內(nèi)存,保證本地cache在一個(gè)比較穩(wěn)定的數(shù)值
  • 將戰(zhàn)報(bào)數(shù)據(jù)放在遠(yuǎn)程的redis中，從而避免本地jvm內(nèi)存過大從而引起頻繁gc

YGC     YGCT    FGC    FGCT     GCT   
171   12.978  81    123.925  136.903

Heap Usage:
New Generation (Eden + 1 Survivor Space):
    capacity = 314048512 (299.5MB)
    used     = 188444480 (179.71466064453125MB)
    free     = 125604032 (119.78533935546875MB)
    60.00489503991027% used
Eden Space:
    capacity = 279183360 (266.25MB)
    used     = 164671168 (157.04266357421875MB)
    free     = 114512192 (109.20733642578125MB)
    58.983160027875584% used
From Space:
    capacity = 34865152 (33.25MB)
    used     = 23773312 (22.6719970703125MB)
    free     = 11091840 (10.5780029296875MB)
    68.18645735432331% used
To Space:
    capacity = 34865152 (33.25MB)
     used     = 0 (0.0MB)
     free     = 34865152 (33.25MB)
    0.0% used
concurrent mark-sweep generation:
    capacity = 2872311808 (2739.25MB)
    used     = 2842293544 (2710.6223526000977MB)
    free     = 30018264 (28.627647399902344MB)
    98.9549092853919% used

num     #instances         #bytes  class name
----------------------------------------------
 1:        609212     1170636376  [B
 2:      40153651      642458416  java.lang.Float
3:       8681504      347260160  san.game.attribute.value.complexValue
4:       2229486      204888400  [Ljava.lang.Object;
5:       6010272      144246528  san.game.attribute.value.byteValue
6:       5008560      120205440  san.game.attribute.value.floatValue
 7:       4063436       97522464  java.util.ArrayList
8:       6010272       96164352     san.game.attribute.changeProcessor.attrChangeProcessor$esProcessor
9:       5728549       91656784  java.lang.Byte
10:        875024       42001152  san.game.talent.TalentSubitem
11:        333904       37397248  san.game.character.GameCharacter
12:       1001712       32054784  san.game.attribute.AttributeModifyer
13:       1268096       30434304  san.game.character.AttrModifySet$Attr
14:        598886       28746528  san.proto.SanCommon$BattleReplayData
15:        633698       25347920  san.game.skill.impls.NormalSkill
16:       1001712       24041088  san.game.attribute.value.intValue
17:        715739       22903648  java.util.HashMap$Node
18:        502983       19150384  [C
19:        272713       16792672  [I
20:        634048       15217152  san.game.character.AttrModifySet
21:        604388       14505312  java.lang.Long
22:        599961       14399064  com.google.protobuf.LiteralByteString

public static ByteString copyFrom(byte[] bytes, int offset, int size) {
    byte[] copy = new byte[size];
    System.arraycopy(bytes, offset, copy, 0, size);
    return new LiteralByteString(copy);
}

public java.lang.String getPlayerName() {
      java.lang.Object ref = playerName_;
      if (ref instanceof java.lang.String) {
    return (java.lang.String) ref;
      } else {
    com.google.protobuf.ByteString bs = 
        (com.google.protobuf.ByteString) ref;
    java.lang.String s = bs.toStringUtf8();
    if (bs.isValidUtf8()) {
      playerName_ = s;
    }
    return s;
      }
    }
public com.google.protobuf.ByteString getPlayerNameBytes() {
  java.lang.Object ref = playerName_;
  if (ref instanceof java.lang.String) {
com.google.protobuf.ByteString b = 
    com.google.protobuf.ByteString.copyFromUtf8(
    (java.lang.String) ref);
playerName_ = b;
return b;
  } else {
return (com.google.protobuf.ByteString) ref;
  }
}

如何計(jì)算對象大小

• 在上一個(gè)例子中，通過jmap可以查看堆內(nèi)存中對象的實(shí)例和大小，如

num     #instances         #bytes  class name
----------------------------------------------
   1:       8095738      129531808  java.lang.Float
   3:       1731886       69275440  san.game.attribute.value.complexValue

• 第二列是實(shí)例的數(shù)目，第三列是實(shí)例占用的字節(jié)數(shù)，第四列是類的名字
• HotSpot的對齊方式為8字節(jié)對齊：
  • （對象頭 + 實(shí)例數(shù)據(jù) + padding） % 8等于0且0 <= padding < 8
• Float對象大小計(jì)算
  • Float類中只有一個(gè) private final float value,4個(gè)字節(jié)，即實(shí)例數(shù)據(jù)為4個(gè)字節(jié)
  • 32位對象頭8個(gè)字節(jié)，64位16個(gè)字節(jié)
  • 通過：jinfo pid查看是否開啟指針壓縮(64bit 1.8 JVM)，可以看到默認(rèn)開啟了指針壓縮，即-XX:+UseCompressedOops,所以對象頭變?yōu)榱?2字節(jié)
  • 所以對象大小：對象頭：12字節(jié) + 實(shí)例數(shù)據(jù)：4字節(jié) = 16字節(jié) = 129531808 / 8095738
• complexValue對象大小計(jì)算
  • 同上，對象頭：12字節(jié)
  • 當(dāng)前類有3個(gè)Float引用+1個(gè)iRelateCalculator引用
  • 引用在32bit上是4個(gè)字節(jié)、64bit是8個(gè)字節(jié)、開啟指針壓縮后是4個(gè)字節(jié)，即當(dāng)前類的實(shí)例數(shù)據(jù)是：4 * 4 = 16字節(jié)
  • 父類:iSimpleValue中有1個(gè)Float引用和一個(gè)iAttrChangeProcessor引用，即父類的實(shí)例數(shù)據(jù)是：2 * 4 = 8個(gè)字節(jié)
  • 所以對象大小：12 + 16 + 8 = 36
  • 加上對其padding = 40（8的倍數(shù)）= 69275440 / 1731886
• 總結(jié)：
  • 通過jmap -histo查看的對象內(nèi)存占用大小指的是shallow size
  • HotSpot VM的自動內(nèi)存管理系統(tǒng)要求對象起始地址必須是8字節(jié)的整數(shù)倍，換句話說就是對象的大小必須是8字節(jié)的整數(shù)倍。對象頭部分正好似8字節(jié)的倍數(shù)（1倍或者2倍），因此當(dāng)對象實(shí)例數(shù)據(jù)部分沒有對齊的話，就需要通過對齊填充來補(bǔ)全
  • 要考慮是否開啟指針壓縮

VM Flags:
Non-default VM flags: 
    -XX:CICompilerCount=3 
    -XX:+HeapDumpOnOutOfMemoryError 
    -XX:InitialHeapSize=4294967296 -XX:MaxHeapSize=4294967296 
    -XX:MaxNewSize=348913664 -XX:MaxTenuringThreshold=6 
    -XX:MinHeapDeltaBytes=196608 -XX:NewSize=348913664 
    -XX:OldPLABSize=16 -XX:OldSize=3946053632 
    -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

如何找到j(luò)ava進(jìn)程占用cpu最高的線程調(diào)用

• jps：找到j(luò)ava進(jìn)程id
• top -H -p pid：列出pid下線程占用情況 或者top -Hp pid
• printf 0x%x tid：找到那個(gè)線程pid，轉(zhuǎn)為16進(jìn)制
• jstack pid > pid_stack.log ：打印線程堆棧并重定向文件
• 在pid_stack.log中查詢上面找到的線程tid
• 本例來看：可以看到nio的這個(gè)線程cpu占用很高：
  • 因?yàn)樵擁?xiàng)目網(wǎng)絡(luò)層不是是直接用nio2這個(gè)庫寫的，而非用網(wǎng)絡(luò)層框架netty等
  • JDK NIO的BUG，例如臭名昭著的epoll bug，它會導(dǎo)致Selector空輪詢，最終導(dǎo)致CPU 100%。官方聲稱在JDK1.6版本的update18修復(fù)了該問題，但是直到JDK1.7版本該問題仍舊存在，只不過該bug發(fā)生概率降低了一些而已，它并沒有被根本解決
  • 關(guān)于這個(gè)bug相關(guān)的文章以及其他框架如netty是如何解決這個(gè)問題
    • http://ifeve.com/netty-2-6/
    • http://bugs.java.com/bugdatabase/viewbug.do?bugid=6403933
    • http://bugs.java.com/bugdatabase/viewbug.do?bugid=2147719
    • http://www.tkk7.com/killme2008/archive/2009/09/28/296826.html
    • http://www.infoq.com/cn/articles/netty-reliability/
• cpu 100% 通常的思路是查看runnable的線程

"pool-1-thread-5" #16 prio=5 os_prio=0 tid=0x00007f5c94383800 nid=0x6004 runnable [0x00007f5c6dffe000]
   java.lang.Thread.State: RUNNABLE
    at sun.nio.ch.EPoll.epollWait(Native Method)
    at sun.nio.ch.EPollPort$EventHandlerTask.poll(EPollPort.java:194)
    at sun.nio.ch.EPollPort$EventHandlerTask.run(EPollPort.java:268)
    at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

登陸壓力測試

• QA測試流程（python腳本）
  • 從connect開始，到登陸中涉及到每一條協(xié)議，都做一個(gè)計(jì)時(shí)(從發(fā)送某條協(xié)議到收到該協(xié)議的reply的時(shí)間)，同時(shí)會對每個(gè)協(xié)議做響應(yīng)計(jì)數(shù)，即收到多少響應(yīng)
  • 壓測n人，如500人，循環(huán)登陸，1人登陸完退出才有新的加入，始終保持500人
  • 跑n分鐘，如5分鐘，計(jì)算5分鐘之內(nèi)處理了多少登陸所有的請求，即最終收到了多少個(gè)done，即登陸完成的reply，然后用這個(gè)值 / 5 * 60 即得到每秒處理的登陸的數(shù)目
• 消息流程：
  • CHECKVERSION---CHECKVERSION_REPLY檢查版本
  • LOGIN--- LOGIN_REPLY登陸驗(yàn)證
  • MAINCHARCREATE --- MAINCHARCREATEREPLY + LOADDATA_OVE 創(chuàng)建角色
• 流程分析：
  • 檢查版本，這個(gè)沒有耗時(shí)
  • 登陸驗(yàn)證，因?yàn)槭莾?nèi)部dev登陸，所以沒有直接返回登陸成功
  • 登陸成功后，去數(shù)據(jù)庫加載賬號角色信息
  • 如果賬號角色下沒有信息，客戶端會發(fā)送創(chuàng)建角色
  • 創(chuàng)建角色
    • 去賬號中心獲取一個(gè)唯一id
    • 存庫
    • 存庫成功后向客戶端返回創(chuàng)建角色回復(fù)和加載數(shù)據(jù)結(jié)束的消息
• 優(yōu)化及改進(jìn)
  • 數(shù)據(jù)庫部分
    • 該項(xiàng)目最初的數(shù)據(jù)層這部分就是一個(gè)單線程+一個(gè)數(shù)據(jù)庫操作隊(duì)列+1個(gè)數(shù)據(jù)庫連接
    • 登陸壓測的時(shí)候執(zhí)行幾十萬次加載賬號角色的數(shù)據(jù)庫操作，全部阻塞在了這塊導(dǎo)致大量等待
    • 解決：使用數(shù)據(jù)庫連接池+多線程+多隊(duì)列，改進(jìn)后處理數(shù)量級直線上升
  • 邏輯優(yōu)化
    • 創(chuàng)建角色存庫的時(shí)候，調(diào)用的是通用的存庫方法，該存庫方法大約執(zhí)行了8,9條的數(shù)據(jù)庫操作（角色其他相關(guān)信息等）
    • 修正這里：創(chuàng)建角色存庫的時(shí)候只需要存儲角色基本信息
    • 對于創(chuàng)建角色回復(fù)和加載數(shù)據(jù)完畢回復(fù)兩條消息不需要等待創(chuàng)建角色存庫回調(diào)返回后再發(fā)送給客戶端，在賬號中心獲取完id后直接回包
    • 另外在加載賬號信息后server這邊可以直接主動創(chuàng)建角色，而非是給客戶端回一個(gè)包客戶單再發(fā)送創(chuàng)建角色消息（歷史原因：上一個(gè)項(xiàng)目的游戲是可以讓玩家選擇創(chuàng)建角色的），需要客戶端配合修改
  • 其他優(yōu)化
    • 數(shù)據(jù)庫連接數(shù)目、多線程數(shù)、多隊(duì)列數(shù) 不斷的進(jìn)行調(diào)優(yōu) 確定一個(gè)合適的值
    • 網(wǎng)絡(luò)層這塊在壓測部分出現(xiàn)了epollWait，即經(jīng)常cpu飆滿，原因上面已經(jīng)解釋了，建議網(wǎng)絡(luò)層這部分修改為netty等nio框架
    • 將數(shù)據(jù)庫操作細(xì)化，如對于加載角色數(shù)據(jù)這樣的操作，屬于邏輯數(shù)據(jù)數(shù)據(jù)庫操作，會影響玩家感受的操作，這樣的操作會一個(gè)單獨(dú)的數(shù)據(jù)庫線程池去操作；而對于類似玩家下線存盤的操作放到另外一個(gè)數(shù)據(jù)庫線程池去操作；當(dāng)然必須要考慮到順序的問題，如A玩家的存儲是在A線程，而加載是在B線程，二者的順序如果不確定的話會造成嚴(yán)重的問題
    • 必須使用緩存，建議使用redis
  • 其他問題
    • 項(xiàng)目中有一個(gè)策略即玩家下線后不從內(nèi)存移除，這個(gè)時(shí)間默認(rèn)是10分鐘
    • 而持續(xù)壓測（連續(xù)5分鐘）倒進(jìn)了大約4,5w人，相當(dāng)于4,5w同時(shí)在線，此時(shí)內(nèi)存撐不住了，導(dǎo)致大量的fullgc，從而因?yàn)閏pu飆滿
    • 解決：
      • 修改斷線存庫的時(shí)間，由10分鐘改為了2分鐘，但是處理大約30000多個(gè)請求后，壓測客戶端基本收不到請求了
      • 懷疑原因是因?yàn)檫^了2分鐘，大量的數(shù)據(jù)開始從內(nèi)存移除（解決了fullgc問題），開始大量的執(zhí)行存盤操作，從而登陸load這種數(shù)據(jù)庫操作一直在等待
    • 所以需要平衡內(nèi)存、效率等問題，結(jié)合調(diào)優(yōu)數(shù)據(jù)做出最好的選擇

IOS刷單

• 充值流程
  • 客戶發(fā)起充值-> SDK -> ios返回訂單
  • 金山通行證去蘋果驗(yàn)證 -> 驗(yàn)證通過 -> 給xg（有效訂單)
  • xg再次去蘋果驗(yàn)證 -> 驗(yàn)證通過-> 回調(diào)游戲
• 如何刷單
  • 玩家利用軟件利用一個(gè)原始訂單偽造多個(gè)訂單 -> 發(fā)起了充值 -> 偽造ios驗(yàn)證中心返回一個(gè)偽訂單
  • 而金山通行證服務(wù)器端未做排重處理 ->導(dǎo)致驗(yàn)證通過從轉(zhuǎn)xg -> xg驗(yàn)證該訂單也存在
  • 回調(diào)游戲 -> 造成刷單
• 解決
  • xg和金山通行證都應(yīng)該校驗(yàn)訂單重復(fù)等

禮包碼問題

• 現(xiàn)象：運(yùn)營測試禮包碼時(shí)一直失敗，而其他人測試禮包碼則沒有任何問題
• 異常：

ERROR] GmVerifyGiftCard error : java.lang.IllegalArgumentException: Illegal character in query at index 72: http://charge.ly.xoyo.com/gm_center/gift_card_check.php?cardnum=000223ec
&serverid=10006&username=meizu%26meizu__117598875&channelid=meizu

• 即一致提示禮包碼參數(shù)異常
• 解決：
  • 通過cat -A 2016-04-07_error.log
  • -A, --show-all equivalent to -vET
  • -E, --show-ends display $ at end of each line
  • 即通過cat -A參數(shù)可以在行尾打印$
  • 此時(shí)查看：發(fā)現(xiàn)carnum后面多了一$，即輸入的禮包碼有一個(gè)回車換行
  • 則只需要在server中對輸入的禮包碼進(jìn)行過濾即可
• 原因：
  • 運(yùn)營為測試游戲方便，是在pc使用的安卓模擬器進(jìn)行的禮包碼測試
  • 而禮包碼測試是從excel粘貼而來的，但是運(yùn)營粘貼的是單元格，而不是單元格內(nèi)容，粘貼單元格就會多一個(gè)換行
  • 已在linux#vim測試并通過cat -A測試（即粘貼excel單元格確實(shí)會多一個(gè)換行）

http://charge.ly.xoyo.com/gm_center/gift_card_check.php?cardnum=000223ec$
&serverid=10006&username=meizu%26meizu__117598875&channelid=meizu  $

金山云LB問題

• 現(xiàn)象：線上大量的登陸驗(yàn)證超時(shí)-SocketTimeoutException
• 原因：
  • 登陸驗(yàn)證的url在外網(wǎng)可以訪問
  • 但是ssh登陸游戲服務(wù)器后，用curl則無法訪問
• 總結(jié)：
  • 理論上和xg一點(diǎn)關(guān)系沒有，但是xg用的金山云，使用的外網(wǎng)負(fù)載.如果你從外網(wǎng)訪問西瓜的負(fù)載不會有任何問題的
  • 簡單來說：就是金山云內(nèi)部機(jī)器相互訪問（內(nèi)部的機(jī)器訪問內(nèi)部機(jī)器的外網(wǎng)負(fù)載）有問題
  • 金山云忽略了，可能內(nèi)網(wǎng)訪問一個(gè)沒有內(nèi)網(wǎng)策略的外網(wǎng)負(fù)載，他的路由沒有走公網(wǎng)，而是在金山云內(nèi)部的路由，造成response有問題
  • 金山云自己判斷了你訪問的是外網(wǎng)，但是實(shí)際請求就沒有出外網(wǎng)，直接在內(nèi)部判斷了
  • 臨時(shí)解決方案：
    • 西瓜的入訪添加一個(gè)我們的內(nèi)網(wǎng)ip
    • xg: 防火墻這塊加好后，需要提供ip給金山云的同事 修改一下底層配置
  • 是金山云LB（負(fù)載均衡）的bug
• 建議：新服上線前，都可能需要測試網(wǎng)絡(luò)連通性以及添加內(nèi)網(wǎng)防火墻了

線上玩家利用WPE抓包修改協(xié)議包

• 真實(shí)玩家利用服務(wù)器邏輯漏洞，利用wpe修改包，達(dá)到作弊目的(運(yùn)營同學(xué)打入玩家內(nèi)部，是一個(gè)15歲的00后)
• 如：
  • 卡牌游戲上陣可以設(shè)置一個(gè)先鋒技，先鋒技可以加怒氣
  • 但服務(wù)器邏輯未判斷只能有一張卡牌用先鋒技能
  • 玩家利用wpe修改協(xié)議包，修改為5張上陣卡牌都使用了先鋒技（正常客戶端已經(jīng)屏蔽掉只能使用一個(gè)先鋒技），這樣服務(wù)器計(jì)算怒氣很大，從而達(dá)到無敵
• 總結(jié)：
  • 服務(wù)器邏輯一定要嚴(yán)謹(jǐn),The Server is the man
  • 可在協(xié)議設(shè)計(jì)這塊做的更好一些，讓作弊的成本最大化，可參考
    • 網(wǎng)絡(luò)游戲的網(wǎng)絡(luò)協(xié)議設(shè)計(jì)之防外掛

合服后啟動server失敗

• 現(xiàn)象：啟動一段時(shí)間后，查看log（tail -f）一直停留在加載競技場玩家數(shù)據(jù)中，沒有繼續(xù)啟動下去；而正常的log會有加載競技場玩家數(shù)據(jù)完畢的log，且會繼續(xù)啟動
• 排查
  • jmap/top/jstat 查看內(nèi)存 cpu gc等都沒有任何問題
  • jstack導(dǎo)出線程堆棧，也沒發(fā)現(xiàn)有線程阻塞，不過導(dǎo)出線程堆棧之后 發(fā)現(xiàn)沒有主線程
  • 反思
    • 其實(shí)在用jstack查看線程堆棧的時(shí)候沒有main，即說明主線程退出了，肯定是有error-所以當(dāng)時(shí)就應(yīng)該直接查詢error，而不是對比啟動成功的日志(會輸出加載競技場數(shù)據(jù)完畢的消息)和啟動失敗的日志
    • 因?yàn)閱映晒螅骶€程還會在，因?yàn)闀O(jiān)聽kill命令，啟動后的主線程的堆棧類似如下
    • 即如果發(fā)現(xiàn)主線程不存在，則說明中間邏輯出了問題
    • 而且出問題的時(shí)，應(yīng)該直接查詢?nèi)罩镜膃rror或者異常信息，第一時(shí)間排查，而不是tail -f
• 原因
  • 因?yàn)楹戏?數(shù)據(jù)庫幾十萬條數(shù)據(jù))導(dǎo)致加載競技場數(shù)據(jù)(5000人)時(shí)間過長，超過10分鐘
  • 主線程LogicServerMngr#loadGlobalData 有一個(gè)防御式編程
    • 即主線程會每隔100s去檢查是否已經(jīng)加載了5000人，如果沒有加載完則一直while -> 如果加載完畢則直接返回 -> 主線程邏輯繼續(xù)跑；如果加載時(shí)間超過了10分鐘則直接返回
  • 查看日志的時(shí)候有一個(gè)疏漏，即運(yùn)維通過tail -f查看日志，只看到了加載競技場玩家的日志，但是其實(shí)在之前，主線程就已經(jīng)有error了：
    • error：global data load timeout.
    • error: Logic server manager startup failed!
  • 因?yàn)檫@個(gè)日志是在主線程輸出的，而加載競技場玩家完畢的消息是在邏輯線程輸出的
    • 是先從數(shù)據(jù)庫加載了競技場的5000個(gè)玩家id
    • 然后扔到db線程依次去加載這5000個(gè)玩家
    • 主線程一個(gè)while，一直去輪訓(xùn)去檢查是否已經(jīng)加載了5000個(gè)玩家并做timeout判斷，主線程判斷超過了10分鐘，則timeout返回
    • 此時(shí)異步線程依然在加載，一直在輸出，導(dǎo)致后續(xù)的輸出覆蓋了之前的timeout輸出 -> 從而排查問題不好排查
• 總結(jié)
  • 看來合服的話，導(dǎo)致數(shù)據(jù)庫非常大，幾十萬的數(shù)據(jù)庫量級，從而使查詢變慢
  • 做好優(yōu)化/用數(shù)據(jù)庫連接池/去掉部分垃圾數(shù)據(jù)
  • 優(yōu)化啟動，不在啟動加載這么多少數(shù)據(jù) -> 或者直接加入到cache中
  • 重啟以后，某個(gè)服成功啟動，這個(gè)應(yīng)該只是概率的，因?yàn)閿?shù)據(jù)庫處理速度誰都不能保證，重啟之后可能速度處理快了一點(diǎn).根本原因還是數(shù)據(jù)庫合服后過于龐大 --> 導(dǎo)致加載時(shí)間過長
  • 目前的解決辦法是修改這個(gè)timeout，改為30分鐘后，則合服后的sever啟動成功

"main" prio=10 tid=0x00007fca1c008800 nid=0x3a24 in Object.wait() [0x00007fca2471e000]
        java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x000000078a404548> (a java.lang.Object)
    at java.lang.Object.wait(Object.java:503)
    at san.server.QuitListener.waitBySignal(QuitListener.java:62)
    - locked <0x000000078a404548> (a java.lang.Object)
    at san.server.QuitListener.waitQuit(QuitListener.java:23)
    at san.server.MainEntry.main(MainEntry.java:37)

long loadTime = System.currentTimeMillis();
    while (!globalDataPersistence.checkArenaLoadOver()) {
        if (System.currentTimeMillis() - loadTime >= 10 * 60 * 1000) {
            LogMessage.error("global data load timeout.");
            return false;
        }
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
        }
    }
        return true;
    }

線上刷元寶（防御式編程）

• 現(xiàn)象
  • 客服同事舉報(bào)某玩家vip等級有異常，剛開服不久便達(dá)到了vip頂級
• 原因：因?yàn)槟硞€(gè)事件處理拋出異常（該異常非畢現(xiàn)），導(dǎo)致很多邏輯出錯
  • 如領(lǐng)取郵件邏輯，郵件中是充值元寶，玩家增加元寶，同時(shí)增加vip經(jīng)驗(yàn)，提升vip等級 ->(vip等級變化)此時(shí)拋出一個(gè)事件處理 -> 異常
  • 導(dǎo)致玩家郵件未正常刪除，玩家再次進(jìn)入游戲會繼續(xù)領(lǐng)取郵件，從而造成刷元寶
  • 同時(shí)增加元寶這個(gè)統(tǒng)計(jì)也因?yàn)楫惓]有統(tǒng)計(jì)到數(shù)據(jù)庫中，給排查人員造成了很大的困難
  • 直到VIP等級達(dá)到上限，不繼續(xù)走異常邏輯從而結(jié)束，數(shù)據(jù)庫中只記錄了一條最后的充值元寶記錄
• 解決
  • 當(dāng)一個(gè)邏輯很復(fù)雜，含有多個(gè)子邏輯的時(shí)候，線上環(huán)境最好防御式編程，每個(gè)子邏輯都try/catch
  • 本例這個(gè)異常是因?yàn)橐粋€(gè)記錄日志引起的異常，而通常這種異常絕對不應(yīng)該讓程序邏輯出錯，所以這種記錄日志的接口最好做一個(gè)包裝類，然后記錄日志的方法本身做try/catch
• 引申
  • 想起了之前西游線上的一個(gè)類似問題，就是調(diào)度程序的問題，如0點(diǎn)的時(shí)候會有很多調(diào)度子邏輯，而如果其中一個(gè)調(diào)度子邏輯出現(xiàn)異常的時(shí)候，則影響了后面的自邏輯從而造成邏輯錯誤
  • 和上面一樣，對于這種調(diào)度邏輯，子邏輯一定要try/catch，尤其是對于這種一個(gè)方法內(nèi)子邏輯非常多的情況

域名擴(kuò)散

• 因重新部署環(huán)境需要將域名指向的ip替換為新的負(fù)載均衡地址
• 域名擴(kuò)散問題：即域名解析換后，有一個(gè)擴(kuò)散問題，即有一部分網(wǎng)絡(luò)還會訪問舊的解析地址，為了保證能訪問，則舊的服務(wù)器還需要維護(hù)兩三天
• 原因：
  • dns是多級解析，每一級dns都可能緩存記錄；即使修改了dns的記錄，要使其生效也需要較長時(shí)間，這段時(shí)間dns仍然會將域名解析到舊的服務(wù)器，導(dǎo)致用戶訪問失敗

mysql的連接允許的閑置時(shí)間

• 現(xiàn)象：
  • 當(dāng)seerver運(yùn)行一段時(shí)間后，拋出異常：java.sql.SQLException: Could not retrieve transation read-only status server
• 原因：
  • 使用了HikariCP，但是某些參數(shù)設(shè)置有一些問題
  • Configure your HikariCP idleTimeout and maxLifeTime settings to be one minute less than the wait_timeout of MySQL
  • mysql的連接允許的閑置時(shí)間，當(dāng)超過閑置時(shí)間以后，database端就會將此連接單方面廢棄，這時(shí)如果使用jdbc繼續(xù)使用之前的連接則拋異常
• 解決：
  • config.setMaxLifetime(86400000 - TimeUnit.MINUTES.toMillis(1))
  • config.setIdleTimeout(86400000 - TimeUnit.MINUTES.toMillis(1))

西游降魔篇3D

數(shù)據(jù)庫更新方式

• 服務(wù)器開服時(shí)用的數(shù)據(jù)庫表腳本必須是包括最新的數(shù)據(jù)庫表
• 只有當(dāng)真正線上數(shù)據(jù)庫表需要變化的時(shí)候，才需要發(fā)送更新郵件，將線上舊的服務(wù)器表更新，而不要提前發(fā)送更新數(shù)據(jù)表表的郵件 -> 即代碼版本和數(shù)據(jù)表的版本要一致
• 原因：
  • 上一個(gè)大版本1.7.6在更新的時(shí)候，因?yàn)橄雀聹y試服，所以測試服的數(shù)據(jù)庫表更至最新。但是本人當(dāng)時(shí)（提前）發(fā)了一封郵件，同時(shí)將線上的所有服務(wù)器提前增加新增的數(shù)據(jù)庫表
  • 但是此時(shí)線上的大版本為1.7.0，后續(xù)新開的服務(wù)器很多服務(wù)器都會清檔，用1.7.0的包新建服務(wù)器，而1.7.0的服務(wù)器中的數(shù)據(jù)庫表還是舊的.從而導(dǎo)致后續(xù)1.7.6版本更新的時(shí)候未做數(shù)據(jù)庫更新(1.7.6版本未發(fā)送數(shù)據(jù)庫更新郵件)
  • 而ios的1.7.6版本又和android大區(qū)的更新時(shí)間不一致,導(dǎo)致我忽略了ios的大版本更新時(shí)間從而使ios新開的一些服務(wù)器的數(shù)據(jù)表是舊的
• 總結(jié)：
  • 注意運(yùn)維新建服務(wù)器的時(shí)候都會進(jìn)行清檔操作,在此之前對該服務(wù)器做的所有操作都會被清除
  • 一定要明確線上ios和android通常版本更新的時(shí)間都不一樣，ios通常會晚一些
  • 運(yùn)維通常會提前準(zhǔn)備好服務(wù)器，部署環(huán)境，正式開服的時(shí)候只需要清檔即可
• 新版本線上更新時(shí)，如果增加了新的sql，需要通知運(yùn)維更新相關(guān)大區(qū)線上的游戲服務(wù)器同步更新數(shù)據(jù)庫
  • 因?yàn)閕os版本和android版本更新時(shí)間不同，通常是android版本先更新.所以會出現(xiàn)如下問題
    • android 1.8.0 更新,數(shù)據(jù)庫更新，通知運(yùn)維更新所有android大區(qū)游戲服務(wù)器數(shù)據(jù)庫
    • 此時(shí)ios大區(qū)還是1.7.5版本,數(shù)據(jù)庫也是1.7.5版本
      • 因?yàn)閕os大區(qū)和android大區(qū)的數(shù)據(jù)庫是混在一起的 -> 所以運(yùn)維希望在更新android 1.8.0時(shí)候，順便將ios大區(qū)的數(shù)據(jù)庫也更新為1.8.0 -> 目前操作也是這樣的
      • 如果不更新1.7.5版本的數(shù)據(jù)庫 -> 即使將ios大區(qū)的數(shù)據(jù)庫提前更新至1.8.0 ->但是因?yàn)楹罄m(xù)ios大區(qū)開新服，會清檔 -> 會重新用1.7.5下的數(shù)據(jù)庫更新 -> 從而以后在更新1.8.0的時(shí)候，運(yùn)維需要查詢哪些服務(wù)器是新開的(更新數(shù)據(jù)庫的時(shí)候會將已部署的所有數(shù)據(jù)庫均進(jìn)行更新，但是因?yàn)樾麻_的服務(wù)器會進(jìn)行回檔，所以要找出這些新開的服務(wù)器更新至1.8.0)，然后同步更新至1.8.0 -> 非常麻煩
  • 總結(jié)：
    • 新版本如1.8.0更新數(shù)據(jù)庫的時(shí)候，請順便將還在運(yùn)營如1.7.5版本的數(shù)據(jù)庫更新至1.8.0（即1.7.5的建庫腳本更新至1.8.0）
    • 即使1.7.5版本開新服的時(shí)候，數(shù)據(jù)庫也能保證是最新的 -> 即使清檔 -> 也沒有問題
    • 注意這種方式均是增量更新，而不是對已有的sql進(jìn)行修改 -> 如果是對原有sql修改的話，必須要保證代碼版本和sql版本一致

IOS正版無法登陸（小米為發(fā)行方）

• 小米SDK的BUG，匿名用戶綁定帳號后，繼續(xù)用匿名帳號去綁定帳號的接口驗(yàn)證，所以登陸失敗
• 部分網(wǎng)絡(luò)環(huán)境下，訪問　account.xiaomi.com 域名失敗，導(dǎo)致小米帳號無法登陸
• 玩家綁定小米帳號后，修改密碼后，無法登陸，需要修改為原來的密碼才可以正常登陸
• 解決：
  • 只能把問題反饋給小米，由小米這邊進(jìn)行排查

Cause: com.mysql.jdbc.exceptions.MySQLTimeoutException: Statement cancelled due to timeout or client request

• 原因：
  • SQL: select count(*) from player where vip >= ?
  • 執(zhí)行這個(gè)sql的時(shí)候超時(shí)，則直接拋出了異常
  • player表數(shù)據(jù)過大，沒有索引導(dǎo)致查詢超時(shí)
  • playerdata和player二者合二為一了，將playerdata中的text字段拷貝到了player表中，導(dǎo)致player表的數(shù)據(jù)激增，因?yàn)閠ext是二進(jìn)制字段，是玩家數(shù)據(jù)，非常大
• 解決
  • player表增加索引
  • 將player和player_data分開

大量玩家登陸上線頻繁gc

• 戰(zhàn)報(bào)數(shù)據(jù)較大，為了節(jié)省流量，在encode的時(shí)候使用7z進(jìn)行壓縮
• 7z算法實(shí)現(xiàn)的很糟糕-7z庫，里面每次會給自己分配8M內(nèi)存
• 可能會造成大量玩家登陸上線引起的頻繁GC,導(dǎo)致性能嚴(yán)重下降
• 解決：
  • 用gzip壓縮

關(guān)于新手引導(dǎo)問題引起的客戶端卡死

• 客戶端卡死問題太嚴(yán)重，后果也很嚴(yán)重
• 所以最好可以從代碼層次避免，即引導(dǎo)失敗或者一些代碼執(zhí)行失敗不會影響游戲業(yè)務(wù)流程,保證游戲客戶端穩(wěn)定性

線上數(shù)據(jù)庫某時(shí)刻流量極大而且服務(wù)器卡

• 原因：
  • 玩家改名每次去數(shù)據(jù)庫查詢是否有重名，while條件則寫錯了 -> 導(dǎo)致沒有重名繼續(xù)do。。。一直沒有重名。。一直do..死循環(huán)。。
  • 從而也造成了這一時(shí)刻數(shù)據(jù)庫流量極大，因?yàn)橐恢比ゲ閿?shù)據(jù)庫
• 分析：
  • 服務(wù)端用了大量的while，已經(jīng)有很多地方出現(xiàn)了死循環(huán)
  • 很多同學(xué)已經(jīng)打了很多補(bǔ)丁，類似如果循環(huán)超過10000次。。就break等
• 反思：禁用while

IOS Emoji表情存儲

• Emoji 字符的特殊之處是，在存儲時(shí)，需要用到 4 個(gè)字節(jié)。而 MySQL 中常見的 utf8 字符集的 utf8generalci 這個(gè) collate 最大只支持 3 個(gè)字節(jié)。所以為了能夠存儲 Emoji，你需要改用 utf8mb4 字符集
• 對 utf8mb4 字符集的支持是 MySQL 5.5 的新功能，所以你需要確保你使用的 MySQL 版本至少是 5.5
• 如果UTF8字符集且是Java服務(wù)器的話，當(dāng)存儲含有emoji表情時(shí)，會拋出類似如下異常即字符集不支持的異常，因?yàn)閁TF-8編碼有可能是兩個(gè)、三個(gè)、四個(gè)字節(jié)，其中Emoji表情是4個(gè)字節(jié)，而Mysql的utf8編碼最多3個(gè)字節(jié)，所以導(dǎo)致了數(shù)據(jù)插不進(jìn)去
• 解決：
  • 起名的時(shí)候過濾掉emoji表情，判斷字符是否在unicode BMP區(qū)域即可
  • 改動數(shù)據(jù)庫版本則相對影響較大

java.sql.SQLException: Incorrect string value: '\xF0\x9F\x92\x94' for column 'name' at row 1  
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)  
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3593)  
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3525)  
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1986)  
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2140)  
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2620)  
        at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1662)  
        at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1581)

protobuf

• protobuf協(xié)議中的集合是一個(gè)UnmodifiableCollection（非常符合協(xié)議的定義，只讀屬性）
• 不能進(jìn)行移除等修改操作，否則會拋出UnsupportedOperationException

上線回檔

• 原因：
  • 每周四10點(diǎn)例行維護(hù)，策劃提交了一版配置
  • 但是獎勵配置出了問題，正常獎勵元寶是1，現(xiàn)在是10000；正常獎勵靈魂是1，現(xiàn)在是10000
  • 而這些資源都是比較稀缺的，而又有拍賣行可以交易
  • 大量的玩家在刷這些資源，如果影響范圍較大的話，可能會影響所有服務(wù)器的經(jīng)濟(jì)系統(tǒng)
• 解決：
  • 回檔
• 問題：
  • 因?yàn)檫@次例行維護(hù)，只是更新配置表，所以沒有停服
  • 沒有停服則沒有備份數(shù)據(jù)庫
  • 而最近的一次備份庫是上午5點(diǎn)的多(現(xiàn)在備份是每天才備份一次，每天5點(diǎn)多備份一次)
  • 只能通過binlog查詢數(shù)據(jù)操作日志，然后進(jìn)行回檔，回檔到上午10點(diǎn)
• 反思:
  • 例行維護(hù)的時(shí)候最好停服，運(yùn)維那邊停服的時(shí)候備份一下所有的庫
  • 維護(hù)前一定要QA測試策劃修改的東西，程序修改的東西
  • 即一定有一個(gè)人知道這個(gè)版本修改了哪些東西，尤其是策劃修改的重要表的數(shù)值
  • 能否將數(shù)據(jù)庫備份的周期再縮短一下

線上防刷（防御式編程）

• 先扣玩家元寶或者道具，然后再給玩家獎勵
  • 因?yàn)橄冉o玩家獎勵，沒問題，再扣玩家元寶或者道具的時(shí)候可能會拋出異常
  • 從而導(dǎo)致玩家刷/復(fù)制
  • 采用第一種方案則保證即使沒有給玩家獎勵，后續(xù)也可以進(jìn)行補(bǔ)償
• 對于客戶端傳過來的參數(shù)，必須要強(qiáng)制校驗(yàn)，否則如果直接使用外掛（直接發(fā)網(wǎng)絡(luò)包）或者客戶端有bug則也會導(dǎo)致刷的問題出現(xiàn)（如使用wpe）

classloader

• Player對象不能持有XXManager這樣的東西
  • 因?yàn)镻layer對象是由系統(tǒng)類加載器加載的 --> 而XXManager是自定義加載器加載的(path自定義,不在系統(tǒng)類加載器加載的path)，按照雙親原則，Player對象是找不到XXManager的
• 而XXManager是可以持有Player對象的
  • 因?yàn)閄XManager是自定義類加載加載的，當(dāng)加載Player的時(shí)候找不到，則會按照雙親原則由系統(tǒng)類加載器加載Player,而恰恰可以加載到

在線執(zhí)行腳本

• 游戲服務(wù)器邏輯支持hotswap，動態(tài)更新在線service業(yè)務(wù)時(shí),為什么還需要在線執(zhí)行腳本
  • 如9.17的爭霸賽問題，因?yàn)楫惓＃斐蓤?zhí)行某個(gè)重要的方法拋出異常
  • hotswap只支持將這段代碼進(jìn)行修補(bǔ)，但是不能再次執(zhí)行這個(gè)方法
  • 而腳本更新則可以直接更新一個(gè)腳本，腳本內(nèi)容為再次執(zhí)行這個(gè)方法；該方法可以做類似修改一些線上玩家錯誤數(shù)據(jù)，配置表數(shù)據(jù)等

排序bug

• 如果list有兩個(gè)A1,A2,A1的robtime為0，而A2的robTime = System.currentMillis
• 做compareto比較時(shí)，因?yàn)橐獜?qiáng)轉(zhuǎn)為int...所以溢出，造成A2排序的時(shí)候變成了負(fù)數(shù)
• 即： (int)(o.time - time) 這種方式不建議，建議大小做判斷
• 參考effective java相關(guān)章節(jié)

A
{
long time;
}
compareto(A o)
{ 
 return (int)(o.time - time)
}

if (robTime > o.robTime) {return -1;}
if (robTime < o.robTime) {return 1;}
return 0;

因?yàn)榭蛻舳藷o法熱更而需要做的一些妥協(xié)

• 設(shè)計(jì)的時(shí)候除了考慮性能問題，還要考慮客戶端是否支持熱更新
• 如果不支持熱更新，則一些設(shè)計(jì)如以前的設(shè)計(jì)是給客戶端數(shù)據(jù)，客戶端拼接數(shù)據(jù)，如文本消息，但是策劃要改文本消息，消息中的參數(shù)都發(fā)生了變化
• 而客戶端不支持更新 -> 而服務(wù)器可以熱更，可能沒辦法的措施就是服務(wù)器發(fā)送給客戶端拼接后的文本，如果策劃要改，則直接服務(wù)器修改
• 則客戶端無法熱更的情況下，不修改協(xié)議的情況下實(shí)現(xiàn)需求的變更
• 解決：
  • 后續(xù)項(xiàng)目客戶端一定要支持代碼熱更新

服務(wù)器提示文本國際化

• 服務(wù)器代碼國內(nèi)版本和國際版本用一套代碼，包括配置文件
• 所以不能將語言這個(gè)變量不要和服務(wù)器代碼維護(hù)耦合在一起（如配置文件中有一個(gè)選項(xiàng)是多語言，國內(nèi)版本是cn，國外版本如越南用vn，但是如果這樣做的話，就相當(dāng)于維護(hù)了多套代碼）
• 解決
  • 將lang這個(gè)變量放在具體的部署環(huán)境中
  • 如運(yùn)維搭建越南游戲服務(wù)器的時(shí)候手動env.sh中的lang=VN
  • 而這個(gè)env.sh只會在第一次搭建的時(shí)候用到 -> 后續(xù)代碼更新或者版本更新的時(shí)候不會影響這個(gè)env.sh
• 舊方案
  • 服務(wù)器包中有一個(gè)配置來描述語種
  • 打包的時(shí)候指定語種 -> 用來覆蓋這個(gè)配置，相對比較麻煩

其他

• 涉及到給玩家東西的邏輯必須加上log，否則和GM,玩家溝通則沒有證據(jù)
• 關(guān)鍵游戲邏輯業(yè)務(wù)加log，便于排查線上問題
• 在一個(gè)已經(jīng)運(yùn)行了一段很長時(shí)間的代碼上面增加代碼 -> 這段代碼最好try/catch -> 否則可能會影響之前的代碼
• server端支持邏輯熱更新是必須的，會很方便的解決一些問題；不過如果邏輯是無狀態(tài)的話，也可以將這些邏輯放在一個(gè)單獨(dú)的進(jìn)程，需要修改邏輯的時(shí)候直接kill再重啟