SpringBoot集成Redis緩存技術(shù)在企業(yè)一卡通系統(tǒng)中的應(yīng)用

文/寧方美 賀雪梅 牟晉娟

1 引言

時(shí)間管理、安全管理、消費(fèi)管理在近些年的企業(yè)管理中越來越受到管理者的關(guān)注。在國(guó)外，由于人工成本高昂，時(shí)間管理更是企業(yè)生存發(fā)展的重要環(huán)節(jié)。企業(yè)一卡通就是幫助客戶實(shí)現(xiàn)時(shí)間管理、運(yùn)營(yíng)安全等方面的統(tǒng)一管理，讓時(shí)間管理變得更簡(jiǎn)單、安排的更合理、發(fā)揮出更大價(jià)值。企業(yè)一卡通系統(tǒng)是軟件硬件相結(jié)合的系統(tǒng)，終端設(shè)備多樣化，對(duì)于一個(gè)中大型的企業(yè)來說，每日產(chǎn)生的數(shù)據(jù)量是非常龐大的，企業(yè)一卡通開發(fā)的難點(diǎn)之一是保證終端和服務(wù)器端的數(shù)據(jù)的一致性，避免數(shù)據(jù)在上傳下達(dá)過程中丟失。

本文結(jié)合實(shí)際企業(yè)一卡通項(xiàng)目開發(fā)經(jīng)驗(yàn)，圍繞SpringBoot技術(shù)架構(gòu)中如何采用Redis緩存技術(shù)設(shè)置特定的操作流程，解決系統(tǒng)中數(shù)據(jù)同步問題。

2 SpringBoot技術(shù)架構(gòu)和Redis技術(shù)簡(jiǎn)介

2.1 SpringBoot簡(jiǎn)介

SpringBoot是在 2013年推出的新項(xiàng)目，主要用來簡(jiǎn)化 Spring 開發(fā)框架的開發(fā)、配置、調(diào)試、部署工作，同時(shí)在項(xiàng)目?jī)?nèi)集成了大量易于使用且實(shí)用的基礎(chǔ)框架。

在傳統(tǒng)的Spring框架中開發(fā)，用戶需要自行編寫XML文件，并在Maven、Gradle中加入相應(yīng)的依賴包，在響應(yīng)的代碼中添加功能代碼，才能使用；如果使用SpringBoot開發(fā)，僅需在Maven、Gradle配置文件中加上少量的配置，即可在代碼中使用所需的框架，讓原本的配置簡(jiǎn)化到幾乎是零代碼、零 XML 配置，同時(shí)依賴包的版本問題也由SpringBoot輕松解決，所以SpringBoot非常適合大型項(xiàng)目的開發(fā)配置。

2.2 Redis技術(shù)

Redis是一個(gè)key-value存儲(chǔ)系統(tǒng)，也是NoSQL技術(shù)陣營(yíng)中的一員，它通過多種鍵值數(shù)據(jù)類型來適應(yīng)不同場(chǎng)景下的存儲(chǔ)需求，Redis優(yōu)勢(shì)主要包括：

（1）性能極高，Redis是一種NoSql數(shù)據(jù)庫，Redis的操作是在內(nèi)存中進(jìn)行的，其速度相比于MySQL之類的數(shù)據(jù)庫，相當(dāng)于內(nèi)存讀寫與硬盤讀寫的差別，Redis能讀的速度是110000次/s,寫的速度是81000次/s ；

（2）支持的數(shù)據(jù)類型豐富，Redis支持二進(jìn)制案例的 Strings,Lists,Hashes,Sets 及 Ordered Sets 數(shù)據(jù)類型操作；

（3）支持事務(wù)，操作都是原子性，所謂的原子性就是對(duì)數(shù)據(jù)的更改要么全部執(zhí)行，要么全部不執(zhí)行；

（4）豐富的特性，Redis還支持 publish/subscribe,通知,key 過期等等特性。

基于上述優(yōu)勢(shì)，Redis技術(shù)最大的應(yīng)用場(chǎng)景就是用來做緩存。緩存技術(shù)可以大大減輕服務(wù)器的壓力，減少數(shù)據(jù)丟失，提高系統(tǒng)中數(shù)據(jù)的一致性和完整性。

3 Spring Boot集成Redis在一卡通管理系統(tǒng)應(yīng)用

在企業(yè)一卡通系統(tǒng)中，員工每天通過終端進(jìn)行考勤打卡、餐廳的消費(fèi)記錄等操作，這些終端產(chǎn)生的數(shù)據(jù)必須最終同步到服務(wù)器端，我們稱之為“上傳數(shù)據(jù)”。

另一方面，系統(tǒng)管理員在服務(wù)器端添加或者修改數(shù)據(jù)，如新員工到人事報(bào)道，人事工作人員通過服務(wù)器端的管理窗口錄入新員工的信息；人事在服務(wù)器端調(diào)整員工所在部門等；這些在服務(wù)器端的修改必須同步到對(duì)應(yīng)的終端設(shè)備中，我們稱之為“下發(fā)數(shù)據(jù)”。

在企業(yè)一卡通系統(tǒng)中，做好終端設(shè)備和服務(wù)器之間的上傳下發(fā)，也就做好了數(shù)據(jù)的同步。實(shí)際的應(yīng)用中，主要存在兩個(gè)主要的問題：

