ビジネスシステムが操作ログを記録するいくつかの方法
2526 ワード
最近のビジネスシステムでは、操作ログの記録方法を実装する必要があります.このログは様々な実現に対する思考である.
1つの操作ごとに流水を記録するこの方法は、各ステップの操作に非常に重要なシステムに適している.例えば、一般的な金融オペレーティングシステムです.一般的なシーンでは、振り替え、引き落としなど、お金に関する操作についてこのような流水ログを記録するだけです.口座のフローチャートを設計する際には、(1)instruction_id流水番号(2)amount金額(3)operation_type操作タイプ(振込or引き落とし)(4)before_balance操作前口座残高(5)after_balance操作後の口座残高(6)time操作時間の最初のフィールド、フロー番号、メインキーです.このフィールドの必要性は、レコードの変更のべき乗等性を維持できることです.簡単な実装では、流水番号はuuidを使用することができます.現在のエンドがチャージを開始すると、まずフロントエンドにフロー番号が生成され、その後、他のユーザが記入したパラメータがrpc要求によってバックエンドに送信される.バックエンドの処理フローは以下の通りである:(1)オープントランザクション(2)dbから口座残高を問い合わせる(3)口座残高を変更する(4)記録流水(5)コミットトランザクション仮定実行中にネットワーク問題が発生し、その実行結果が未知の状態にある場合、フロントエンドは先ほどのuuidを通じて確定した結果が得られるまで繰り返し再試行することができる.一般的な状況に適応するために、流水計を少し改善することができます.フィールドは次のとおりです:(1)instruction_idストリーム番号(信頼性の要求があまり高くない場合、データベースを使用してidを自己増加することができます)(2)operation_type操作タイプ(3)before(修正前の行レコードを記述するjson)(4)after(json、修正後の行レコードを記述する)(5)timeにはinput_param(パラメータ入力)、オペレータなど.このような流水ベースの方式の利点は、1信頼性が高い2実現方式の決定、インタフェースに基づいて注釈を行うことができる3この流水に基づいて、業務層の操作ロールバックを実現することができるが、その欠点も明らかである:1開発量を増加し、記録書き込みを追加する必要がある2運行効率を低下させ、2回以上のクエリー(before,after)3と業務バインドを必要とする
二データベースベースbinlog実装第二の方法はmysqlベースbinlog実装である.この方法の最大の利点は、トラフィックと完全にデカップリングでき、統計的な結果が完全に正確であることである(トラフィックコードに完全に基づいた実装に比べて、このような実装は一般的に実行前後のクエリに対して2回行われる).binlogの定義と取得については、参照してください.
http://www.jianshu.com/p/1f7889273845
binlogは、以下のようなmodelとして記述することができる.
binlogベースの実装にはもう一つの小さな問題がある.ユーザーの操作idを取得するにはどうすればいいですか?権限付与および権限分離に関連するシステムでは、idの操作が重要です.しかし、このフィールドはビジネス・レイヤに完全に属しているため、データベースの設計との関連性は大きくありません.この問題を解決するには、ユーザー操作に関連するテーブルごとに新しいフィールドoperator_を追加する必要があります.id. もう1つは、ユーザーのステップ操作が複数のテーブルの変更に関連し、このときbinlogをトランザクションidで集約することができる場合です.その後、binlogを操作レコードに変換してライブラリに記録する必要があります.操作レコードのフィールドは以下の通りです.(1)operator_id(オペレータid)(2)operation_type(操作タイプ、テーブルおよびbinlogタイプ(insert,update,delete)に基づいて決定可能)(3)before(json、ローレコード修正前の値を記述する)(4)after(ローレコード修正後の値を記述する)(5)timestamp(タイムスタンプ)
ここで、ユーザ操作ログの生成とクエリーは、全体の流れは以下の通りである:1ユーザ操作修正表2非同期サービス取得binlog 3トランザクションidに基づいてbinlogを一定の集約処理4 binlogを元の操作ログに変換し、ライブラリ5に記録ユーザが操作ログをクエリーすると、条件検索操作ログ6に基づいて操作ログをユーザ可読のviewに変換して返す
1つの操作ごとに流水を記録するこの方法は、各ステップの操作に非常に重要なシステムに適している.例えば、一般的な金融オペレーティングシステムです.一般的なシーンでは、振り替え、引き落としなど、お金に関する操作についてこのような流水ログを記録するだけです.口座のフローチャートを設計する際には、(1)instruction_id流水番号(2)amount金額(3)operation_type操作タイプ(振込or引き落とし)(4)before_balance操作前口座残高(5)after_balance操作後の口座残高(6)time操作時間の最初のフィールド、フロー番号、メインキーです.このフィールドの必要性は、レコードの変更のべき乗等性を維持できることです.簡単な実装では、流水番号はuuidを使用することができます.現在のエンドがチャージを開始すると、まずフロントエンドにフロー番号が生成され、その後、他のユーザが記入したパラメータがrpc要求によってバックエンドに送信される.バックエンドの処理フローは以下の通りである:(1)オープントランザクション(2)dbから口座残高を問い合わせる(3)口座残高を変更する(4)記録流水(5)コミットトランザクション仮定実行中にネットワーク問題が発生し、その実行結果が未知の状態にある場合、フロントエンドは先ほどのuuidを通じて確定した結果が得られるまで繰り返し再試行することができる.一般的な状況に適応するために、流水計を少し改善することができます.フィールドは次のとおりです:(1)instruction_idストリーム番号(信頼性の要求があまり高くない場合、データベースを使用してidを自己増加することができます)(2)operation_type操作タイプ(3)before(修正前の行レコードを記述するjson)(4)after(json、修正後の行レコードを記述する)(5)timeにはinput_param(パラメータ入力)、オペレータなど.このような流水ベースの方式の利点は、1信頼性が高い2実現方式の決定、インタフェースに基づいて注釈を行うことができる3この流水に基づいて、業務層の操作ロールバックを実現することができるが、その欠点も明らかである:1開発量を増加し、記録書き込みを追加する必要がある2運行効率を低下させ、2回以上のクエリー(before,after)3と業務バインドを必要とする
二データベースベースbinlog実装第二の方法はmysqlベースbinlog実装である.この方法の最大の利点は、トラフィックと完全にデカップリングでき、統計的な結果が完全に正確であることである(トラフィックコードに完全に基づいた実装に比べて、このような実装は一般的に実行前後のクエリに対して2回行われる).binlogの定義と取得については、参照してください.
http://www.jianshu.com/p/1f7889273845
binlogは、以下のようなmodelとして記述することができる.
@Data
public class RowDiffModel {
long timestamp;
String tableName;
List pkColumnName = new ArrayList<>(); //
List binlogベースの実装にはもう一つの小さな問題がある.ユーザーの操作idを取得するにはどうすればいいですか?権限付与および権限分離に関連するシステムでは、idの操作が重要です.しかし、このフィールドはビジネス・レイヤに完全に属しているため、データベースの設計との関連性は大きくありません.この問題を解決するには、ユーザー操作に関連するテーブルごとに新しいフィールドoperator_を追加する必要があります.id. もう1つは、ユーザーのステップ操作が複数のテーブルの変更に関連し、このときbinlogをトランザクションidで集約することができる場合です.その後、binlogを操作レコードに変換してライブラリに記録する必要があります.操作レコードのフィールドは以下の通りです.(1)operator_id(オペレータid)(2)operation_type(操作タイプ、テーブルおよびbinlogタイプ(insert,update,delete)に基づいて決定可能)(3)before(json、ローレコード修正前の値を記述する)(4)after(ローレコード修正後の値を記述する)(5)timestamp(タイムスタンプ)
ここで、ユーザ操作ログの生成とクエリーは、全体の流れは以下の通りである:1ユーザ操作修正表2非同期サービス取得binlog 3トランザクションidに基づいてbinlogを一定の集約処理4 binlogを元の操作ログに変換し、ライブラリ5に記録ユーザが操作ログをクエリーすると、条件検索操作ログ6に基づいて操作ログをユーザ可読のviewに変換して返す