Keywords

1 Introduction

Every year when it comes to graduate season, many well-known companies will receive thousands of resumes. It takes a lot of time and resources of the companies to identify the authenticity of the resumes. If the data of students’ whole life cycle can be truly and untamable recorded such as awards record, certificates and grades, etc. a lot of time will be saved.

For that the blockchain [1, 2] is good at solving the problems of data security, sharing and reconciliation and so on, a lot of research has sprung up on the application industry of blockchain such as finance [3], medical care [4] and education [5, 6].

The sudden abundant data caused by students’ collective activities requires fabric’s consensus mechanism, kafka-based ordering service [7], should adapt to the current system workloads quickly. Therefore in this paper, a novel adaptive tuning mechanism (A-Kafka) contracting on adjustment of the parameters of the kafka-based ordering service based on feedback control theory [8] is proposed, with blockchain particularly Hyperledger fabric [9] utilized. In order to evaluate its efficiency, the proposed A-Kafka is studied on and analyzed in comparison with the original scheme of kafka (O-Kafka).

2 Related Work

The consensus mechanism based on kafka is selected by Hyperledger fabric1.x, which has the characteristics of high throughput, low latency, extensibility, durability and reliability [10]. The kafka-based consensus mechanism contains kafka cluster and its associated zookeeper cluster, as well as ordering service nodes (OSN). Literature [11, 12] elaborated its consensus process:

Figure 1 shows the flow of kafka-based ordering service, when the transactions (e.g. tx1, tx2 … txn) created by clients, they will be broadcasted toward OSNs into kafka cluster. When the configurations of batchSize which is the maximum message count of the block and batchTimeout which is the maximum delay time from the last block generated are met, OSNs will package previously received transactions and generate a new block and after that, the block will be presented to committer peers which validate transactions in every block.

Fig. 1.
figure 1

The architecture of kafka-based ordering service

Full size image

Currently, the configuration of O-Kafka about batchSize and batchTimeout could be set at startup [12], but the optimal policy configuration cannot be determined in real-time. Therefore, some researches related to the kafka-based consensus optimization have been carried out such as literature [13, 14].

3 Model

3.1 Model Representation

To describe the structure of A-Kafka, this paper models kafka-based ordering service into three stages: ordering, buffer and batching until configurations are met and committer validation.

A-Kafka continually evaluates the whole workload and the performance of consensus throughout a feedback control loop. It obtains information from kafka-based ordering service regarding the events such as pull transactions from the kafka cluster, buffer and cut block and process block (committer peers’ validation) to adjust parameters of batchSize and batchTimeout.

3.2 Model Details

BatchTimeout

The batchTimeout should be large or small enough to meet the requirements of enough transactions batched or a busy state of the stage committer validation. MBV defined in this paper is the mean process time of buffer and batching and committer validation, and MOT defined is the mean time interval of OSNs pull transactions.

The Eq. (1) is the formula of MBV.

$$ MBV_{k} = \alpha MBV_{k - 1} + \left( {1 - \alpha } \right)BV_{k} $$
(1)

In the formula, \( \alpha \) is the coefficient and \( BV_{k} = T_{exe} - T_{start} \); \( T_{exe} \) is the instant time of complete validation of a block and \( T_{start} \) is the instant time when the OSN pulls a transaction from kafka cluster. \( MBV_{k - 1} \) means the average value of the last T time intervals of \( MBV \).

The Eq. (2) shows the formula of MOT.

$$ MOT = \frac{{t - t_{0} }}{n} $$
(2)

In the formula, n represents the number of transactions that OSNs pulled in time interval \( \left( {t - t_{0} } \right) \).

BatchSize

The adjustment method of batchSize is also should be large or small enough. The batchSize (BS) then could be calculated from the relationship of MBV and MOT and the Eq. (3) is presented below.

$$ BS = \left\lceil {\frac{MBV}{MOT}} \right\rceil $$
(3)

3.3 Algorithms for A-Kafka

figure a
figure b
figure c

4 Experiments

4.1 Objective

Latency (LT) and Throughput (TH) is widely used in performance evaluation. LT measures the mean time interval of a process from a transaction initially being created by clients to the transaction is confirmed by the blockchain. TH measures the numbers of transactions processed successfully number per second. What’s more, \( {\text{PER}} = \frac{TH}{LT*100} \) is utilized in this paper to evaluate the integral performance.

4.2 Experiments Design

The configuration of Hyperledger Fabric is fixed, the number of the nodes of zookeeper is fixed to 3, with that of the kafka nodes fixed to 4 and of the orderer nodes 3. And considering the influence factors of experimental performance are the size of transactions and the value of batchTimeout and batchSize. Therefore, the experiments are designed to those of fixed workloads and those of varying workloads.

4.3 Results and Analysis

Fixed-Workloads Experiments

The data collected from the fixed-workload experiments is shown from Tables 1 and 2. Obviously, the performance of A-Kafka is better than O-Kafka by observing variation of PER.

Table 1. Fixed-workloads results (5 clients, 8 KB)
Full size table
Table 2. Fixed-workloads results (50 clients, 8 KB)
Full size table

Varying-Workloads Experiments

Tables 3 and 4 present the results of the experiments of varying workloads with 5 and 50 clients engaged. We found that A-Kafka is more effective in experiments of varying workloads compared to those of fixed workloads by observing the change of PER.

Table 3. Varying-workloads results (5 clients, 256B-8 KB)
Full size table
Table 4. Varying-workloads results (50 clients, 256B-8 KB)
Full size table

To sum up, A-Kafka performs better than O-Kafka both in two types of experiments especially with varying workloads. To analyze, O-Kafka cannot cope with the changing workloads.

5 Conclusion

To address the difficulty in adapting to the dynamic workloads of the kafka-based ordering service in Hyperledger Fabric, this paper proposes an adaptive tuning mechanism A-Kafka. The results have shown that the effectiveness of this mechanism exceeds the O-Kafka, both in the experiments of fixed and varying workloads.