（1）大量數(shù)據(jù)上傳容易產(chǎn)生服務(wù)器擁堵；

（2）數(shù)據(jù)丟失嚴(yán)重。

本系統(tǒng)采用Redis緩存技術(shù)結(jié)合SpringBoot框架設(shè)置了一套企業(yè)一卡通的同步機(jī)制。

3.1 HTTP PUSH 協(xié)議

圖1：HTTP PUSH協(xié)議流程圖

HTTP 協(xié)議是一種請(qǐng)求/響應(yīng)型的協(xié)議，而Push 協(xié)議是基于HTTP的基礎(chǔ)上定義的數(shù)據(jù)協(xié)議，Push協(xié)議建立在TCP/IP 連接上，使用 Push 協(xié)議的客戶端和服務(wù)器，必須由客戶端先發(fā)起“初始化信息交互”請(qǐng)求成功之后，才能使用其他功能，比如上傳數(shù)據(jù)、獲取服務(wù)器命令、上傳更新信息、回復(fù)服務(wù)器命令等，其中這些功能并沒有先后順序，取決于客戶端應(yīng)用程序的開發(fā)。如圖1所示。

3.2 上傳數(shù)據(jù)

以“考勤打卡”為例說明“上傳數(shù)據(jù)”實(shí)現(xiàn)機(jī)制。

（1）用戶在終端打卡后考勤機(jī)自動(dòng)發(fā)送RestApI POST請(qǐng)求到Server，客戶端請(qǐng)求示例如下：

POST /iclock/cdata?SN=0316144680030＆t able=ATTLOG＆Stamp=9999 HTTP/1.1

Host: 58.250.50.81:8011

Content-Length: 145

1452 2015-07 -30 15:16:28 0 1 0 0 0

1452 2015-07 -30 15:16:29 0 1 0 0 0

8965 2015-07 -30 15:16:36 0 1 0 0 0

8965 2015-07 -30 15:16:37 0 1 0 0 0

（2）Server端接收到請(qǐng)求后，將此條考勤數(shù)據(jù)寫入到Redis Queue中，同時(shí)給終端響應(yīng)，Redis Queue中存儲(chǔ)著所有終端上傳的更新數(shù)據(jù)。

服務(wù)器響應(yīng)： HTTP/1.1 200 OK Server: nginx/1.6.0

（3）在Redis Queue中可以設(shè)置不同的參數(shù)，選擇實(shí)時(shí)寫入或者定時(shí)寫入數(shù)據(jù)庫的方式，Redis Queue會(huì)按照先進(jìn)先出的規(guī)則逐條取出更新數(shù)據(jù)寫入的數(shù)據(jù)庫。

3.3 下發(fā)數(shù)據(jù)

以“新增人員”說明“下發(fā)數(shù)據(jù)”的實(shí)現(xiàn)機(jī)制。

（1）人事通過管理頁面錄入新員工的基本信息，該條數(shù)據(jù)立即寫入數(shù)據(jù)庫中。

（2）按照設(shè)備協(xié)議規(guī)則組織添加數(shù)據(jù)命令，并把命令寫入到Redis Cache中，新增人員的命令格式如下：

C:${CmdID}:DATA${SP}UPDATE${SP}USERINFO${SP}PIN=${XXX}${HT}Name=${XXX}${HT}Passwd =${XXX}${HT}Card=${XXX}${HT}Grp=${XXX}${HT}TZ=${XXX}${HT}Pri=${XXX}

部分字段說明：

1.PIN=${XXX}：用戶工號(hào)

2.Name=${XXX}：用戶姓名，當(dāng)設(shè)備為中文時(shí)，使用的是 GB2312 編碼，其他語言時(shí)，使用 U TF-8 編碼

3.Passwd=${XXX}：密碼

4.Card=${XXX}：卡號(hào)，值支持兩種格式

（3）終端設(shè)備可以設(shè)置心跳包，規(guī)則間隔執(zhí)行命令的時(shí)間，自動(dòng)執(zhí)行服務(wù)器端的Redis命令；一旦指令已經(jīng)執(zhí)行過且執(zhí)行成功，該條指令將從Redis Cache中刪除；執(zhí)行失敗的指令將被標(biāo)注重新存儲(chǔ)。

4 總結(jié)

在3.2 和3.3中分別講述在作者參與的企業(yè)一卡通系統(tǒng)中，如何同步終端和服務(wù)器端的數(shù)據(jù)。Redis在“上傳數(shù)據(jù)”和“下發(fā)數(shù)據(jù)”中分別采用了不同的技術(shù)手段，從終端上傳的各種數(shù)據(jù)首先保存的Server端的Redis Queue中，按照先進(jìn)先出的原則在從Redis Queue將數(shù)據(jù)寫入數(shù)據(jù)庫；服務(wù)端更新的數(shù)據(jù)寫入數(shù)據(jù)庫后，全部保存到Redis Cache中，根據(jù)設(shè)置的更新周期和頻率逐步從Cache中獲取更新指令，指令執(zhí)行成功后實(shí)時(shí)更新Cache,從實(shí)際的系統(tǒng)運(yùn)行效果來看，該機(jī)制大大降低了服務(wù)器擁堵問題，充分證明了Redis技術(shù)在解決此類問題中的強(qiáng)大功能。從實(shí)際應(yīng)用效果看，終端和服務(wù)器端數(shù)據(jù)的一致性可以達(dá)到98%以上。