達成システム実現(四)-テストと総括

アーキテクチャ設計が完了した後、開発段階に入り、その後、連調テストの調整を経て、約2週間かかり、開発と自己測定が完了し、コードはgithubでオープンソースになった.https://github.com/caisl/achievement-system.git
ユニットテスト:

@Test
    public void finishWelcomeAchievementTest() throws Exception {
        OrderEvent orderEvent = new OrderEvent(entityId, customerRegisterIds, AchievementConstant.EventSource
                .FROM_H5, AchievementEnum.EventTypeEnum.ORDER_EVENT.getType());
        orderEvent.setAction(AchievementEnum.OrderActionEnum.SUBMIT.getCode());
        orderEvent.setOrderType(AchievementConstant.OrderType.ORDER_SHOP);
        eventClient.publish(orderEvent);
        Thread.sleep(5000);
    }

自測の過程でコードに対してdebugを行い、それからどうしてもブレークポイントがイベント処理類に入らないことを発見し、この問題を解決するために、やはり長い間考えていたが、最後に発見したのは、ユニットテストのメインスレッドが早期に閉鎖されたためで、消費者スレッドは非同期で開き、キューから事件を取り出して消費し、Threadを加えたからだ.sleep(5000)は,メインスレッドが常に動作状態を処理していることを保証し,ブレークポイントに入ることができる.
オンライン後の観察:
オンラインにリリースされると、しばらくするとキュー内のイベント消費ブロックの問題が発生します.つまり、消費者スレッドがシーケンス番号のイベントを読み込んだ後、キューから次のイベントを取り外さなくなります.同時にサーバーのloadの上昇に伴って、最初は具体的な原因に位置していないで、サーバーが再起動した後に正常に回復して、それからしばらくしてまた閉塞して、xxxの位置付けを経て以下のようにして、異常処理のこの問題があることを発見して、異常を捉えた後に、また再び投げ出して、消費者のスレッドが閉塞して、ringBufferリングの読み取り消費のため、その他の消費者のスレッドも一緒にカード死を開始します.
具体的な位置決めの過程はこの文章を見ることができます:一回のオンラインサーバーloadの高い問題の位置決めと解決を覚えます
外部から導入されたフレームワークについては、慎重に注意し、その原理とソースコードの実現を理解しなければならない.